===================================
#fedora-meeting: FESCO (2014-04-09)
===================================

Meeting started by t8m at 18:00:21 UTC. The full logs are available at
http://meetbot.fedoraproject.org/fedora-meeting/2014-04-09/fesco.2014-04-09-18.00.log.html
.

Meeting summary
---------------
* init process  (t8m, 18:00:39)
  * abadger1999 assures us he's not around  (pjones, 18:05:28)

* #1244 F21 System Wide Change: cron to systemd time units  (t8m,
  18:06:16)
  * LINK: https://fedoraproject.org/wiki/User:Notting/timer   (nirik,
    18:10:19)
  * AGREED: Talk to FPC about replacing SHOULD with MUST, address
    concerns there (+7 -0 0:0)  (t8m, 18:28:56)
  * ACTION: notting will bring it up with FPC  (t8m, 18:30:48)

* #1221 Product working group activity reports  (t8m, 18:31:29)
  * Server: Spent the last two weeks organizing and filing Change
    Proposals  (sgallagh, 18:32:30)
  * Work on the Role Infrastructure was stalled by my unavailability.
    (sgallagh, 18:32:34)
  * Please, WG liaisons add the reports to the ticket if you have
    anything new to report  (t8m, 18:36:07)

* #1250 F21 Self Contained Changes  (t8m, 18:37:13)
  * AGREED: All F21 Self Contained Changes for 2014-04-09 meeting are
    approved (+7, -0, 0:0)  (t8m, 18:40:13)

* #1269 Closing all 'Merge Review' bugs  (t8m, 18:40:55)
  * ACTION: dgilmore to organise a vfad to finish off merge reviews
    (dgilmore, 18:42:50)
  * ACTION: dgilmore will e-mail devel-announce to encourage
    provenpackagers to fix things from stalled merge reviews  (t8m,
    18:46:10)

* #1272 Reschedule meeting for DST shift?  (t8m, 18:46:51)
  * AGREED: The FESCo meeting is moved one hour earlier (+5, -0, 0:3)
    (t8m, 18:50:30)

* #1274 F21 System Wide Change: GCC49 -
  https://fedoraproject.org/wiki/Changes/GCC49  (t8m, 18:50:51)
  * AGREED: F21 System Wide Change: GCC49 is approved (+7, -0, 0:0)
    (t8m, 18:54:21)

* #1275 F21 System Wide Change: GHC 7.8 -
  https://fedoraproject.org/wiki/Changes/GHC_7.8  (t8m, 18:54:34)
  * AGREED: F21 System Wide Change: GHC 7.8 is approved (+8, -0, 0:0)
    (t8m, 18:57:26)
  * if there are no ordering requirements for the haskell-using packages
    the F21 mass rebuild could be used for rebuilding them  (t8m,
    18:59:01)

* #1276 F21 System Wide Change: lbzip2 as default bzip2 implementation
  (t8m, 18:59:19)
  * AGREED: F21 System Wide Change: lbzip2 as default bzip2
    implementation was rejected  (t8m, 19:08:14)
  * 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)  (t8m, 19:14:53)

* #1277 F21 System Wide Change: RPM-4.12  (t8m, 19:15:17)
  * AGREED: F21 System Wide Change: RPM-4.12 is approved (+8, -0, 0:0)
    (t8m, 19:16:55)

* Next week's chair  (t8m, 19:17:17)
  * ACTION: notting will chair the next meeting  (t8m, 19:19:38)

* Open Floor  (t8m, 19:20:00)

Meeting ended at 19:24:01 UTC.


Action Items
------------
* notting will bring it up with FPC
* dgilmore to organise a vfad to finish off merge reviews
* dgilmore will e-mail devel-announce to encourage provenpackagers to
  fix things from stalled merge reviews
* notting will chair the next meeting




Action Items, by person
-----------------------
* dgilmore
  * dgilmore to organise a vfad to finish off merge reviews
  * dgilmore will e-mail devel-announce to encourage provenpackagers to
    fix things from stalled merge reviews
* notting
  * notting will bring it up with FPC
  * notting will chair the next meeting
* **UNASSIGNED**
  * (none)


People Present (lines said)
---------------------------
* t8m (105)
* mitr (47)
* nirik (43)
* pjones (43)
* sgallagh (37)
* dgilmore (35)
* Viking-Ice (24)
* notting (24)
* mattdm (15)
* zodbot (15)
* abadger1999 (12)
* drago01 (4)
* jwb (4)
* ffesti (2)
* mmaslano (0)

------

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


-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Reply via email to