18:00:21 <t8m> #startmeeting FESCO (2014-04-09)
18:00:21 <zodbot> Meeting started Wed Apr  9 18:00:21 2014 UTC.  The chair is t8m. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:21 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:21 <t8m> #meetingname fesco
18:00:22 <t8m> #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb
18:00:22 <zodbot> The meeting name has been set to 'fesco'
18:00:22 <zodbot> Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m
18:00:39 <t8m> #topic init process
18:00:59 <t8m> Hi everyone
18:01:08 <mitr> Hello
18:01:15 <pjones> hello
18:01:24 <sgallagh> Salutations
18:02:02 <nirik> morning
18:03:02 <Viking-Ice> I would like to request if it is possible fesco starts with ticket 1244 since I'm in a bit of a hurry
18:03:58 <t8m> Viking-Ice, no problem
18:04:46 * notting is here. sorry i'm a few minutes late
18:04:56 <t8m> dgilmore, mattdm, abadger1999, around?
18:05:06 <nirik> abadger1999 is off at pycon.
18:05:11 <nirik> not sure on the others.
18:05:14 <abadger1999> t8m: I'm not around.
18:05:28 <pjones> #info abadger1999 assures us he's not around
18:05:31 <t8m> :)
18:05:39 <abadger1999> ;-)
18:06:05 <t8m> we will start as we have a quorum
18:06:16 <t8m> #topic #1244 F21 System Wide Change: cron to systemd time units
18:06:17 <t8m> .fesco 1244
18:06:18 <zodbot> t8m: #1244 (F21 System Wide Change: cron to systemd time units - https://fedoraproject.org/wiki/Changes/cron-to-systemd-time-units) – FESCo - https://fedorahosted.org/fesco/ticket/1244
18:06:54 <t8m> So Viking-Ice is asking us to overrule FPC's SHOULD with MUST
18:06:57 <nirik> so, I am pretty confused here. Viking-Ice: can you summarize? because there's no fpc writeup last I looked and I couldn't parse all the not/should junk...
18:06:59 <Viking-Ice> right FPC change an must not to an should not which I here by request that FESCo overwrites to an must not (without an FESCo exception)
18:07:22 <notting> wasn't 'must' in what fesco approved?
18:07:23 <nirik> can you repeat the current and proposed change?
18:07:24 <mitr> (FPC not documenting its decision properly is rather disappointing.)
18:08:05 <Viking-Ice> mitr, or closing that ticket with their ruling
18:08:10 <Viking-Ice> notting, "18:02:41 <abadger1999> Okay, MUSTs changed to SHOULDs."
18:08:24 <Viking-Ice> that decision is in their meeting logs
18:08:43 <mitr> notting: Not explicitly AFAICS, but that's what we have been discussing outside of the formal page at least
18:09:00 <abadger1999> *sigh* -- fpc approved should not must.  I would have spent more time to try to change minds but there wasn't time at the meeting and still get t o the other things that affect other Fedora Changes.  Can be brought up again but I'm not around to bring it back up until apr27.
18:09:02 <mitr> The MUSTs do make more sense to me;
18:09:19 <t8m> mitr, +1
18:09:25 * nirik looks for actual context.
18:09:33 <pjones> nirik: yeah, that's what I'm trying to figure out as well
18:09:34 <t8m> at least for the second MUST NOT
18:09:42 <mitr> the concerns about making the timer units optional / not enabled by default seem not relevant for this porting effort
18:10:02 <t8m> I could go with SHOULD for the first MUST and MUST NOT (without FESCo exception) for the second
18:10:18 <Viking-Ice> mitr, where applicable timer units wont enable at all but directly tied to the startup of the service/daemon
18:10:19 <nirik> https://fedoraproject.org/wiki/User:Notting/timer
18:10:29 <nirik> here's context for people who actually want it ^
18:10:29 <abadger1999> geppetto should run the meeting this week if someone would like to present the case for must (I can vote in ticket for must).
18:10:30 <mitr> nirik, pjones:
18:10:32 <mitr> <RemiFedora> "Whether a timer unit is enabled by default is controlled by systemd presets, just like any other systemd unit." => does this mean we cannot have a systemd timer enabled by default ?
18:10:34 <mitr> <abadger1999> RemiFedora: So... a couple ways to fix that.. " All packages with timed execution or scheduled tasks which already depend on systemd (for example because they contain service units) MUST use timer units instead of cron jobs, with no dependency on a cron daemon. "
18:10:36 <mitr> 17:55:58 <abadger1999> We can change that into a should
18:11:06 <pjones> so it seems like the way presets work was misunderstood?
18:11:19 <pjones> (or maybe I'm misunderstanding them ;)
18:11:19 <mitr> ... can we step back and make sure we agree we would want to overrule FPC here?
18:11:34 <pjones> mitr: I think that's still the discussion we're having...
18:11:57 <abadger1999> mitr: I don't think that's a good idea -- better to go to fpc to get it changed (but need to bring more info to that discussion)
18:12:01 <mitr> pjones: I thought we might be at the stage of "how", but OK
18:12:08 <sgallagh> Speaking from my own past experience, any "should" in the guidelines is implicitly read as "if you feel with it. Or not. Whatever."
18:12:16 <sgallagh> s/with/like/
18:12:21 <t8m> sgallagh, +1
18:12:37 <t8m> that's exactly my experience as well
18:12:41 <pjones> sgallagh: right, it's "unless you mistakenly think you know better"
18:13:01 <t8m> pjones, sometimes even unmistakenly
18:13:18 <sgallagh> So in general, I'm always of the opinion that guidelines should either be MUST or not mentioned.
18:13:31 <nirik> so, the disadvantage of a should is that we have some cron using stuff that already depends on systemd?
18:13:44 <abadger1999> pjones: yeah, presets might be a crux there.  No time at meeting to research what presets actually do.
18:13:44 <t8m> sgallagh, well some guidelines might be actually recommendations and not guidelines
18:13:47 <pjones> I wouldn't go quite that hard line here, but in this case it seems like "should" is tantamount to not having any rule.
18:14:09 <sgallagh> you'll notice I used the word "should" in that sentence :-P
18:14:22 <t8m> :D
18:14:54 <sgallagh> But yes, that's exactly how I'm reading this case, pjones
18:14:54 <nirik> I'm not sure how presets figure in in the end...
18:14:54 <pjones> abadger1999: presets are essentially an analog of the chkconfig line in sysvinit scripts, AIUI
18:15:05 <t8m> So what do we want - any concrete proposal either for direct overruling of FPC or for "politely asking" FPC to reconsider?
18:15:06 <mitr> pjones: AFAICS presets were not misunderstood but the policy on starting by default was
18:15:35 <pjones> abadger1999: so "MUST" in that case would mean that the /reason/ it's default needs to be that the preset says so
18:15:46 <mitr> nirik: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd only enables units if the preset says so.
18:15:53 <pjones> abadger1999: http://www.freedesktop.org/software/systemd/man/systemd.preset.html <-- fyi
18:16:03 <nirik> but look at it from the existing cron jobs.
18:16:08 <mitr> pjones: well "systemctl enable ..." is also an option
18:16:12 <nirik> they are enabled if the package is installed now.
18:16:31 <nirik> so why wouldn't they continue to always run if the package is installed and it's up to them to not do anything bad if the service isn't running.
18:16:32 <Viking-Ice> <sigh> enablement needs to be decided on case by case bases
18:16:34 <t8m> nirik, for that reason I would not insist on changing the first SHOULD
18:16:44 <mitr> nirik: That would be a case for making the cron->migration spec explicit for how this is written in the spec, but not in changing the requirements
18:16:51 <pjones> mitr: right, and the MUST is saying to use the presets instead of having the package set it up as enabled by putting the files in place to enable it
18:16:54 <abadger1999> t8m: I think the best thing is for someone to present the case for must to fpc to change the guideline.  might normally be me but I can't until until after apr27.
18:17:00 <Viking-Ice> best case scenario we bind the enablement with the startup of the daemon/service the timer unit belongs to
18:17:24 <mitr> pjones: I can't see these being related at all.  MUST{,NOT} use systemd is fairly orthogonal to "uses presets/ hard-enable to enable the script"
18:17:36 <t8m> Viking-Ice, yep, that's reasonable although there might be exceptions needed
18:17:49 * notting agrees with mitr, and would be in favor of putting 'must' back
18:17:52 <nirik> I can try and bring it to FPC, but I personally still don't see presets as part of this at all.
18:18:12 <nirik> but I would be in favor of must instead of should.
18:18:17 <Viking-Ice> when I'm talking about must or must not I'm referring to components that do or do not already depend on systemd
18:18:18 * dgilmore is here
18:18:18 <pjones> mitr: you're right, I misspoke - discussion on that line was the result of remi's question, which is what I was talking about, but that doesn't actually have the must vs should distinction in that line
18:18:19 <abadger1999> mitr: re: start by default..  fpc wrote that policy too... so it might be fesco that misunderstands that policy ;-)
18:18:20 <mitr> Viking-Ice: universal enablement for everything would be perfectly consistent with cron.  We can do better if we want but I woudln't see it as a blocker or something FESCo would need to overrule FPC for
18:18:37 <Viking-Ice> mitr, we do not want cron behaviour
18:18:42 <Viking-Ice> and enable everything
18:18:59 <pjones> mitr: but basically the answer to remi's question seems like it was "no" but the conversation assumed it was "yes"
18:19:20 <nirik> we want to enable things that already depend on systemd.
18:19:24 <mitr> pjones: right
18:19:30 <nirik> we specificially do not want to enable things that don't
18:20:06 <abadger1999> nirik: s/enable/migrate/ ?
18:20:32 <nirik> right.
18:20:33 <mitr> abadger1999: "If a service does not require configuration to be functional and does not listen on a network socket, it may be enabled by default" would cover all of this, at least I hope
18:21:11 <nirik> there's 3 groups... a) depend on systemd now, and can be migrated. b) depend on systemd now and can't be for some reason. c) don't depend on systemd and must not be migrated, because it would add a systemd dep.
18:21:12 <Viking-Ice> ok step back here for a moment you can enable things anyway you like if you think it's better to that by default but what I'm talking about is components that do not already depend on systemd and contain cron jobs MUST NOT (without an FESCo exception) be migrated to systemd timers
18:21:48 <mitr> nirik: b) was the concern and AFAICT b) doesn't exist
18:22:08 <sgallagh> Viking-Ice: I may have missed that part of the conversation, but what is the specific reason to ban them from migrating?
18:22:23 <sgallagh> To avoid issues with containerization efforts?
18:22:27 <Viking-Ice> c)
18:22:38 <pjones> it seems like that means we should make filesystem own the directory so they grow the dependency on it instead?
18:22:56 <nirik> mitr: well, we don't know. If it doesn't that could be must. If it does, it should be should.
18:22:58 <pjones> so that they can optionally provide timers without depending on systemd.
18:23:08 <nirik> pjones: directory?
18:23:10 <pjones> (though I'm on the fence on that being a really valid concern at all tbh)
18:23:16 <Viking-Ice> pjones, right workaround
18:23:35 <pjones> nirik: er... the mechanism for creating a systemd timer.  Have I completely misunderstood it?
18:23:54 <pjones> nirik: it is a file, yes?
18:24:01 <t8m> we are more than 15 minutes at this topic do we want to continue?
18:24:03 <Viking-Ice> no adding dependency on something other then systemd is not the right way forward
18:24:07 <mitr> nirik: I'd say that we could easily prove non-existence of b) by writing a program that converts a cron line into a systemd unit and the associated packaging.
18:24:08 <t8m> I'd like to ask for concrete proposals
18:24:18 <sgallagh> pjones: From my perspective, the problem is that at the moment we can't put a timer into a container, because it would require systemd to be running in that container.
18:24:33 <pjones> (typically we don't actually add dependencies on filesystem)
18:24:34 <notting> proposal: talk to FPC about replacing SHOULD with MUST. address concerns there.
18:24:34 <sgallagh> So we don't want too many services to grow that dependency until we solve that problem
18:24:35 <nirik> pjones: yes, but it won't do anything without systemd to process it. Then again. I have no idea how containers do cron
18:24:39 * dgilmore thinks that the solution may be a bigger issue than the thing its trying to fix
18:24:41 <Viking-Ice> sgallagh, this is not limited to container
18:24:47 <abadger1999> notting: +1
18:24:48 <t8m> notting, +1
18:24:50 <pjones> nirik: well, yes.
18:24:55 <sgallagh> Viking-Ice: Perhaps not, but that's a representative case, I think?
18:24:56 <pjones> notting: +1
18:25:02 <dgilmore> notting: +!
18:25:04 <dgilmore> +1
18:25:17 * abadger1999 goes back to paying attention to his real-life discussion again
18:25:19 <Viking-Ice> systemd provides benefits which is explicitly tied to the init system what does not require it should not depend on it
18:25:21 <mitr> notting: +1 I suppose... I'd hate to have this on FESCo agenda another meeting but it's worth using the appeal mechanism in the most limited way necessary
18:25:34 <notting> abadger1999: when's FPC?
18:25:50 <notting> abadger1999: n/m, i can look that up
18:26:04 <mitr> notting: Thursday at 2014-04-10 16:00 UTC
18:26:13 <sgallagh> Viking-Ice: I'm wary of attempting to legislate upstream policy here. I agree with not making Fedora-specific changes of course
18:26:15 <mitr> (but it's not on the agenda)
18:26:29 <Viking-Ice> do me a favour just votte on this "components that do not already depend on systemd and contain cron jobs MUST NOT (without an FESCo exception) be migrated to systemd timers"
18:26:41 <Viking-Ice> ack or nack it and we can put this matter to rest
18:26:42 <t8m> #agreed Talk to FPC about replacing SHOULD with MUST, address concerns there (+6 -0 0:0)
18:27:05 <t8m> notting, I counted you as implicit +1
18:27:23 <notting> t8m: yup. i can do it
18:27:29 <nirik> sorry, got sidetracked. +1
18:27:45 <sgallagh> Viking-Ice: I just want to clarify that you're referring only to Fedora package maintainers and not trying to handicap upstreams from making this decision there.
18:27:59 <t8m> Viking-Ice, apparently FESCo does not want to go to direct overruling of FPC just now
18:27:59 <Viking-Ice> we would not ship those cron jobs
18:28:05 <Viking-Ice> if upstreams converts them
18:28:10 <Viking-Ice> it makes no sense
18:28:14 <sgallagh> Viking-Ice: Agreed
18:28:18 <dgilmore> Viking-Ice: if upstream converts to timers?
18:28:46 <dgilmore> anyway we have spent too much time on this
18:28:47 <Viking-Ice> dgilmore, right if an cron job like for example wget for drupal uses timers instead which makes drupal have a hard dependency on systemd
18:28:49 <t8m> #undo
18:28:49 <zodbot> Removing item from minutes: AGREED by t8m at 18:26:42 : Talk to FPC about replacing SHOULD with MUST, address concerns there (+6 -0 0:0)
18:28:56 <t8m> #agreed Talk to FPC about replacing SHOULD with MUST, address concerns there (+7 -0 0:0)
18:29:14 <t8m> Anybody wants to take #action to bring it to FESCo?
18:29:20 <t8m> oops
18:29:23 <pjones> you mean fpc?
18:29:31 <mitr> sgallagh: I'd be perfectly fine with legislating such things if there is no better ecosystem-wide place to codify best practices (and we have a good reason to want things one way), FWIW
18:29:33 <t8m> yep, not FESCo but FPC
18:29:41 <dgilmore> t8m: i thought notting said he would
18:29:58 <Viking-Ice> you are talking about a meeting that will happen on the 27th of april
18:29:58 <t8m> dgilmore, that was about the implicit +1
18:30:14 <sgallagh> mitr: In general I agree, but since this was already conditional on other things, I didn't want to imply that we were trying to prevent future migrations
18:30:28 <nirik> Viking-Ice: no.
18:30:29 <sgallagh> Just that we aren't allowing them to be made *without upstream involvement*
18:30:35 <notting> t8m: i bring it up with FPC
18:30:39 <nirik> notting: can you talk to FPC thursday?
18:30:48 <t8m> #action notting will bring it up with FPC
18:31:08 <t8m> let's move on next topic
18:31:29 <t8m> #topic #1221 Product working group activity reports
18:31:29 <t8m> .fesco 1221
18:31:31 <zodbot> t8m: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221
18:31:53 <sgallagh> Server: Spent the last two weeks organizing and filing Change Proposals
18:32:18 <sgallagh> Work on the Role Infrastructure was stalled by my unavailability.
18:32:30 <sgallagh> #info Server: Spent the last two weeks organizing and filing Change Proposals
18:32:34 <sgallagh> #info Work on the Role Infrastructure was stalled by my unavailability.
18:34:48 <t8m> other groups?
18:35:23 <dgilmore> I know cloud has been busy filing changes and organising themselves in trac
18:36:07 <t8m> #info Please, WG liaisons add the reports to the ticket if you have anything new to report
18:36:07 <dgilmore> workstation has been very quiet, they did not respond at all to my follow on email in response to jwb reminding me to follow up
18:36:19 <t8m> let's move on
18:36:31 <jwb> dgilmore, that seems like a trivial thing to solve imo
18:36:46 <jwb> workstation has been quiet.  i've also been on PTO
18:36:49 <dgilmore> jwb: there will be more deliverables than they want and list
18:37:13 <t8m> #topic #1250 F21 Self Contained Changes
18:37:13 <t8m> .fesco 1250
18:37:14 <zodbot> t8m: #1250 (F21 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1250
18:37:26 <jwb> dgilmore, the DVD image can be deleted if the tools can't be changed to not generate it in the first place
18:37:40 <jwb> anyway, we should discuss this elsewhere
18:37:41 <t8m> So I suppose there are some self-contained changes that might be slightly controversial
18:38:20 <mitr> I'm fine with all of them
18:38:25 <t8m> anybody wants to exclude something from the list of changes to be approved in single vote?
18:38:26 <nirik> I'm ok with all of them
18:38:32 * pjones has no objections
18:38:46 <dgilmore> im okay with them all also
18:38:57 <notting> i'm OK with them.
18:39:09 <t8m> I am actually OK with them all as well
18:39:49 <sgallagh> I'm good with all of them
18:39:54 <dgilmore> maybe all the hadoop ones could be merged into one
18:40:13 <t8m> #agreed All F21 Self Contained Changes for 2014-04-09 meeting are approved (+7, -0, 0:0)
18:40:55 <t8m> #topic #1269 Closing all 'Merge Review' bugs
18:40:55 <t8m> .fesco 1269
18:40:57 <zodbot> t8m: #1269 (Closing all 'Merge Review' bugs) – FESCo - https://fedorahosted.org/fesco/ticket/1269
18:40:59 <mattdm> holy %^#% I lost track of time. Hi everyone :)
18:41:24 <t8m> we agreed tell provenpackagers to just fix things and make sure they know we'll support them if an unresponsive package maintainer suddenly wakes up and complains that the provenpackager did what we asked them to do. organise a vfad to get them done in a a day. (6+1 0-1)
18:41:28 <t8m> hi mattdm
18:41:36 <mattdm> sorry!
18:41:40 * mattdm reads scrollback
18:41:59 <pjones> mattdm: we didn't assign you that much work, don't worry
18:42:01 <nirik> right so we didn't actually do that except in the ticket. ;) we need someone to send out a devel-announce on it?
18:42:02 <t8m> does anyone want to take #action for the things we agreed on the last meeting?
18:42:28 <dgilmore> ill take on organising the vfad
18:42:50 <dgilmore> #action dgilmore to organise a vfad to finish off merge reviews
18:42:55 <mattdm> dgilmore++
18:42:57 <t8m> good
18:44:04 <t8m> nirik, yep sending the devel-announce for provenpackagers seems to be the second #action needed
18:45:38 <dgilmore> t8m: I can do that also, will fit in as part of organising a vfad
18:46:10 <t8m> #action dgilmore will e-mail devel-announce to encourage provenpackagers to fix things from stalled merge reviews
18:46:37 <t8m> finally onto new business
18:46:51 <t8m> #topic #1272 Reschedule meeting for DST shift?
18:46:51 <t8m> .fesco 1272
18:46:53 <pjones> so now we talk about timezones?
18:46:54 <zodbot> t8m: #1272 (reschedule meeting for DST shift?) – FESCo - https://fedorahosted.org/fesco/ticket/1272
18:47:05 * dgilmore would prefer an hour ealier
18:47:21 <dgilmore> unless we canb get done in an hour
18:47:43 <nirik> I dont care. No preference. Will go with whatever is better for everyone else.
18:47:45 <pjones> well, right now we're hitting new business in just under 50 minutes.
18:47:51 <dgilmore> I have to go pick my daughter up at 2pm US Central time
18:48:10 <t8m> #proposal let's move one hour earlier
18:48:13 <mitr> +1
18:48:16 <dgilmore> +1
18:48:20 <t8m> +1
18:48:23 <pjones> my noon wednesday meeting seems to be really good at keeping it to 1hour, so I can do an hour earlier.
18:48:25 * pjones +1
18:48:39 <sgallagh> +1
18:49:00 <notting> 0.
18:49:15 <mattdm> I have a slight preference for current time but a strong preference for accomodating dgilmore's needs
18:49:23 <nirik> 0
18:49:40 <t8m> mattdm, will count you as 0
18:49:49 <mattdm> as long as that doesn't block the vote
18:50:08 <notting> mattdm: appears it passes anyway
18:50:09 <pjones> we're already at +5
18:50:17 <dgilmore> thanks all
18:50:30 <t8m> #agreed The FESCo meeting is moved one hour earlier (+5, -0, 0:3)
18:50:51 <t8m> #topic #1274 F21 System Wide Change: GCC49 - https://fedoraproject.org/wiki/Changes/GCC49
18:50:52 <t8m> .fesco 1274
18:50:53 <zodbot> t8m: #1274 (F21 System Wide Change: GCC49 - https://fedoraproject.org/wiki/Changes/GCC49) – FESCo - https://fedorahosted.org/fesco/ticket/1274
18:51:31 <nirik> +1
18:51:39 <sgallagh> Proposal: Approve and schedule a mass-rebuild
18:51:40 <dgilmore> +1
18:51:50 <t8m> +1
18:51:52 <mitr> +1
18:51:57 <dgilmore> sgallagh: not sure we can do that yet
18:52:09 <t8m> sgallagh, do we know of any other things that could need mass-rebuild?
18:52:18 <sgallagh> Sorry, rephrasing "Account for it when we schedule a mass-rebuild"
18:52:24 <dgilmore> sgallagh: there may be things other than gcc49 that need us to schedule a mass rebuild
18:52:24 <notting> dgilmore: not sure we can do one, or not sure we can schedule it yet?
18:52:37 <dgilmore> notting: not sure we can schedule it yet
18:52:38 <nirik> there's a ticket open to track that
18:52:40 <nirik> in releng
18:52:48 <notting> dgilmore: ok, no problem.
18:53:03 * notting is +1
18:53:11 <sgallagh> I think we're agreeing, just with different words
18:53:17 <sgallagh> +1 to the Change proposal
18:53:21 <mattdm> +1
18:53:32 <t8m> sgallagh, I think there is no controversy with the mass rebuild for gcc 4.9
18:53:39 <dgilmore> notting: its pretty clear we need and want one, we just need to work out when to do it. once all changes are approved and we can guage what needs it we can work out when to schedule
18:54:21 <t8m> #agreed F21 System Wide Change: GCC49 is approved (+7, -0, 0:0)
18:54:34 <t8m> #topic #1275 F21 System Wide Change: GHC 7.8 - https://fedoraproject.org/wiki/Changes/GHC_7.8
18:54:34 <t8m> .fesco 1275
18:54:35 <zodbot> t8m: #1275 (F21 System Wide Change: GHC 7.8 - https://fedoraproject.org/wiki/Changes/GHC_7.8) – FESCo - https://fedorahosted.org/fesco/ticket/1275
18:55:50 <mitr> +1
18:55:51 <notting> speaking of other things for mass rebuilds.
18:56:05 <dgilmore> +1
18:56:08 <t8m> +1
18:56:13 <notting> +1
18:56:14 <sgallagh> +1
18:56:37 <nirik> +1
18:56:45 <mattdm> +1
18:56:48 <pjones> +1
18:56:50 <t8m> Seems like the haskell-using packages could be mass-rebuilt within the mass rebuild
18:57:23 <dgilmore> t8m: as long as we do not need to worry about build ordering
18:57:26 <t8m> #agreed F21 System Wide Change: GHC 7.8 is approved (+8, -0, 0:0)
18:57:47 * dgilmore will be back soon
18:59:01 <t8m> #info if there are no ordering requirements for the haskell-using packages the F21 mass rebuild could be used for rebuilding them
18:59:19 <t8m> #topic #1276 F21 System Wide Change: lbzip2 as default bzip2 implementation
18:59:25 <t8m> .fesco 1276
18:59:27 <zodbot> t8m: #1276 (F21 System Wide Change: lbzip2 as default bzip2 implementation - https://fedoraproject.org/wiki/Changes/lbzip2) – FESCo - https://fedorahosted.org/fesco/ticket/1276
18:59:31 <t8m> This one is more controversial
18:59:36 <nirik> yeah...
18:59:44 <t8m> there was quite some discussion on devel list
18:59:53 <mitr> Yeah, "get more exposure to be accepted" / "be accepted to get more exposure"
18:59:59 <sgallagh> Without a library interface, I'm a moderate -1
19:00:23 <nirik> it does seem odd to replace just command line, but leave all the rest
19:00:37 <notting> i'm of a similar opinion to sgallagh - if we're just swapping out the CLI, and not the full implementation, i'm not sure it's worth it. (or worth the use of alternatives)
19:00:37 <mattdm> it _is_ impressively fast. but I'm not sure that's a reason to switch the command line -- can't we just suggest using it?
19:01:06 <nirik> there was some interest expressed in replacing the library bit too right? just not in scope for f21.
19:01:17 <t8m> I think that using alternatives is really overengineering here. If the library would be there and API/ABI compatible we could just replace the default completely
19:01:28 <mitr> Moderate -1 as well, but wouldn't want to lose the the contribution/contributor.
19:01:30 <abadger1999> t8m: I'm with you
19:01:50 <mitr> Can we agree (but not strictly pre-commit) to criteria to approving this?
19:01:54 <nirik> mitr: yeah, me too. -1, but if they can get the library side working so we can switch the entire thing...
19:02:16 <notting> t8m: yes. although mildly curious about the implications of an ABI-compatible library that introduces threads into decompression
19:02:34 <t8m> notting, perhaps that could be some non-default option?
19:02:41 <sgallagh> mitr: Yes, a compatible (preferably drop-in) replacement for the library would be my personal preference here
19:02:50 <notting> t8m: that's the main source of the speedup, isn't it?
19:03:11 <mattdm> sooooo....
19:03:13 <mitr> notting: Asking a single-threaded application to add a flag to be much faster isn't such a burden
19:03:23 <t8m> mitr, exactly
19:03:24 <mattdm> proposal: mark bzip2 as deprecated in this release, intend to replace in f22
19:04:07 <drago01> whats wrong with replacing the command line tool only for now?
19:04:10 <mitr> sgallagh, nirik: I'd want a library and _some_ (unsure which) indication that the code is _past_ development pains like "assertion on compression of some data"
19:04:30 <mitr> drago01: "unexplicable" differences in behavior
19:04:38 <notting> drago01: the goal is one better implementation. a switchable implementation doesn't necessarily further that
19:04:41 <drago01> that way the code behind it gets exposed to more tests and then if we get a library (which will affect more applications) it will have a better tested base
19:04:47 <pjones> "inexplicable" I'm pretty sure, but yeah.
19:05:04 <drago01> mitr: which differences?
19:05:04 <nirik> mitr: me too.
19:05:10 <mitr> pjones: thanks
19:05:15 <pjones> drago01: that's an awfully big "if" you're waiving around like a fait accompli there
19:05:52 <mitr> drago01: like "crashes on some inputs" (one instance fixed last month)
19:06:07 * mitr really doesn't want lbzip2 to encourage to _hide_ such bugs from FESCo, though
19:06:10 <drago01> mitr: that's not different behaviour thats a bug
19:06:42 <t8m> so I am currently -1 with encouraging the author to work on the library
19:07:13 <t8m> that's -4 and the feature did not pass
19:07:18 * pjones also -1
19:07:30 * nirik was gone there for a min... iwlwifi decided I needed a break from working net. ;)
19:07:42 <pjones> nirik: as it does...
19:08:09 <mitr> proposal: FESCo would be happy to consider a re-proposal that includes a compatible library replacement, and some indication of project maturity
19:08:14 <t8m> #agreed F21 System Wide Change: lbzip2 as default bzip2 implementation was rejected
19:08:16 <mattdm> mitr +1
19:08:21 <t8m> mitr, +1
19:08:22 <mitr> (happy to accept a re-wording proposal, this doesn't read quite right)
19:08:25 <pjones> mitr: +1
19:09:04 <notting> mitr: +1
19:09:21 <sgallagh> mitr: I think "indication of project maturity" might be unfair
19:09:41 <mitr> sgallagh: counterproposal?
19:09:42 <sgallagh> If it's accepted as a Change, then we are implying that there is testing done on it
19:10:21 <sgallagh> I think it's better to just request that it be a drop-in replacement and trust that existing test methodologies will therefore catch regressions
19:10:27 <mitr> sgallagh: (We don't have a good precedent; historically we've been adopting _new_ compression formats for widespread use after they have been separately available in Fedora for a while, and have been used by non-Fedora users)
19:11:17 <pjones> sgallagh: I'd call that an indication of project maturity
19:11:35 <mitr> sgallagh: If the proposal _today_ included a drop-in library, I'd be really uncomfortable with accepting it based on http://lbzip2.org/news
19:11:36 <pjones> because you're saying "be a drop-in replacement for the thing you're cloning"
19:12:17 <pjones> mitr: yeah, likewise.
19:13:17 <mitr> OTOH I do  agree that we might be imposing an unbearable burden by asking Mikolaj to attract testing users without telling him how
19:13:19 <t8m> anybody else would vote for the mitr's proposal?
19:13:27 <sgallagh> 0
19:13:51 <t8m> mitr, are you +1 to yourself?
19:13:53 <pjones> mitr: certainly we're not /introducing/ that burden; it's one he has (and all other software authors have) naturally.
19:13:59 <mitr> t8m: +1 for the record
19:14:06 <mitr> pjones: true
19:14:19 <notting> mitr: a copr with obsoletes:  ...
19:14:23 <pjones> It's not as if he didn't face the problem "how do I get people to use my work" before fesco was involved.
19:14:34 <t8m> #agreed FESCo would be happy to consider a re-proposal that includes a compatible library replacement, and some indication of project maturity (+5, -0, 0:1)
19:14:35 <nirik> +1
19:14:37 <sgallagh> I'd be +1 if we dropped the last part
19:14:46 <t8m> #undo
19:14:46 <zodbot> Removing item from minutes: AGREED by t8m at 19:14:34 : FESCo would be happy to consider a re-proposal that includes a compatible library replacement, and some indication of project maturity (+5, -0, 0:1)
19:14:49 <dgilmore> mitr: +1 for the record
19:14:53 <t8m> #agreed FESCo would be happy to consider a re-proposal that includes a compatible library replacement, and some indication of project maturity (+7, -0, 0:1)
19:15:17 <t8m> #topic #1277 F21 System Wide Change: RPM-4.12
19:15:23 <t8m> .fesco 1277
19:15:24 <zodbot> t8m: #1277 (F21 System Wide Change: RPM-4.12 - https://fedoraproject.org/wiki/Changes/RPM-4.12) – FESCo - https://fedorahosted.org/fesco/ticket/1277
19:15:47 <dgilmore> +1 from me
19:15:57 <nirik> +1
19:16:05 <t8m> +1
19:16:10 <sgallagh> +LOTS
19:16:11 <mattdm> +1
19:16:16 <pjones> +1
19:16:36 <mitr> +1
19:16:50 <notting> +1, even if we won't use all the new stuff yet
19:16:55 <t8m> #agreed F21 System Wide Change: RPM-4.12 is approved (+8, -0, 0:0)
19:17:17 <t8m> #topic Next week's chair
19:17:27 * sgallagh will be at Summit next week
19:17:27 <t8m> Anybody wants it?
19:17:49 <ffesti> why can't I get rid of the feeling this should be more difficult
19:17:57 <dgilmore> who else other than sgallagh will be at summit?
19:18:23 <t8m> ffesti, put more bugs into new releases and it might be :)
19:18:26 <dgilmore> i.e. will we have enough people for a meeting
19:18:38 <dgilmore> ?
19:18:44 <sgallagh> ffesti: The hard part is getting the new features through FPC.
19:18:51 <mattdm> I'll be at summit too
19:19:09 * nirik won't be at summit, should be around.
19:19:20 <t8m> I suppose we can at least try to have the meeting
19:19:23 * notting should be around, and can run the meeting
19:19:28 <t8m> good
19:19:38 <t8m> #action notting will chair the next meeting
19:19:39 <ffesti> sgallagh, yup, that's expected.
19:19:41 * dgilmore will be around
19:20:00 <t8m> #topic Open Floor
19:20:01 <mattdm> I'll show up for the meeting depending on summit schedule
19:20:14 <t8m> Anybody has anything for Open Floor?
19:20:25 <dgilmore> nothing here
19:20:27 * pjones will be around
19:21:08 * nirik has nothing
19:22:20 <t8m> If nobody speaks up I'll close the meeting in a minute.
19:24:01 <t8m> #endmeeting