18:00:37 <mmaslano> #startmeeting FESCO (2013-07-24)
18:00:37 <zodbot> Meeting started Wed Jul 24 18:00:37 2013 UTC.  The chair is mmaslano. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:37 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:43 <mmaslano> #meetingname fesco
18:00:43 <zodbot> The meeting name has been set to 'fesco'
18:00:48 <mmaslano> #chair abadger1999 mattdm mitr mmaslano notting nirik pjones t8m sgallagh
18:00:48 <zodbot> Current chairs: abadger1999 mattdm mitr mmaslano nirik notting pjones sgallagh t8m
18:01:32 <mmaslano> #topic init process
18:01:35 * sgallagh is here but splitting his attention.
18:01:35 <nirik> morning everyone.
18:01:37 <mitr> Hello
18:02:03 <mattdm> good afternoon
18:02:07 <pjones> hi.
18:02:17 <t8m> hello
18:02:48 * notting is here
18:03:25 <mmaslano> abadger1999: are you here?
18:03:28 * abadger1999 here
18:03:42 <mmaslano> let's follow up with old topics
18:03:43 <abadger1999> Sorry, just trying to read the last few messages on no default sendmail
18:03:49 <mmaslano> #topic #1132 libtool + %global _hardened_build 1 = no full hardening
18:03:54 <mmaslano> .fesco 1132
18:03:55 <zodbot> mmaslano: #1132 (libtool + %global _hardened_build 1 = no full hardening) – FESCo - https://fedorahosted.org/fesco/ticket/1132
18:04:28 <mmaslano> ok, so this one is related to mass rebuild
18:04:37 <mmaslano> do you want to discuss time for mass rebuild now or later?
18:05:07 <nirik> so, looks like maintainer is on vacation, so someone else needs to apply the hacky patch.
18:05:28 <nirik> I guess I can do it, or see if dgilmore would like to.
18:05:56 <mmaslano> the another problem is still running rebuild of Perl
18:06:07 <nirik> yeah, so on mass rebuild:
18:06:20 <mmaslano> feature owners hope it will take a week to do the rest of packages
18:06:34 <nirik> perl needs to finish. last few arm things need finished (I think java is landing today/tomorrow with a fix).
18:06:42 <t8m> and we have the docdir change that is needed before mass rebuild
18:07:07 <nirik> also, there is datacenter work next week... so ideally mass rebuild would be after thats done so it doesn't disrupt it any.
18:07:28 <mmaslano> nirik: who coordinate those things?
18:07:39 <nirik> me I guess?
18:07:40 <mmaslano> nirik: should we decide on the next meeting if everything is ready?
18:07:50 <mmaslano> nirik: great, what do you want :)
18:08:06 <mitr> If there are action items, do they have clear owners?  (like the libtool thing...)
18:08:08 <nirik> well, I'd say we know what we are waiting for, so we should start it as soon as all those are landed.
18:08:23 * nirik looks for the docs change
18:08:58 <mitr> ARM SIG suggested last week that they were able to join the build systems by 20th; has that happened?  is there a specific problem we should be aware of?  or should we just keep hands of and not waste ARM SIGs time?
18:09:05 <nirik> https://bugzilla.redhat.com/show_bug.cgi?id=986871
18:09:37 <notting> mitr: if they have blockers, it would be good to know what they are
18:09:39 <nirik> mitr: packages have mostly been imported. It's waiting on a java build today/tomorrow to enable builds in primary buildsys (at least my understanding talking to dgilmore)
18:09:58 <nirik> the java build lands native stuff which should make the java rebuilds much faster.
18:10:28 <mitr> jreznik__: So we are looking at at least a week's slip.  Is that acceptable enough?
18:11:00 * nirik nods. I think we are a week off at this point from the estimated schedule.
18:11:19 <jreznik__> one week is ok
18:11:38 <mmaslano> +1 one week slip
18:12:11 <nirik> so, next week perhaps we set the final schedule?
18:12:18 <jreznik__> it leads to Nov 19, still time before Christmas
18:12:22 <nirik> (once we have reviewed all the changes)
18:12:27 <jreznik__> nirik: works for me
18:12:32 * dgilmore thinks we should give maybe 2 weeks
18:13:14 * mattdm thinks this does feel like a really fast cycle. maybe i've just been extra busy
18:13:19 <jreznik> dgilmore: two weeks are on the edge, still doable
18:13:20 <pjones> dgilmore: what's your reasoning for wanting the extra week?
18:13:26 <mmaslano> dgilmore: because of arm?
18:13:41 <dgilmore> pjones: as is things are mich tighter than usual
18:13:55 <abadger1999> mattdm: You are correct, it's a very fast cycle.
18:13:57 <dgilmore> we normally give 3 weeks for mass rebuild
18:13:57 * nirik would be good to decide final schedule next week. We should know more then if we have started mass rebuild, etc.
18:14:04 <dgilmore> it takes about a week for initial pass
18:14:17 <dgilmore> and then we allow two weeks for clean up
18:14:47 <jreznik> I'm with nirik - lets say we need at least one week and we will see the status - if it would not make sense to move it by one week, we will try two weeks
18:15:19 * nirik hopes he can be on next week, will be at datacenter, so we will see.
18:15:36 <pjones> jreznik: I really hate it when we do this "let's push by one week and see where we are" stuff.
18:15:48 <jreznik> pjones: not now, once we know more
18:16:07 <dgilmore> assuming we start rebuilding on tuesday the 30th, first pass would be done around the 6th. which is when we are supposed to branch
18:16:09 <pjones> either we do need to slip two weeks or we don't.  if dgilmore is telling us we need to slip two, ...
18:17:07 <jreznik> pjones: if it's really not doable and dgilmore wants two weeks - I don't have big issues with it neither, it's on the edge but
18:17:14 <nirik> jreznik: have you sent out all the changes for review at this point? or are there more?
18:17:16 <dgilmore> one week to clean up failures really really tight
18:17:55 <dgilmore> mmaslano: its nothing to do with arm.
18:18:08 <jreznik> nirik: few more but nothing really big
18:18:31 <nirik> well, if folks want to set the schedule now we could do that I suppose...
18:18:37 <mitr> We are not really forced to slip - the cleanup would just have to continue on both branches
18:18:38 <jreznik> some people were confused from change from feature to change etc., I'm trying to sort it out, most of the stuff is for this meeting
18:18:38 <dgilmore> hopefully we can merge perl in and the docdir changes land by tuesday
18:18:47 <nirik> I'd worry about something preventing us from starting mass rebuild on time or the like.
18:19:04 <mitr> So, 4 to-do items? 1) libtool hardening patch 2) docdir patch, 3) ARM 4) start the mass rebuild
18:19:06 <mitr> Corresponding owners: 1) ??? 2) ??? 3) no FESCo action 4) no FESCo action?
18:19:29 <pjones> mitr: looks right
18:19:30 <dgilmore> nirik: right. if we cant start by tuesday there is no way we will line things up right
18:19:31 <nirik> 5) merge perl mass rebuild
18:19:34 <mmaslano> 5) Perl rebuild
18:19:41 <pjones> well, that's 0
18:19:51 <nirik> I can do the 1 and 2 things I suppose, unless someone else would be willing to.
18:19:51 <pjones> in that it's underway
18:20:17 <mmaslano> 2 should be done by Panu, but he didn't respond to me
18:20:25 <nirik> he's on vacation it seems
18:20:36 <nirik> "Somebody else better take this bug then, I'm on vacation for two more weeks mostly AFK. Its lucky enough I happened to notice this at all."
18:21:10 <pjones> nirik appears to have volunteered ;)
18:21:20 <nirik> yeah, I can if no one else will.
18:21:31 <mmaslano> great
18:21:48 <mitr> nirik: thanks
18:21:51 <nirik> will try and land it later today so we can shake out bugs before rebuild
18:21:58 <mmaslano> I'll write it into rebuild ticket and let's move on
18:22:05 <mmaslano> #topic #1136 F20 System Wide Change: ARM as primary Architecture - https://fedoraproject.org/wiki/Changes/ARM_as_Primary
18:22:10 <mmaslano> .fesco 1136
18:22:13 <zodbot> mmaslano: #1136 (F20 System Wide Change: ARM as primary Architecture - https://fedoraproject.org/wiki/Changes/ARM_as_Primary) – FESCo - https://fedorahosted.org/fesco/ticket/1136
18:22:18 <nirik> I think we already went over this...
18:22:32 <pjones> I think we mostly just agreed this is a no-fesco-action item at this point in time
18:22:42 <nirik> yeah.
18:22:44 <mitr> Yes.  One question is whether we want to keep the topic on the agenda, or get a shepherd as has been suggested.
18:22:51 <mmaslano> I asked them for status, it's in the ticket
18:23:04 <mmaslano> otherwise we could completely forget about it
18:23:04 <nirik> well, the open issue for fesco is when/if we decide to actually promote arm to primary?
18:23:13 <dgilmore> mitr: i dont think it needs to stay on theagenda
18:23:36 <pjones> nirik: but we basically decided that last week/the week before - once the merge is done and it appears to be /working/ as a primary arch
18:23:37 <dgilmore> once we get the the point of milestone delivery it should be added back
18:23:42 <nirik> when do we decide the primaryness (ok, thats not a word at all)
18:23:55 <nirik> ok, so before alpha?
18:24:01 <t8m> +1 to remove from agenda for now
18:24:15 <notting> +1. please put back if there are blocking issues
18:24:17 <pjones> nirik: primacy surely ;)
18:24:43 <mmaslano> +1
18:24:44 <dgilmore> notting: right. if we hit snags in the implementation ill be raising issues
18:24:45 <abadger1999> makes sense, +1
18:24:51 * nirik hands arm a crown and septre.
18:25:08 * nirik is fine with removing it for now.
18:25:20 <nirik> perhaps we should just say... 'if there's no blocking issues by alpha, it's primary' ?
18:26:00 <mitr> nirik: I'd rather see the results of people using the alpha
18:26:03 <mmaslano> probably, we will review it as other features
18:26:04 <pjones> likewise
18:26:07 <nirik> ok.
18:26:22 <mmaslano> #topic #1138 F20 System Wide Change: Unversioned Docdirs - https://fedoraproject.org/wiki/Changes/UnversionedDocdirs
18:26:27 <mmaslano> .fesco 1138
18:26:28 <zodbot> mmaslano: #1138 (F20 System Wide Change: Unversioned Docdirs - https://fedoraproject.org/wiki/Changes/UnversionedDocdirs) – FESCo - https://fedorahosted.org/fesco/ticket/1138
18:26:32 <pjones> the criteria for success is actually succeeding, not it across the finish line ;)
18:26:38 <pjones> s/not/not throwing/
18:26:39 <nirik> I think we were mostly +1 on ticket on this one?
18:26:43 * nirik is ok with it.
18:26:50 <nirik> pjones: sure.
18:27:00 <mmaslano> #action nirik volunteered to apply the patch
18:27:09 <mmaslano> it was +6 in ticket
18:27:12 * pjones is vaguely +0 on this one
18:27:23 <mattdm> Yeah, what pjones said
18:27:26 <sgallagh> I'm a weak +1 for this.
18:27:33 <mattdm> I guess +0.1?
18:27:39 <nirik> yep. Not strongly, but whatever.
18:27:57 <mattdm> sounds like a solid "meh" all around!
18:27:58 <sgallagh> In my view, it's slightly more convenient but largely irrelevant.
18:28:25 <sgallagh> Given most of the BZs I see, I doubt many of our users even know these directories exist... -_-
18:28:38 * t8m on the other hand wonders why we didn't do this a long time ago
18:28:59 <nirik> yeah, lets say approved and move on
18:29:05 <mmaslano> yeah
18:29:37 <mmaslano> #approved Unversioned Docdirs will be used (+6.1,-0)
18:29:49 <mmaslano> #topic #1140     F20 Self Contained Changes - week 2013-07-10 - 2013-07-17
18:29:54 <mmaslano> .fesco 1140
18:29:55 <zodbot> mmaslano: #1140 (F20 Self Contained Changes - week 2013-07-10 - 2013-07-17) – FESCo - https://fedorahosted.org/fesco/ticket/1140
18:29:58 <mmaslano> it's messy this time
18:30:49 <nirik> shall we call out ones we want to discuss more?
18:31:06 <t8m> nirik, please do
18:31:26 * mitr repeats OpenOffice and ntpd
18:31:39 <notting> i second mitr's addendum on apache openoffice
18:31:43 * nirik is fine with all except: ntpdate, apache openoffice (but I would be ok with mitr's proposed acceptance)
18:32:09 <nirik> and possibly ruby on rails being system wide.
18:32:32 <t8m> I agree with mitr's Apache Openoffice addendum as well
18:32:41 <abadger1999> ruby on rails I think is systemwide, I'm +1 to approving it though.
18:32:56 * nirik is ditto abadger1999
18:32:57 <t8m> For the ntpdate - should we request the submitter to resummarize?
18:33:02 <pjones> yeah, that was my thought as well
18:33:02 <mitr> There are several things where "self-contained" is a bit of a stretch - OTOH "nobody saw a specific reason to mark as systemwide" is good enough for me
18:33:23 <mmaslano> let's vote about them
18:33:24 <pjones> mitr: yeah, I think that's going to very rapidly become the default rule
18:33:32 <nirik> on ntpdate I would say: punt and ask submittor to redo the change with all the discussion. It's unclear to me anymore what it is going to do.
18:33:45 <t8m> nirik, exactly
18:33:46 <pjones> nirik: +1
18:33:48 <sgallagh> Actually, LVM thin provision support might be considered system-wide from a testing perspective
18:33:50 <abadger1999> I'd be +1 to the exact same proposal for F20 Apache OpenOffice as F19 although I do wonder what's going on with a re-review of the package/bundled libraries/etc.
18:33:51 <jreznik> for ntpdate I'm +1 to nirik
18:34:11 <abadger1999> ntpdate: +1
18:34:22 <mitr> (I'd actually prefer dropping or weakening the last sentence about OpenOffice in case there were a larger consensus to that effect - but I'm fine with the old resolution and keeping it unmodified simplifies things)
18:34:22 <notting> +1 to punting ntpdate
18:34:25 <abadger1999> (+1 to asking for a new description)
18:34:37 <mitr> +1 to deferring ntpdate for a reworked proposal
18:34:40 <sgallagh> +1 to asking for a new desc on ntpd
18:35:10 <pjones> sgallagh: eh, doubt it on lvm.  it's basically another option in the drop-down, so most users won't be affected.
18:35:11 <mmaslano> could you use proposals? that would be helpful for counting votes
18:35:11 <mattdm> +1 as well after rereading it
18:35:51 <pjones> sgallagh: it does have additional testing overhead, but it is at least relatively isolated
18:35:53 <nirik> proposal: ask ntpdate submittor to rework change and resubmit based on feedback on list, describing new planned scope and changes.
18:36:07 <mmaslano> +1
18:36:18 <abadger1999> +1
18:36:20 * nirik is +1 too shockingly
18:36:24 <t8m> +1
18:36:27 <BCrookAtRA> can ntpdate be replaced with a wrapper for ntpd that does the same thing as ntpdate (much like 'chkconfig' and 'service' to today)  print the 'right way' and then execute it
18:36:32 <sgallagh> +1
18:36:36 <mitr> sgallagh: "Do we want to change the release criteria?" would be my criterion on LVM
18:36:40 <mitr> nirik: +1
18:36:44 <t8m> BCrookAtRA, I am afraid we can't solve this here now
18:37:00 <mattdm> +1
18:37:27 <mmaslano> #agreed ntpdate submittor has to rework the proposal and resubmit to list with describing new scope and changes (+6,-0)
18:37:30 * nirik notes also that chrony is default on many types of fedora installs. Ideally it would have a way to do all the things we need from ntpdate.
18:37:37 <mmaslano> #proposal apache openoffice approved as is, but with mitr's addendum
18:37:41 <notting> nirik: +1
18:37:42 <mattdm> btw rfe for chronie to just do it as recieved positively. https://bugzilla.redhat.com/show_bug.cgi?id=986098
18:37:43 <pjones> nirik: +1
18:37:46 <notting> mmaslano: +1
18:37:52 <nirik> mattdm: cool.
18:37:54 <nirik> mmaslano: +1
18:38:02 <notting> mattdm: we have chrony and cronie. are they merging?
18:38:04 <abadger1999> +1
18:38:08 <mmaslano> notting: no
18:38:12 <sgallagh> What was mitr's addendum?
18:38:29 <mmaslano> sgallagh: Feature is accepted under the condition that the conflicts must be worked out. openoffice and libreoffice packagers get to work them out. There is no fesco mandate that libreoffice must change to accomodate openoffice at this time. alternatives is not the way to resolve the conflicts but environment-modules may be looked at as a similar means to achieve that.
18:38:40 <sgallagh> +1
18:38:47 <t8m> +1 to the proposal
18:38:49 * sgallagh thought that was the original
18:38:55 <mattdm> notting so confusing. whichever is the time one :)
18:38:55 <mmaslano> #action jreznik will contact ntpdate owner
18:39:12 <abadger1999> Question that I'd just like to be clear about w/ apache oo -- is there a re-review request?
18:39:21 <nirik> abadger1999: there would need to be...
18:39:31 <abadger1999> Okay.  Fair enough.
18:39:47 <mmaslano> #agreed apache openoffice approved as is, but with mitr's addendum (+7,-0)
18:39:59 <abadger1999> There's some technical questions that I'll just wait on the re-review ticket to make sure get addressed.
18:40:21 <nirik> yeah, they get no free pass to bypass any guideline, IMHO
18:40:25 <mattdm> I think we should maybe make clear that we're not auto-approving any exceptions to the process to get it in.
18:40:33 <mattdm> right that :)
18:41:04 <mmaslano> abadger1999: do you want to look at the re-review?
18:41:08 <abadger1999> If it needs to be explicit, +1 -- I'd hope that would be the expectation for any feature though :-)
18:41:27 * nirik sees no review filed yet
18:41:32 <t8m> mattdm, I really do not see the need for it to be explicit
18:41:39 <abadger1999> mmaslano: I wanted to look at but not necessarily do the whole thing :-)  And I didn't see a ticket for it yet in bugzilla.
18:41:49 <pjones> mattdm: I think that's clear - that's why they're called exceptions, not "the process"
18:41:54 <mmaslano> ok, so we can leave it for now
18:41:54 <t8m> mattdm, we could then have to add this addendum to every approved change
18:42:09 <pjones> there are no automatic exceptions to the process.  ever.
18:42:14 <mmaslano> sgallagh: you wanted to speak about LVM, don't you?
18:42:22 <mattdm> t8m, pjones Sure I just think that since the "changes" process is new, that may be unclear. We can move on.
18:42:53 <pjones> #info mattdm wants this to be perfectly clear: FESCo does not grant automatic exceptions to our processes on any basis.
18:42:54 <t8m> mmaslano, I think we can persuade sgallagh, that this is not needed to be systemwide
18:42:59 <pjones> mattdm: done
18:43:29 <sgallagh> mmaslano: Well, my concern here is mostly that if we install with LVM thinp, there are other applications that will need to be thinp-aware to avoid user confusion
18:43:35 <sgallagh> For example, 'df'
18:44:01 <mmaslano> abadger1999: so, let's discuss Ruby&Rails as a system wide?
18:44:10 <abadger1999> mmaslano: works for me.
18:44:13 <pjones> sgallagh: I think that's... unrelated to this change.
18:44:15 <mitr> sgallagh: That's... an interesting problem.
18:44:27 <pjones> sgallagh: this isn't "does fedora support lvm thinp at all"
18:44:34 <mitr> pjones: Only because it's very precisely named so that it would be unrelated.
18:44:52 <sgallagh> pjones: It's "does Fedora consider installation on lvm thinp a supported configuration"
18:45:07 <pjones> mitr: and because different people are responsible for different parts of our OS, and I'm not willing to put dlehman on the hook for places LVM does something weird, just because he's enabling our users to use something we already let them use more easily.
18:45:19 <sgallagh> I think we *should*, but I think it needs to be coordinated to avoid a negative user experience
18:45:35 <pjones> if there are problems with using thinp, they need to be addressed, but that's not this feature.
18:45:38 <mitr> pjones: That makes sense, otoh _somebody_ eventually should be on the hook or the whole system will never work right
18:45:38 <pjones> er, change.
18:45:40 <sgallagh> Because there are a lot of benefits to this approach, but if we don't address thinks like 'df' early, it will sour people
18:45:44 <pjones> old typing dies hard ;)
18:46:36 <mmaslano> sgallagh: do you have any proposal what to do?
18:46:45 <mitr> To be more precise,, "df" is 'interesting' but I'd not want to micromanage that working in any specific way.  We should be clear whether this impact release criteria or not, though.
18:47:24 <sgallagh> mmaslano: Well, my main proposal would be "declare it system-wide and request that they coordinate with the coreutils folks"
18:47:52 <mmaslano> fine by me +1
18:48:00 <nirik> do we know df doesn't work with it?
18:48:22 <sgallagh> nirik: Well, it's ambiguous how it works because the upper available limits are fluid
18:48:26 <pjones> sgallagh: so, uh, what exactly is weird about df?
18:48:46 <pjones> the numbers are unexpected sometimes?  because that's always been true for all unix filesystems - consider the df -i case of full FS, for example.
18:48:51 <sgallagh> With thinp, you can have a 200GB drive with two 200GB thinp partitions on it.
18:49:04 <notting> is it any more conceptually confusing than df/du when sparse files are in use?
18:49:14 <poettering> (btw, you are aware that there are services like journald which actually scale the amount of disk space they will use at max by the size and fill level of the partition they rely on?)
18:49:20 <pjones> notting: it's exactly the same AFAICS
18:49:46 <sgallagh> poettering: Ok, that sounds like something else that should be coordinated in this effort.
18:49:48 <mitr> notting: yes, per https://bugzilla.redhat.com/show_bug.cgi?id=952787 it seems applications might get EIO instead of ENOSPC
18:49:50 <pjones> poettering: but fill level for one mountpoint is still effectively correct, if I understand right
18:50:11 <poettering> (btw, btrfs raid is actaully broken in a similar way: it will report all df values multiplied by 2)
18:50:25 <sgallagh> pjones: Except if the journal partition ends up running out of space because a data partition actually uses up the whole available pool
18:50:30 <pjones> there are issues here, but they're more of the same issues we used to have
18:50:41 <poettering> (apps *and* users must be able to rely on the values returned there do scale things.)
18:50:44 <pjones> sgallagh: which is the same as with sparse files and btrfs raid and ...
18:51:04 <sgallagh> Ok, so I guess the FESCo question should be: is addressing these issues a pre-requisite for installation on LVM thinp.
18:51:05 <pjones> sgallagh: I mean, I see what you're saying, but to me this really sounds like an unrelated, system-wide bug we've got
18:51:11 * nirik nods. I guess I'm ok with asking them to coordinate with other folks to try and come to some handling of things... but I don't think there's some magic 'solution' probibly.
18:51:13 <sgallagh> What I'm hearing is "no", but I wanted that to be discussed
18:51:15 <notting> *shrug*. df starts returning shades of red instead of numbers.
18:51:27 <pjones> where this thing - and not the change in question - triggers it
18:51:28 <mattdm> should it at least be in the release notes?
18:51:32 <poettering> i mean, the df value doesn't have to be 100% correct, but it should be useful as a rough estimate, and not off by 100% or so...
18:51:37 <mitr> proposal: Defer for 1 week and ask for more feedback on the mailing list.
18:51:52 <mitr> This discussion should have really happened on the mailing list.
18:51:53 <pjones> poettering: I don't disagree, but I'm having trouble making this related to the change in question.
18:51:56 <notting> mattdm: I can see more information in the install guide about "What ThinP Means For You And Why You Might Choose It"
18:52:00 <mmaslano> mitr: +1
18:52:06 <jreznik> mitr: +1, do you want to ask for system wide?
18:52:08 <mitr> I'm not decided that this can't be a installer-only self-contained change, but it's not an obvious thing.
18:52:08 <notting> after all, in anaconda it's just five letters that you hope the user understands.
18:52:14 <sgallagh> mitr: You're probably right, but I didn't think of it until now :0/
18:52:18 <nirik> sure, I'm ok with getting more feedback from change owners...
18:52:28 <mitr> sgallagh: Yeah, I didn't see the implications either :(
18:52:38 <t8m> mitr, +1
18:52:53 <abadger1999> notting: +1
18:53:11 <pjones> I guess my point is: why do you think dlehman is going to have opinions that are meaningful about what df does on a full disk?  that's *completely unrelated* to the work he's doing.
18:53:47 <mmaslano> sgallagh: I guess you want to list your concerns on fedora-devel in thread related to thinp
18:53:49 <pjones> it's like playing round robin on thesis defense day.
18:53:53 <mitr> pjones: Other people can (and some should) have opinions, and those are directly related to whether we want to expose this in the installer now or not.
18:54:36 <sgallagh> mitr: For the record, I *do* want this in the installer in F20 for my own reasons, but I want to make sure it doesn't provide an unacceptable user experience in the process.
18:54:36 <mmaslano> more votes for postponing voting to next week?
18:54:58 <mitr> sgallagh: It's about the same for me.
18:55:01 <pjones> sgallagh: and again, the user experience for most users is unchanged - they still have to select it
18:55:27 <notting> i'm -1 to postponing. i'd prefer if it's in anaconda, it be documented in a way that the user can make sense what to choose. but that's not the feature being debated.
18:55:59 <sgallagh> notting: I think I agree with that
18:56:01 <mitr> pjones: I'd like to target a higher level of quality than "only precisely the defaults work well".
18:56:37 <pjones> mitr: there's no objection based on "we don't think it will work", nor would that be entirely appropriate at this time anyway
18:56:57 <pjones> we think it will work, and some people here are concerned that the users may be confused *by* thin provisioning
18:57:39 <mattdm> +1 to docs.
18:57:42 <sgallagh> pjones: I think I understand what you've been saying now.
18:57:46 <pjones> the df behavior, and what poettering has said we should be concerned about, are real concerns, but they're not concerns with "can users install what they want correctly and have it work"
18:58:00 <sgallagh> #proposal Accept LVM thinp as a features and treat usability issues as bugs to be worked out
18:58:11 <sgallagh> s/feature/Change/
18:58:11 <nirik> sure, +1.
18:58:53 <pjones> that seems like a reasonably good compromise
18:58:54 <pjones> +1
18:58:59 <t8m> sgallagh, +1
18:59:03 <notting> addendum: change documentation from N/A to 'please document in install guide'?
18:59:07 <mmaslano> +1
18:59:07 <mitr> sgallagh: I'd be +1 with the addendum to call out for the respective maintainers to really take a look, not just wait for bug reports
18:59:22 <t8m> notting, +1 to addendum
18:59:22 <sgallagh> mitr: agreed
18:59:28 <abadger1999> +1
18:59:31 <mitr> sgallagh: I can take the action to ask on fedora-devel
18:59:34 <pjones> mitr: I think that's also reasonable, but again it's detached from this change itself
18:59:40 <sgallagh> notting: Also agreed to doc update
18:59:50 <sgallagh> mitr: Thank you
18:59:56 <mmaslano> #action mitr will ask for actions related to thinp on fedora-devel
19:00:39 <mmaslano> #agreed ccept LVM thinp as a features and treat usability issues as bugs to be worked out, change documentation from N/A to 'please document in install guide' and speak to maintainers of tools like coreutils (+7,-0)
19:00:48 * notting was +1
19:01:08 * mattdm also +1
19:01:31 <mmaslano> #undo
19:01:31 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x19b89e90>
19:01:49 <mmaslano> #agreed accept LVM thinp as a features and treat usability issues as bugs to be worked out, change documentation from N/A to 'please document in install guide' and speak to maintainers of tools like coreutils (+9,-0)
19:01:54 * mmaslano hopes it's all
19:02:08 <pjones> well, +10 would be strange.
19:02:18 <mmaslano> pjones: funny
19:02:22 <mmaslano> abadger1999: Rails?
19:02:31 <mmaslano> abadger1999: do you have any proposal?
19:03:06 <abadger1999> mmaslano: I think something should be added about the packages in the distribution that rely on rails.
19:03:27 <abadger1999> The application packages, I mean -- I think that the Change Owners have teh Rails stack packages covered.
19:03:32 <mitr> Looking at F19 repoquery, there are a few plugins but not applications
19:04:01 <abadger1999> mitr: Hmm... On list I thought people mentioned two or three.
19:04:32 <mitr> abadger1999: you're right
19:04:37 <nirik> "There is openshift-broker and console."
19:04:51 <abadger1999> https://lists.fedoraproject.org/pipermail/devel/2013-July/186016.html  <nod>
19:05:32 <mattdm> I hope we don't break openshift.
19:06:15 <nirik> so, make system wide and coordinate with those app owners? or just ask them to coordinate? or ?
19:06:27 <mmaslano> mattdm: I wouldn't worry, Vit is speaking to OpenShift people
19:06:28 <mitr> Given that at least rubygem-openshift-origin-auth-remote-user is not owned by the Change Owners, I think the case for system-wide is clear enough.
19:06:32 <abadger1999> nirik: yep.  The former is what I was thinking.
19:06:32 <pjones> mattdm: I think openshift probably has some people who maybe somebody who works on cloud stuff could involved here to make sure their interests are represented/attended to? ;)
19:06:42 <pjones> could /get/ involved.
19:07:01 <mitr> In practice, "mark system-wide" and ask to coordinate I think.
19:07:06 <mitr> (and approve anyway?)
19:07:08 <jreznik> if it's coordinated by owner, it could stay self contained but I'd like to see stated it in the change page itself
19:07:22 <mattdm> +1 mitr
19:07:31 <t8m> +1 to mitr as well
19:07:31 <mitr> jreznik: right, "mark system-wide or add co-owners to cover the users"
19:07:34 * nirik is +1 to mitr's proposal
19:07:35 <abadger1999> +1 mitr
19:07:40 <sgallagh> +1 mitr
19:07:40 * pjones +1
19:07:45 <mmaslano> +1 mitr
19:07:45 <mattdm> I think in practice language stack changes are almost always going to be systmewide
19:07:59 * notting is +1 to that
19:08:21 <mattdm> at least until we have some mechanism to decouple them. :)
19:08:24 <pjones> mattdm: yeah, I think so too
19:08:32 <abadger1999> mattdm: agreed
19:08:45 <mitr> mattdm: For the major languages at least.
19:08:55 <mmaslano> #agreed Rails feature will be changed to system wide. It will be needed cooperation at least with OpenShift (+9,-0)
19:09:19 <mmaslano> same question for gnome
19:09:59 <sgallagh> mmaslano: Do we have anyone from the GNOME team around to answer whether 3.10 is going to make any important GTK/GLib changes?
19:10:03 <jreznik> mmaslano: for gnome I explained it in the ticket - one idea was to give sigs more power and it's now about trust - if they misuse it or not
19:10:09 <mmaslano> #action jreznik Rails must be changed to system wide
19:10:25 * nirik doesn't think gnome 3.10 needs to be system wide, based on the changes page anyhow.
19:10:36 <mmaslano> same with Ruby SIG, but ok
19:10:42 <mitr> mmaslano: the GNOME feature doesn't list affected packages precisely enough "is gtk in scope"?) so it is unverifiable
19:11:23 <mmaslano> mitr: so feature wrangler did a bad job ;-)
19:11:24 <nim-nim> mitr: the next gtk kills middle-click cut and paste
19:11:25 <sgallagh> Yeah, that's my concern: is it likely that GTK might introduce a backwards-incompatible change?
19:11:40 <sgallagh> nim-nim: That's a bad joke, right?
19:11:40 <nim-nim> mitr: someone is going to notice
19:11:45 <mattdm> nim-nim wait what?
19:11:52 <abadger1999> *shudder*
19:11:53 <nim-nim> disabled by default
19:12:00 <mitr> nim-nim: horrible but not an API change so let's keep it _out of this meeting please_
19:12:01 <t8m> nim-nim, really? What a fun :D
19:12:07 <pjones> Fedora is about freedom to make bad decisions.
19:12:16 <pjones> so go ahead ;)
19:12:25 <sgallagh> pjones: I disagree with that statement in its entirety
19:12:30 <nim-nim> https://wiki.gnome.org/Terminal/FAQ
19:12:31 <mitr> Pragmatically speaking, someone has spoken up for Rails; nobody has spoken up for GNOME?  Also GNOME is still better in API stability than Rails
19:12:32 <pjones> sgallagh: you have been trolled
19:13:09 <nirik> proposal: approve gnome-3.10 as self contained unless/until changes that would affect system wide are noted.
19:13:19 <t8m> nirik, +1
19:13:19 <pjones> nirik: +1
19:13:23 <mitr> To be absolutely sure, can we list them?
19:13:24 <sgallagh> nirik: +1
19:13:39 <sgallagh> mitr: List what?
19:13:44 <nirik> mitr: I poked around https://wiki.gnome.org/ThreePointNine/Features and didn't see much that looked system wide.
19:13:58 <mattdm> changing gtk's behavior would change it in all desktops, right?
19:14:06 <mitr> Vagrant, GNOME 3.10, DNSSec for FreeIPA, snapshot/rollback, transitive trusts, Enlightenment, X12go, sguar, sssd smart card, acpica, devassistant GUI, RBAC with libvirt, CIFS plugin, FreeIPA OTP, Ryu, plasma-nm, isn't it?
19:14:09 * jreznik could ask for more details in the change page
19:15:02 <abadger1999> mattdm: The config file, at least, looks like it's global to all gtk apps and irregardless of environment being run under.
19:15:15 <mitr> jreznik: I'm +1 to approving anyway, but for the future I'd really like the feature page to allow precisely determining which packages would be affected if possible.
19:15:25 <mmaslano> +1
19:15:26 * mitr should have called that out on the mailing list as well
19:15:49 <pjones> abadger1999: I think probably that means we should document that in release notes?  I know a lot of developers are used to that behavior
19:15:54 <mitr> +1 to nirik re: gnome 3
19:15:59 <pjones> abadger1999: where "that" means: which config file and how to change it back
19:16:21 <nirik> pjones: +1
19:16:30 <abadger1999> pjones: could be -- or switch the behaviour by default on Fedora installs so that cut and paste doesn't differ between apps?
19:16:43 <sgallagh> pjones: Actually, I'd like to go so far as to vote on whether we should force that to be un****ed in Fedora.
19:16:44 <abadger1999> I don't know the right answer really...
19:16:46 <pjones> abadger1999: ewwww.
19:17:11 <pjones> sgallagh: well, you're free to make proposals with meekly hidden swear words in them ;)
19:17:19 * abadger1999 just remembers the days before cut and paste was standardized across Linux GUI systems.
19:17:50 <mmaslano> it seems to be wrong to me, but anyway
19:18:13 <mmaslano> #agreed GNOME 3.10 feature is approved as it is proposed (+6,-0)
19:18:27 <sgallagh> Proposal: Accept GNOME 3.10 but mandate that cut&paste be restored to proper working order by default in Fedora.
19:18:34 <pjones> I mean, I don't like that particular change, but on other similar issues we've had before, fesco's line has pretty much been: feel free to become one of the $x maintainers so you can make decisions for them
19:18:35 <mmaslano> :)
19:18:55 <pjones> I think this is only different because a lot of people on fesco, myself included, think it's a silly thing to change
19:19:13 <mitr> I basically think we've gone so far down the path of letting GNOME do various things we / some of us don't like, that choosing middle-click to make a point is... pointless.
19:19:29 <pjones> it's a gnome behavioral change, but it's not critical to the distro or to gnome working with other software or any of the things that typically *are* our business.
19:19:42 <sgallagh> mitr: On the other hand, it's probably about time we take a stand against GNOME making decisions that drive even more people away from Fedora.
19:19:44 <pjones> mitr: indeed.
19:20:05 <pjones> sgallagh: and what would that be?  having something else as the "desktop" spin?
19:20:12 <t8m> sgallagh, if it affects all desktops and not only GNOME, then I am +1
19:20:16 <mitr> I'd be very much +1 to an #info item, but not to forcing the projet at this point.
19:20:18 <sgallagh> That particular behavior is so ingrained in so many of us that if I hadn't been told right now that it's possible to switch it back, I would immediately get pissed and switch desktops.
19:20:25 * nirik thinks we are off in the weeds.
19:20:35 <sgallagh> t8m: It affects any app relying on GTK
19:20:41 <nirik> gtk3 that is. ;)
19:20:49 <pjones> sgallagh: I mean, if you're going to do that, I'd recommend that instead of taking that stand in fesco, you go ask the gnome maintainers to split it out so it can be decided on a per-desktop basis
19:20:49 <mattdm> t8m: it will affect xfce
19:20:49 <mmaslano> sgallagh: I agree
19:20:50 <t8m> sgallagh, I understand that so +1
19:20:55 <nirik> mattdm: nope
19:20:59 <mitr> sgallagh: I'm very open to being persuaded in that direction, but I'd like to see more than a single-sentence proposal made in anger during a FESCo meeting :)
19:21:04 <mattdm> especially as xfce goes to half gtk3
19:21:10 <mattdm> nirik why not?
19:21:12 <sgallagh> I'm not angry, I'm exasperated :)
19:21:19 <mitr> sgallagh: Also see our earlier conversations re: Fedora being design-led.
19:21:20 <nirik> Xfce is gtk2 currently.
19:21:26 <nirik> unless they are  backporting that
19:21:34 <mattdm> nirik: http://wiki.xfce.org/releng/4.12/roadmap/gtk3
19:21:44 <nirik> yeah, thats kinda fiction. ;)
19:21:46 <mmaslano> sgallagh: cool new word, anyway I'd rather solve it as a different ticket
19:22:07 <nirik> mattdm: see the schedule thats... long past. ;)
19:22:34 <nirik> mattdm: anyhow, yes, that could be the case down the road, but will not be for f20 at least
19:22:41 <mmaslano> do you want to discuss any other feature?
19:22:47 <mattdm> nirik okay. :) it may be that forking is basically the only way to stay sane for non-gnome desktops. but anyway, yes, far in the weeds
19:22:48 <pjones> fwiw mate is also gtk2 AFAICS
19:23:01 <mattdm> +1 to what mmaslano said re make this issue separate
19:23:26 <sgallagh> pjones: It's not just the desktop itself though, many users use GTK3 apps
19:23:33 <sgallagh> e.g. Gimp
19:23:50 * mattdm would also like to fix the insane flipping of right and left mouse clicks in gtk3 scrollbars. gah.
19:23:50 <pjones> do people often middle-click to paste in to gimp?
19:23:53 <sgallagh> Or better: Mozilla Firefox
19:23:54 * nirik sees we are 1.5 hours into the meeting and haven't even gotten to the hot button features. ;)
19:24:17 <mmaslano> #proposal approve all other features, where no concerns were raised: Vagrant, GNOME 3.10, DNSSec for FreeIPA, snapshot/rollback, transitive trusts, Enlightenment, X12go, sugar, sssd smart card, acpica, devassistant GUI, RBAC with libvirt, CIFS plugin, FreeIPA OTP, Ryu, plasma-nm
19:24:21 <sgallagh> pjones: Firefox and Thunderbird are pretty ubiquitous
19:24:27 <nirik> mmaslano: +1
19:24:34 <sgallagh> mmaslano: +1
19:24:50 <mattdm> mmaslano: +1
19:24:54 <pjones> mmaslano: +1
19:24:56 <mitr> sgallagh: and use gtk2 (for now?)
19:25:00 <mitr> mmaslano: +1
19:25:03 <mmaslano> +1 to my proposal
19:25:07 <abadger1999> mmaslano: +1
19:25:18 <notting> mmaslano: +1
19:25:39 <t8m> +1
19:25:43 <mmaslano> #agreed following features are approved: Vagrant, GNOME 3.10, DNSSec for FreeIPA, snapshot/rollback, transitive trusts, Enlightenment, X12go, sugar, sssd smart card, acpica, devassistant GUI, RBAC with libvirt, CIFS plugin, FreeIPA OTP, Ryu, plasma-nm (+9,-0)
19:25:58 <mmaslano> #topic #1141     F20 System Wide Change: Allow kdump on secureboot machines - https://fedoraproject.org/wiki/Changes/Kdump_with_secureboot1140
19:26:03 <mmaslano> .fesco 1141
19:26:04 <zodbot> mmaslano: #1141 (F20 System Wide Change: Allow kdump on secureboot machines - https://fedoraproject.org/wiki/Changes/Kdump_with_secureboot) – FESCo - https://fedorahosted.org/fesco/ticket/1141
19:26:20 <drago01> sgallagh: fwiw gimp is not a gtk3 app
19:26:38 <pjones> my biggest worry with this is if it will be ready in time.
19:27:15 <sgallagh> Sorry, I thought they had moved to gtk3. My mistake.
19:27:20 * nirik is ok with this one.
19:27:27 <mitr> I'm really not thrilled about IMA, but, I think I can live with it in this non-default feature.
19:27:29 <nirik> if it isn't ready, punt to next
19:27:39 <pjones> nirik: *nod*
19:27:50 <abadger1999> nirik: Agreed
19:27:57 <abadger1999> +1 from me
19:28:00 <t8m> +1
19:28:00 <mattdm> pjones contingency plan is basically that, right? does the timing seem reasonable?
19:28:03 <pjones> mitr: yeah... I wasn't terribly happy about it using ima at all as well
19:28:29 <pjones> mattdm: well, I suspect vivek is trying hard to get it in here because it's a requirement for RHEL 7 and he wants to have it here first, like one does
19:28:50 * mattdm nods
19:29:04 * notting is +1, i guess
19:29:08 <sgallagh> I'm +1
19:29:14 <mitr> (So +1 from me)
19:29:19 <pjones> but there's also a lot of infrastructure differences it'll rely on
19:29:24 * pjones is +1 as well
19:29:31 <mattdm> in that case i'm +1 too
19:29:49 <pjones> but that means infra people may need to be involved in infra changes, and more people involved = slower
19:30:14 <pjones> so anyway, like I said, I'm for it, but I'm concerned about timing
19:30:50 <mmaslano> #agreed F20 System Wide Change: Allow kdump on secureboot machines was accepted (+6,-0)
19:31:05 <mmaslano> #topic #1142     F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin - https://fedoraproject.org/wiki/Changes/NoBinDeps
19:31:10 <mmaslano> .fesco 1142
19:31:11 <zodbot> mmaslano: #1142 (F20 System Wide Change: Change Packaging Guidelines to discourage requires into /bin and /sbin - https://fedoraproject.org/wiki/Changes/NoBinDeps) – FESCo - https://fedorahosted.org/fesco/ticket/1142
19:31:12 <mitr> pjones: If infrastructure has concerns, I'd like them to speak up on the mailing list during the comment period
19:31:39 <pjones> mitr: yeah - maybe we should be sure they understand they'll be asked to do something
19:32:01 <mitr> pjones: It's in the announcement mail, that should be ("in the ideal case") good enough
19:32:17 <pjones> mitr: the spherical cow is strong in you
19:32:31 <mitr> Re: /bin Requires: I don't think this makes sense as proposed, but I'm glad we can get the packaging actually thought through, and it seems the FPC is trying to do that.
19:32:31 <nirik> I'm happy to work with folks to get things done... if it is too much work, we punt to 21. ;)
19:33:22 <mitr> (For more context, this was apparently motivated by https://bugzilla.redhat.com/show_bug.cgi?id=982664 )
19:33:45 <abadger1999> mitr: <nod>  I made a packaging draft to reverse the prohibition on using /bin/FILE in packages which is kind of hte opposite of what the submitter wanted but it should make the guidelines more consistent in the end.
19:34:12 <abadger1999> FPC was one short of quorum last week so we didn't get to discuss/vote on which direction to take, though.
19:34:34 <nirik> so, we are waiting for FPC? or they are waiting on us?
19:34:53 <notting> wouldn't it just be "move stuff to /usr/{bin,sbin} ; if your package used to install to a separate /{bin,sbin}, provide the old path"?
19:35:04 <t8m> abadger1999, could you consider making a list of packages that can contain /bin/FILE and disapprove otherwise?
19:35:55 <abadger1999> nirik: fpc needs quorum to move on so I don't think they're waiting on fesco atm.
19:36:25 <mitr> t8m: Or, instead of a list, just mandate that new packages shouldn't ship anything in the non-/usr paths?
19:36:46 <abadger1999> t8m: rather than keeping a list, I'd rather let package maintainers just do the right thing.
19:36:57 <mitr> Anyway, proposal: Defer to FPC figuring out the right thing to do here, reevaluate if this needs to be handled as a Change then.
19:37:03 <t8m> abadger1999, what's the right thing? :D
19:37:12 <t8m> mitr, +1
19:37:16 <mmaslano> mitr: +1
19:37:53 <pjones> mitr: +1
19:38:18 <abadger1999> t8m: That's got a long explanation ;-)  Here's my draft if you're interested in giving feedback to FPC: https://fedoraproject.org/wiki/User:Toshio/Effect_of_UsrMove
19:38:20 <abadger1999> mitr: +1
19:38:27 <notting> mitr: +1, i suppose.
19:38:28 <nirik> +1
19:38:45 <mmaslano> #agreed Defer to FPC figuring out the right thing to do here, reevaluate if this needs to be handled as a Change then. (+6,-0)
19:38:55 <mmaslano> #topic #1143     F20 System Wide Change: No Default Sendmail - https://fedoraproject.org/wiki/Changes/NoDefaultSendmail
19:38:56 * abadger1999 could consider nottings -- when in doubt, use both as well... have to think about that.
19:39:00 <mmaslano> .fesco 1143
19:39:02 <zodbot> mmaslano: #1143 (F20 System Wide Change: No Default Sendmail - https://fedoraproject.org/wiki/Changes/NoDefaultSendmail) – FESCo - https://fedorahosted.org/fesco/ticket/1143
19:39:15 <mitr> Nice, some excitement.
19:39:29 <mitr> First of all, I don't think these things are as important as middle-click :)
19:39:37 <mattdm> +1 mitr :)
19:39:46 <nirik> I'm +1 to this change.
19:39:52 <t8m> abadger1999, where should I put the feedback? I mostly agree with your proposal, but I'd shift it just slightly towards /usr/...
19:39:53 <mitr> Second, the real change here is treating "cloud" as "the measure for deciding what should be the default", which is... fairly new.  Are we doing it?
19:39:57 <abadger1999> mitr: +1 ;-)
19:40:15 <notting> mitr: 'default'? what's a default?
19:40:19 <sgallagh> I'm also +1 to this change. I want to see what breaks, because if it was relying on sendmail it was broken by design IMHO
19:40:21 <abadger1999> t8m: FPC ticket would be best.  Or packaging mailing list if it will likely lead to a long discussion.
19:40:33 <t8m> -1 to removal of sendmail from standard, +1 to removal from core
19:40:50 <notting> mitr: the only reason we have a default in anaconda is because there were complaints about making users select something.
19:40:54 <mitr> notting: "whatever this Change is proposing to change"?  "Expectations from "Linux"?
19:41:13 <pjones> notting: and also anaconda doesn't really want that much to do with package selection anyway
19:41:39 <t8m> also I'd support replacing sendmail with postfix in standard
19:41:46 <mattdm> mitr -- the 'how important is cloud' got its own change. https://fedoraproject.org/wiki/Changes/VisibleCloud
19:41:49 <mitr> notting: "cloud needs to save disk space" is an argiument that is exponentially loosing importance over time.
19:42:00 <t8m> mitr, +1
19:42:12 <mattdm> mitr: citation needed.
19:42:26 <mitr> mattdm: moore's law
19:42:39 <pjones> this is an incredibly bad argument for us to have
19:42:46 <drago01> mitr: has nothing to do with storage
19:42:50 <notting> t8m: ugh, standard is an even bigger mess than core
19:43:09 <mitr> I'll echo t8m I think, 1 to removal of sendmail from standard, +1 to removal from core
19:43:22 <mattdm> right, so part of my big overall proposal, and mitr's work, is about making that less of a mess.
19:43:35 <mmaslano> +1 to removal from core
19:43:48 <mattdm> I'm in favor of making a better defined "base design", and I'm willing to consider an mta being part of that
19:44:14 <mattdm> so I'm basically a strong +1 to removal from @core and 0 on what happens in @standard.
19:44:15 <mitr> drago01: Storage is the very first thing in the "benefit to Fedora" section.
19:44:20 <nim-nim> mattdm: de-duplication
19:44:37 <drago01> mitr: I meant moore's law isn't really about storage
19:44:41 <mattdm> nim-nim hard to do across the network.
19:44:58 <pjones> mitr: mattdm: drago01: you guys are in some serious weeds.
19:44:59 <mattdm> plus small is a strong marketing point.
19:45:07 <mattdm> pjones ack
19:45:08 <sgallagh> I'm a strong +1 on removal from @core and a weak +1 on removal from standard.
19:45:12 * abadger1999 mostly agrees with mitr's arguments for /usr/sbin/sendmail being a de facto "api" under unix but also understands the argument that /usr/bin/sendmail is a poor api
19:45:13 * nirik just thinks it's useless
19:45:30 <nim-nim> mattdm: all the vms the cloud is build from are going to be on de-duped storage
19:45:37 <mmaslano> #agreed sendmail will be removed from @core (+6,-0)
19:45:40 <drago01> abadger1999: if it is api anything that needs it should require it
19:45:41 <abadger1999> Definitely would vote +1 for removal from core
19:45:43 <notting> /usr/{lib,sbin,bin}/sendmail isn't even on the lsb
19:45:47 <mitr> abadger1999: Well, with SMTP error reproting is always iffy.  I'm not sure how much that can be really improved over /usr/sbin/sendmail
19:45:49 <nirik> the storage argument seems strange to me.
19:45:49 <notting> mmaslano: i'm +1, fwiw
19:45:56 <mmaslano> #undo
19:45:56 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x1776a450>
19:46:11 <mmaslano> #agreed sendmail will be removed from @core (+8,-0)
19:46:56 <nirik> so, not enough votes to remove from standard?
19:47:02 <abadger1999> I guess at this moment, I'd vote to keep it in standard.
19:47:15 <nirik> bummer.
19:47:16 <mattdm> where does the vote on that stand?
19:47:25 * nirik is +1 to remove from standard.
19:47:27 <mmaslano> mattdm: not sure
19:47:34 <pjones> mmaslano: I'm actually +1 to that as well
19:47:41 <pjones> sorry for the delay in saying so
19:47:49 <mmaslano> pjones: don't sleep, it's night here
19:47:53 <mmaslano> #undo
19:47:53 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x1776a7d0>
19:47:58 <mmaslano> #agreed sendmail will be removed from @core (+9,-0)
19:48:14 <mmaslano> -1 to remove from standard
19:48:18 <sgallagh> I'm +1 to remove from standard
19:49:34 <pjones> what's the implication for removing from standard?  many MUAs still require some sort of local spooling MTA, even if it's smarthost only, don't they?
19:49:46 <pjones> or has that gotten to be less true since last time we had this discussion?
19:49:47 <notting> pjones: 'every spin includes standard'. *shrug*
19:50:22 <notting> so, in essence, removing it from core removes it *only* from the minimal install
19:50:31 <pjones> bah, sure, +1
19:50:34 <abadger1999> weak -1 to remove /usr/sbin/sendmail from standard.  I don't care what package implements that.  Could change my mind by F21.
19:51:01 <nirik> most mua's are configured to use a providers smtp server...
19:51:04 <nirik> or are web based.
19:51:05 <t8m> notting, and that's what I'd like to implement :D
19:51:31 <mattdm> I'm 0 but I'd like to see either some serious proposal for a "base design" or see it out by f21, with removing it from @core being a test case and careful approach
19:51:32 <pjones> removing it from minimal does appear to be the real goal here
19:51:34 <nirik> it's pretty useless for most of our users... but whatever
19:51:58 <pjones> nirik: there's a pretty big "steaming pile" factor there as well though.
19:52:17 * sgallagh lost track of the count. Where are we?
19:52:19 <nirik> not sure what you mean...
19:52:22 <sgallagh> (And who has not voted?)
19:52:58 <pjones> right now we're -mmaslano, +me, +nirik, +sgallagh
19:52:58 <abadger1999> sgallagh: +2:-2, mmaslano, sgallagh, pjones, abadger1999 have voted
19:53:00 <pjones> I think?
19:53:13 <notting> i think @standard is a pile of crap that's not particularly useful. so i'm +1 to removing sendmail from it on that principle, but could also be persuaded to not do that now in favor of more extreme measures later.
19:53:14 <t8m> -1 as I said above to removal from standard
19:53:15 <pjones> oh, -abadger1999 as well, weakly.
19:53:19 <nirik> right now, sendmail is installed. It can't really send out very well anymore, it spools mails to /var/spool/mail/root where no one looks for them, and otherwise takes up space and makes things less secure, and slows down boot on dns issues, etc.
19:53:25 <mitr> -1 to standard (repeating)
19:53:31 <pjones> okay, so -4 +3
19:53:51 <abadger1999> notting: yeah, I hold out hope that mattdm's Ring 1 will do something for the @standard situation...
19:54:13 <t8m> -5 +3 so that's it I think
19:54:30 <t8m> or do I count wrong?
19:54:52 <t8m> I do
19:55:09 <sgallagh> Perhaps we should just revote?
19:55:19 <t8m> sgallagh, mattdm is 0
19:55:22 <sgallagh> +1
19:55:24 <abadger1999> nirik and mattdm are the outstanding votes.
19:55:31 <pjones> abadger1999: notting, not nirik
19:55:37 <nirik> I am again +1 to removing it from standard.
19:55:46 <mmaslano> -1
19:55:50 <t8m> -1
19:55:54 * notting is again +1
19:55:57 <abadger1999> -1
19:56:02 <pjones> it's 4:4:1
19:56:11 * sgallagh facepalms
19:56:13 <pjones> which is: does not pass
19:56:15 <abadger1999> pjones: yep.
19:56:32 <sgallagh> Unless mattdm has changed his mind one way or the other
19:56:42 <mmaslano> I guess we will postpone it for next release of Fedora and the whole group could change in future
19:56:54 <t8m> mmaslano, +1
19:57:03 <mattdm> I did not want this to come down to me :)
19:57:08 <pjones> sucker.
19:57:26 <mmaslano> I guess it doesn't pass, so move on to more interesting topics
19:57:26 <BCrookAtRA> -1 to remove from standard/default
19:57:34 <abadger1999> <nod>  The group can change, the Ring 1 proposal could change how we look at things, lots of things could affect this decision for next release.
19:57:41 <mmaslano> BCrookAtRA: please do not vote, it's a mess already
19:57:44 <t8m> perhaps we should not do such changes on such a split vote
19:57:48 <drago01> mattdm: you are +0 on your own feature?
19:57:57 <pjones> drago01: @standard, not @core
19:58:01 <notting> i suppose punting any decision to s/sendmail/somethingelse/ is also best
19:58:28 <mattdm> drago01 As noted above -- I'm listening to mitr's argument and willing to take a careful approach.
19:58:58 <nirik> ok, then shall we move on?
19:59:01 <abadger1999> BCrookAtRA: You're welcome to express your opinion in the fesco meeting but only fesco member votes will be tallied for the final result so it's best not to use an actual "+Number, -Number" so as not to confuse people.
19:59:08 <mmaslano> #agreed removal of sendmail from @standard didn't pass (+4,-4,0)
19:59:08 <poettering> mattdm: jeez man. 0 on your own feature?
19:59:09 <pjones> well, it didn't pass, with the decision essentially being to defer this until F21
19:59:17 <mmaslano> #topic #1144     F20 System Wide Change: No Default Syslog - https://fedoraproject.org/wiki/Changes/NoDefaultSyslog
19:59:23 <mmaslano> .fesco 1144
19:59:24 <zodbot> mmaslano: #1144 (F20 System Wide Change: No Default Syslog - https://fedoraproject.org/wiki/Changes/NoDefaultSyslog) – FESCo - https://fedorahosted.org/fesco/ticket/1144
19:59:25 <poettering> what a fuckup
19:59:27 <mitr> (FYI, I'm not planning to propose any radical redesign of tier 1 on Flock - mostly just better administration of the kind of decisions we've been already making, plus better delineation.
19:59:34 <mattdm> poettering I know, right? I want to see it for F21 though and core now.
19:59:39 <mitr> A radical redesign would start with moving away from C and I'm not proposing that.)
19:59:46 <BCrookAtRA> abadger1999: noted. I am quite negative one on this one, as well
20:00:10 <poettering> mattdm
20:00:13 <mattdm> I think there things in progress for better alerting and notification that will be in better shape by then too
20:00:52 <poettering> i am pretty sure i am not going to submit anything with you again if you are this unsure about the stuff you push
20:01:00 <nirik> so, on this one... I see changes for applications reading messages are noted... is there expectation that they will be 'fixed' in some way if this change is approved?
20:01:21 <sgallagh> poettering: I think that's a bit unnecessary. Different people have different opinions on things.
20:01:25 <mitr> poettering: 8 people had a clear vote, and a feature submitter decided to abstain.  What exactly would you want different?
20:01:25 <mattdm> poettering I like to listen to the reasonable things people have to say.
20:01:33 <sgallagh> poettering: And you will note that he was +1 on removal from @core
20:02:37 <pjones> I'm pretty sure we don't need a discussion about mattdm's voting here and now.
20:02:40 <nirik> ie, did we come up with a way to express that a package needs messages file and is that part of this proposal?
20:02:43 <t8m> pjones, +1
20:03:04 <mitr> nirik: I'd hope so, though I probably wouldn't want to make a F20 blocker out of it
20:05:07 <sgallagh> poettering: Is it absolutely impossible for journalctl to output to /var/log/messages and /var/log/secure?
20:05:35 <nirik> sgallagh: sure... 'yum install rsyslog...'
20:06:05 <pjones> sgallagh: the counter argument being that if you want that, you don't want journald/journalctl
20:06:06 <sgallagh> I like and use journalctl myself, but sometimes it's just easier to grep through /var/log/secure rather than remember the incantation to get journalctl to print only LOG_PRIVMSG
20:06:19 <mattdm> I would like for that to eventually be "yum install rsyslog-localfilesconf'
20:06:33 <mitr> *shrug*, I'll start the voting
20:06:36 <mitr> -1 1) plain text is useful for system recovery 2) disk space is cheap 3) if disk space and one more process were so important, journal wouldn't have been designed to result in such duplication in the first place
20:06:49 <mitr> mattdm: Cleaning that up would be very beneficial, yes.
20:07:24 <mmaslano> -1 according to list many people wouldn't be happy without /var/log/messages. mitr's comments were expressed there many times
20:07:30 <t8m> -1 as well
20:07:35 <mattdm> I'm +1 to this one. Logging in Fedora and in our downstream distribution has always been pathetic and this is the way forward
20:07:40 <sgallagh> Yeah, I'm -1 to losing /var/log/secure primarily
20:08:18 <sgallagh> I don't care one iota if rsyslog is the daemon producing these files.
20:08:47 <nirik> I'm kinda on the fence. If there was assurance that messages consuming packages would be fixed in some way to require rsyslog or the like, I would probibly be +1.
20:08:47 <sgallagh> If journald can be configured to output these, I'm fine with it replacing rsyslog in the default install with that configuration by default.
20:08:49 <notting> i am +1 to removing rsyslogd from the minimal/@core install.
20:08:52 <mattdm> sgallagh we are already in the state where journal is logging the authpriv data right with the rest
20:08:58 <notting> sgallagh: AARGH.
20:09:00 <mitr> sgallagh: I care only minimally - 90% of the rsyslog code isn't processed by the text-only-logs paths in our default install anyway
20:09:10 <notting> sgallagh: (re: 'default install')
20:09:10 <BCrookAtRA> It doesn't particlarly matter what prodices those files, but they need to be there, for at least another few years
20:09:29 <BCrookAtRA> journald's binary format is not a sufficient replacement for them
20:09:33 <nirik> so, does that mean some folks would support removing from core and moving to standard?
20:09:35 <drago01> it is
20:09:36 <sgallagh> BCrookAtRA: I agree
20:09:40 <pjones> BCrookAtRA: note that presence in @core is not really what's determining that
20:09:43 <sgallagh> That's the argument I'm trying to make.
20:09:47 <nirik> BCrookAtRA: or those things need a way to express that they need rsyslogd
20:09:50 <mattdm> I think it's pretty compelling that other distros do not write to /var/log/messages
20:10:18 <BCrookAtRA> journald's format is better in so many ways, but not in all, and particularly not in many practical ones
20:10:19 <sgallagh> mattdm: I think it's a nightmare every time I try to help someone debug something on Ubuntu and can't find the logs.
20:10:23 <mattdm> even distros like Rocks (very popular in HPC) don't follow that.
20:10:27 <t8m> mattdm, they have just different name for the file, that does not mean they do not have text logs
20:10:28 <BCrookAtRA> nirik: 'those things' are often, people
20:10:41 <mattdm> sgallagh I don't think we're going to convince them to switch to our way
20:10:42 <pjones> I've never been a big fan of either unstructured /var/log/messages or journald, but... honestly that has little to do with presence in @core, so I'm a weak +1 to removing it from there.
20:10:58 <sgallagh> mattdm: I'm not asking them to. I'm just saying that just because they're doing it, doesn't mean it's a good idea :)
20:11:18 <nirik> BCrookAtRA: well, you can't always just keep things the same way for all time. :) People do have to learn and move on.
20:11:23 <pjones> mattdm: a lot of log reading going on in the HPC space?  as opposed to "that node isn't working right reinstall it"?
20:11:24 <mattdm> sgallagh but it means that there is no "/var/log/messages is the defacto standard" argument.
20:11:26 <sgallagh> I'm -1 to any proposal that takes /var/log/messages and /var/log/secure out of @core.
20:11:29 <mitr> nirik: Re: removing from core... it's one line in a kickstart in any case, so I don't really care.
20:11:33 <notting> nirik: i could see there being some 'traditional unix daemons' groups that contains cron, mta, rsyslog, and put all those there.
20:11:45 <drago01> sgallagh: I can't remember how a tool works is a worse argument
20:11:50 <sgallagh> mattdm: I wasn't making that argument in the general case. Only that it's one of the things Fedora has actually gotten right.
20:11:57 <sgallagh> So changing it would be a regression in my opinion.
20:12:00 <mattdm> pjones sometimes you like to know how things broke :)
20:12:03 <pjones> mitr: and any particular spin can make it default if they think it's important, as well
20:12:10 <pjones> mattdm: sure, the second or third time ;)
20:12:11 <BCrookAtRA> nirik: agreed.  It's just not time yet.
20:12:27 <drago01> BCrookAtRA: why?
20:12:27 <mattdm> notting didn't there used to be one of those in ancient times?
20:12:39 <drago01> BCrookAtRA: other distros have already done it
20:12:55 <BCrookAtRA> core has to be maintainable by the least common denominator
20:13:18 <BCrookAtRA> drago01: this isn't other distro.  The fact that someone else has done something wrong, is amusing, but not relevant here
20:13:18 <notting> mattdm: there's a legacy-unix group in RHEL with a bunch of random stuff (talk, rwho, ksh, etc.)
20:13:18 <drago01> I have no idea what that means
20:13:19 <sgallagh> BCrookAtRA: The better explanation is that the binary format is difficult to handle if you're dealing with the hard drive outside of the running system
20:13:27 <BCrookAtRA> sgallagh: exactly
20:13:27 <mitr> pjones: I expect the default installation to be _useful for most_ with minimal tinkering.  @core always requires manual tinkering to get an useful system (unless you want to run arithmetics in shell only) so it's not that important there.
20:13:32 <pjones> BCrookAtRA: no, but their motiviations are relevant to whether it's wrong or not
20:13:44 <drago01> BCrookAtRA: the point is someone else did it and the world didn't end like you are claiming
20:13:45 <pjones> mitr: most people don't ever look at the log files at all, I suspect.
20:14:06 <BCrookAtRA> drago01: really?  I didn't hear myself say that
20:14:25 <sgallagh> mitr: Not having a plaintext log in @core would make it noticeably less useful for the exact set of people likely to run a minimal install
20:14:30 <BCrookAtRA> being the first at adding features is great.  Being the first at taking them away isn't
20:14:33 <BCrookAtRA> and its hardly necessary
20:14:34 <mattdm> sgallagh As tools become more available, less of a problem. (journal viewer backported to el6 would be huge; i have an rfe in for guestfish support)
20:14:58 <sgallagh> mattdm: Sure, and we can revisit this at such a time as those tools are actually readily available.
20:15:07 <BCrookAtRA> agreed
20:15:12 <pjones> sgallagh: that's a pretty good argument for journal viewer being on e.g. rescue images... not seeing how it effects @core that much
20:15:15 <sgallagh> Shutting off a useful feature before we have a sufficient replacement is unacceptable
20:15:22 * mmaslano thinks it's -4,+2 at the moment
20:15:23 <pjones> if you're doing analysis on another machine, you can install it if you need
20:15:29 <drago01> BCrookAtRA: "you" didn't mean you as person but you as in "the opposition on the list"
20:15:40 <mitr> sgallagh: At the same time, "minimal" does day "minimal".  I could see it either way.
20:15:42 <pjones> mmaslano: I count mattdm, notting, and myself as +1 to removing it from @core
20:15:57 <nim-nim> btw are the various bug reporting tools like libreport even capable of taking info from journald?
20:15:58 <mmaslano> so -4,+3
20:15:59 <abadger1999> Current vote: +3 (mattdm, notting, pjones):-4 (mitr, mmaslano, t8m, sgallagh):0()
20:16:06 <BCrookAtRA> drago01: ah.  k. well yes, some of the opposition is a bit dramatic.  But that doesn't invalidate all of the opposition
20:16:12 <mattdm> maybe we could do as before and split up the @core/@standard vote?
20:16:16 <nim-nim> you know, kerneloopses and such
20:16:17 <BCrookAtRA> it's just not practical to remove it yet.
20:16:19 <abadger1999> nirik and myself haven't voted yet.
20:16:22 <jmoskovc> nim-nim: not yet
20:16:30 <notting> sgallagh: sufficient replacement? you mean a 1-1 copy of the data on the disk? seems overkill, imo. but journalctl gives you the data in that format.
20:16:31 * nirik was 0 I guess, unless someone can assure me about the things that consume messages file better.
20:17:01 <nim-nim> jmoskovc: so the proposal is to remove infra before our own tools can deal with the fallout?
20:17:02 <mattdm> poettering: you still around?
20:17:08 <BCrookAtRA> and yes, that is one of the reasons I think $otherdistro is a mess
20:17:12 <nim-nim> jmoskovc: le alone third-parties?
20:17:20 * abadger1999 is 0 because text files are useful for recovery
20:17:27 <abadger1999> So that's everyone.
20:17:36 <t8m> did not pass
20:17:45 <jmoskovc> nim-nim: well, it souldn't be that hard to port it to use journald
20:17:54 <abadger1999> +1:3; -1:4; 0:2
20:18:12 <mmaslano> #agreed No Default Syslog didn't pass (+3,-4,2)
20:18:13 * nirik would say it would be great to work on tools and then re-propose for 21.
20:18:15 <notting> sgallagh: i guess i'm just curious what your definition of 'sufficient' is
20:18:16 <mattdm> nirik -- I didn't look at libreport, but in general, it's only a handful of things
20:18:27 <mattdm> mmaslano wait can we revote for just @core?
20:18:33 <Viking-Ice> since this got rejected can we set some goals that need to be done before this can be submitted again ( things that you feel the journal lacks ) along with somekind of strategy fixing the implementation of the logging in the distribution
20:18:38 <BCrookAtRA> I think 5 years is an optimistic goal for when it will be realistic
20:18:49 <sgallagh> BCrookAtRA: Not helpful
20:18:51 <mmaslano> mattdm: sure, give a proposal
20:18:54 <BCrookAtRA> this is also not something Fedora  alone can fix
20:19:29 * mmaslano would like to ask if we want to continue. Meeting already took 3.25 hours
20:19:30 <mattdm> proposal: remove rsyslog from @core, leave in @standard pending revaluation in future
20:19:38 <jreznik> Viking-Ice: +1
20:19:39 <Viking-Ice> I got a packing proposal in status qoue with FPC since they refuse to movie it forward since journal is not default but i feel we need to fix this regardless if the journal is default or not
20:19:43 <Viking-Ice> thanks
20:19:50 <sgallagh> notting: Hard to say. I'll admit to being a bit set in my ways. I have something that works 100% of the time I've needed to use it. I don't see a reason to turn it off.
20:20:09 <nirik> I think identifying and fixing items that consume legacy logs would be the top of my list, perhaps having a group of people run with no rsyslog and identify anything else that might break or need dependencies.
20:20:15 <BCrookAtRA> I'm especially negative one about this.  People who install core are even more likely to be the sorts of people who need plain text logging
20:20:33 <notting> mattdm: +1 to that (obvs, given earlier vote)
20:20:37 <mattdm> nirik I'm pretty sure I have identified most of them in the distro
20:20:51 <drago01> BCrookAtRA: no one really needs "plain text logging" ... people need log files
20:20:52 <sgallagh> nirik: That's a good idea. I'll even volunteer to do it.
20:20:57 <notting> BCrookAtRA: people that do the minimal install are the people least equipped to know what they expect from logging and configure their system appropriately? that seems backwards to me.
20:20:58 <mattdm> nirik removing from core is a good way to test.
20:21:00 <drago01> BCrookAtRA: the format is an implemenation detail
20:21:01 <nirik> mattdm: sure, but the change page just notes them, doesn't say "we will fix or remove or address all these" does it?
20:21:21 <t8m> mattdm, -1
20:21:24 <mattdm> nirik for most of them, it's "install rsyslog if you need this thing".
20:21:31 <nirik> anyhow, I guess I am +1 to move from core to standard.
20:21:47 <mitr> mattdm, mmaslano: I'd like to abstain + lower the quorum if possible
20:21:52 <mattdm> I'm +1 too, obviously :)
20:21:53 <nirik> mattdm: yes, but I want a better way to do that than 'yum install thing' and see that it errors.
20:21:53 <sgallagh> nirik: I'll spend the next couple weeks with rsyslog uninstalled and I'll do a write-up on my blog as to how the experience turns out.
20:22:06 <nirik> sgallagh: great
20:22:07 <BCrookAtRA> how reliably do packages that need that file  i.e. stuff like fail2ban to declare the requires?
20:22:15 <t8m> mitr, I don't think we have a rule on lowering the quorum
20:22:32 <sgallagh> Viking-Ice: At the end of that, I'll try to have a list of bugs/enhancements ready for you.
20:22:33 <nirik> BCrookAtRA: good question. It was discussed on the list... but I don't think there was a complete answer/consensus reached.
20:22:36 <mitr> t8m: I can procedurally vote with the winner if there is a majority
20:22:50 <t8m> mitr, yep, I wanted to propose that to you
20:22:59 <mmaslano> mattdm: I would postpone other topics until next week
20:23:09 <mmaslano> even this one
20:23:17 <BCrookAtRA> until there's confidence that things that have been requiring the files are actually packaged to say they do, that alone is a reason it should stay
20:23:29 <t8m> mmaslano, could we finish this topic?
20:23:31 <mitr> Viking-Ice: Several people expressed clear preference for text logs - you can either take that as a requirement or hope that they will change thier mind?
20:23:37 <mattdm> BCrookAtRA No, that's a reason to make the change and fix during alpha and beta!
20:23:37 <t8m> mmaslano, I'd be +1 to postponing the rest
20:23:43 <mmaslano> t8m: thanks
20:23:44 <mitr> s/for text logs/for having text logs/
20:24:03 <t8m> where we are with the vote for matt's proposal?
20:24:10 <mmaslano> mattdm: -1 at the moment
20:24:11 <Viking-Ice> mitr, well they could just write timer units to dump it to logs if they want or need text log files
20:24:20 <Viking-Ice> ( or cron job if you prefer )
20:24:32 <drago01> Viking-Ice: or just yum install $syslog-impl
20:25:11 <mitr> Viking-Ice: You asked what would be necessary for the proposal to pass, you got one possible answer.  Implementation is up to $whoever.
20:25:14 <abadger1999> +0 from me still.
20:25:15 * nirik guesses we don't have enough folks still around to continue?
20:25:25 <BCrookAtRA> I'd like to see journald write to those files, and satisfy $syslog-impl itself
20:25:31 <mmaslano> +3,-3,0 at the moment
20:25:52 <sgallagh> BCrookAtRA: I'd be happier with that as well, obviously configurable.
20:25:57 <Viking-Ice> sgallagh, thanks and please you all nudge that fpc to somekind of movement fixing that might actually identify some of the stuff that to fix
20:25:59 <BCrookAtRA> journald and syslog fulfil very similar objectives after all. it just needs to be more plugable and configurable
20:26:15 <Viking-Ice> mitr, so you suggest a community wide server of the journal?
20:26:23 <Viking-Ice> mean survey
20:26:39 <mmaslano> any more votes for mattdm proposal?
20:26:49 <BCrookAtRA> sgallagh: I think it's a very obvious solution to this.  journald simply assimilates the role of syslog
20:27:05 <Viking-Ice> mitr, to get an actual representation of the need for the text files
20:27:22 <mitr> Viking-Ice: Sorry, I mean the voting FESCo members.
20:27:32 <pjones> I'm sorry, what was the proposal?
20:27:37 <sgallagh> I'm -1 to removing from @core at this time, but I'm willing to defer a week or two while I perform my experiment
20:27:39 * pjones got pulled away and can't obviously find it in the scrollback
20:27:40 <BCrookAtRA> and for the first few years, the option to write those files is turned on, and their use is discouraged.  then at some point when its a small enough issue that nobody joins the fedora-devel mailing list just to fight it, the option gets turnedoff by default
20:27:44 <mattdm> proposal: remove rsyslog from @core, leave in @standard pending revaluation in future
20:27:50 <mitr> Viking-Ice: Obviously the larger development community matters for FESCo
20:27:52 <pjones> I can be +1 to that
20:27:58 <nirik> note that it's not in standard. so it's move actually. ;)
20:28:04 <pjones> right
20:28:17 <mmaslano> +4,-3,1
20:28:18 <mitr> mmaslano: So we are at +4:-3?
20:28:19 <mattdm> proposal: remove rsyslog from @core, move to @standard pending revaluation in future
20:28:33 <sgallagh> Eh, go ahead and switch me to +1
20:28:34 <mitr> I'll be procedurally +1 as promised
20:28:37 <abadger1999> I think that's +4, -3, 2 -- which would pass?
20:28:39 <notting> mitr: well, i suspect the presence or absence of /var/log/messages are an issue for the user/admin community. 99% (made-up stat!) of developers/software likely doesn't care
20:28:40 <mmaslano> -1
20:28:47 <abadger1999> (ie: 0 is the same as reduce quorum)
20:28:49 <Viking-Ice> I would like to propose the third option of leaving rsyslog installed but simply have it disabled what about simply disable rsyslog
20:28:59 <mitr> mattdm: Though I'll really _much_ prefer dropping the "pending revaluation in future" part, I have no intention on changing my mind on text logs.
20:29:09 <sgallagh> I suppose I can accept the argument that @core users would know to add it back in on their own
20:29:24 <BCrookAtRA> Viking-Ice: im curious how that is better than whats been discussed so far.
20:29:31 <mitr> Viking-Ice: now _that_ is a waste of space.
20:29:37 <t8m> I think we now got +5, -3, 0:1
20:29:39 <sgallagh> Yeah, seems like the worst of all worlds
20:29:55 <t8m> or even +6
20:30:02 <t8m> if sgallagh changed his mind
20:30:13 <sgallagh> Yeah, I'm okay with @standard
20:30:15 <BCrookAtRA> sgallagh: they of course would know how too,  but should it be there BEFORE they need it?
20:30:21 <mmaslano> #agreed remove rsyslog from @core, move to @standard pending revaluation in future (+6,-3,1)
20:30:24 <t8m> so let's declare victory and please close this meeting
20:30:27 <pjones> BCrookAtRA: no.
20:30:44 <mmaslano> #topic chair for next week
20:30:46 <t8m> mmaslano, that's +6, -2, 0:1
20:30:52 <BCrookAtRA> that's the problem with taking it out by default, if it's not logging a problem before it happens and provokes you to add it, you're painted into a corner
20:30:52 <pjones> BCrookAtRA: there's no reason it should be exceptional among the set of all packages.
20:30:53 <mmaslano> #undo
20:30:53 <zodbot> Removing item from minutes: <MeetBot.items.Topic object at 0x1880bc50>
20:30:57 <mmaslano> #undo
20:30:57 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x19d59290>
20:31:03 <mmaslano> #agreed remove rsyslog from @core, move to @standard pending revaluation in future (+6,-2,1)
20:31:08 <mmaslano> #topic chair for next week
20:31:10 <BCrookAtRA> pjones: it produces a log that gets referred to later, that is unique
20:31:19 <drago01> bconoboy: or just use journalctl i.e move on ;)
20:31:21 <pjones> that is not unique.
20:31:22 <mmaslano> I can say I won't chair next week
20:31:23 * nirik will be on the road next week, not sure I will be able to attend, so not sure I can chair.
20:31:32 * notting will be on vacation
20:31:34 <t8m> I won't be able to attend next week
20:31:39 <t8m> (on vacation)
20:31:44 * mattdm will also be on vacation
20:31:47 <mmaslano> I can't attend too
20:31:48 <mattdm> yay summer!
20:31:55 <drago01> bconoboy: sorry tab fail
20:31:56 <BCrookAtRA> drago01: that presumes that administration is always done in an environment that journalctl suports
20:31:56 <pjones> I don't think we'll have quorum
20:32:04 <sgallagh> #proposal: cancel next week's meeting
20:32:08 <pjones> just counting how many of you said you won't be here.
20:32:09 <t8m> sgallagh, +1
20:32:09 <abadger1999> Hmm.. If 4 are away, then we'll need unanimous votes in meeting to pass anything
20:32:10 <pjones> sgallagh: +1
20:32:15 <mmaslano> pjones: 4
20:32:17 <nirik> well, we have a number of changes and the schedule to decide?
20:32:20 <pjones> mmaslano: still...
20:32:27 <nirik> which we can try and do in tickets...
20:32:34 <mmaslano> pjones: do you want to chair? ;-)
20:32:34 <sgallagh> nirik: I don't think we want to decide schedule without quorum.
20:32:37 <pjones> nirik: right.  and those are things that *never* have descent ;)
20:32:45 <sgallagh> I'd suggest we try to deal with Changes in tickets.
20:32:46 <abadger1999> is there another day we can meet?  Some other time this week to at least clear off this week's features?
20:33:09 <nirik> possibly thursday/friday for me.
20:33:14 <mmaslano> abadger1999: not another evening
20:33:15 <t8m> I am not sure I'll be able this week
20:33:28 * sgallagh is available after 10am EDT tomorrow and Friday
20:33:31 <t8m> please let's vote about changes in tickets
20:33:39 <pjones> tbh wednesday is the worst day for me, but ... all you people are going to be on vacation wednesday.  are any of you not going to be on vacation monday or friday?  no?
20:33:44 <nirik> we have a poor historical record on ticket voting. ;)
20:33:53 <notting> pjones: nope, whole week.
20:34:03 <mmaslano> pjones: I could meet on Monday
20:34:07 <pjones> nirik: speak for yourself - I have *terrible* historical record on ticket voting
20:34:10 <t8m> whole week
20:34:16 <abadger1999> yeah, voting in ticket might be the best we can do.
20:34:22 <nirik> we could do a whenisgood for next week I suppose
20:34:28 <nirik> but sounds lke not much point
20:34:34 <pjones> let's try for a ticket, but I don't think a meeting is looking likely to solve anything
20:34:41 <pjones> s/a/in/
20:34:45 <abadger1999> If people are out for the whole week, then even voting in ticket won't work... but at least we tried.
20:35:02 <nirik> alright
20:35:02 <mmaslano> who will be the next chairman? that's still a question for next
20:35:21 <sgallagh> Are we going to run on Wednesday?
20:35:28 <sgallagh> I'll chair if we're on.
20:35:38 <mmaslano> thanks
20:35:38 <nirik> sure, day before flock travel for many people.
20:35:41 <abadger1999> two weeks from now is August 7.
20:35:43 <sgallagh> Oh crap
20:35:47 <pjones> wednesday the 7th
20:35:49 <mmaslano> um
20:35:53 <pjones> days before flock
20:35:59 <sgallagh> Geez, is that already next week?
20:36:02 <nirik> but that should be ok... unless people are traveling early?
20:36:08 <mmaslano> sgallagh: you can give it to someone else, thanks anyway ;-)
20:36:09 <nirik> week after next
20:36:19 <sgallagh> Sorry, I was talking about chairing the 31st
20:36:24 <mitr> The 7th would work for me, but not for a 3-hour meeting :)
20:36:32 <sgallagh> Minimal quorum is still quorum...
20:36:39 <mmaslano> #action sgallagh will chair 31th (if we have meeting)
20:36:39 * pjones wonders when the hell he's traveling
20:36:49 * mmaslano will close meeting now
20:37:03 <nirik> so yeah, 4 people are not going to attend the 31st. If everyone else does...
20:37:04 <jreznik> so what do we want to do with schedule if the meeting would be 7th?
20:37:13 <mattdm> +1 mmaslano
20:37:24 <mattdm> I _may_ be able to attend just can't promise
20:37:30 <mmaslano> jreznik: we have nice ticketing system, people should try to use it ;-)
20:37:34 <sgallagh> I have to go. I'm supposed to have been cooking for dinner guests for the last half-hour.
20:37:36 <mmaslano> #endmeeting