18:00:21 #startmeeting FESCO (2014-04-09) 18:00:21 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 Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:21 #meetingname fesco 18:00:22 #chair abadger1999 dgilmore mattdm mitr notting nirik pjones t8m sgallagh mmaslano jwb 18:00:22 The meeting name has been set to 'fesco' 18:00:22 Current chairs: abadger1999 dgilmore jwb mattdm mitr mmaslano nirik notting pjones sgallagh t8m 18:00:39 #topic init process 18:00:59 Hi everyone 18:01:08 Hello 18:01:15 hello 18:01:24 Salutations 18:02:02 morning 18:03:02 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 Viking-Ice, no problem 18:04:46 * notting is here. sorry i'm a few minutes late 18:04:56 dgilmore, mattdm, abadger1999, around? 18:05:06 abadger1999 is off at pycon. 18:05:11 not sure on the others. 18:05:14 t8m: I'm not around. 18:05:28 #info abadger1999 assures us he's not around 18:05:31 :) 18:05:39 ;-) 18:06:05 we will start as we have a quorum 18:06:16 #topic #1244 F21 System Wide Change: cron to systemd time units 18:06:17 .fesco 1244 18:06:18 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 So Viking-Ice is asking us to overrule FPC's SHOULD with MUST 18:06:57 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 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 wasn't 'must' in what fesco approved? 18:07:23 can you repeat the current and proposed change? 18:07:24 (FPC not documenting its decision properly is rather disappointing.) 18:08:05 mitr, or closing that ticket with their ruling 18:08:10 notting, "18:02:41 Okay, MUSTs changed to SHOULDs." 18:08:24 that decision is in their meeting logs 18:08:43 notting: Not explicitly AFAICS, but that's what we have been discussing outside of the formal page at least 18:09:00 *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 The MUSTs do make more sense to me; 18:09:19 mitr, +1 18:09:25 * nirik looks for actual context. 18:09:33 nirik: yeah, that's what I'm trying to figure out as well 18:09:34 at least for the second MUST NOT 18:09:42 the concerns about making the timer units optional / not enabled by default seem not relevant for this porting effort 18:10:02 I could go with SHOULD for the first MUST and MUST NOT (without FESCo exception) for the second 18:10:18 mitr, where applicable timer units wont enable at all but directly tied to the startup of the service/daemon 18:10:19 https://fedoraproject.org/wiki/User:Notting/timer 18:10:29 here's context for people who actually want it ^ 18:10:29 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 nirik, pjones: 18:10:32 "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 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 17:55:58 We can change that into a should 18:11:06 so it seems like the way presets work was misunderstood? 18:11:19 (or maybe I'm misunderstanding them ;) 18:11:19 ... can we step back and make sure we agree we would want to overrule FPC here? 18:11:34 mitr: I think that's still the discussion we're having... 18:11:57 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 pjones: I thought we might be at the stage of "how", but OK 18:12:08 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 s/with/like/ 18:12:21 sgallagh, +1 18:12:37 that's exactly my experience as well 18:12:41 sgallagh: right, it's "unless you mistakenly think you know better" 18:13:01 pjones, sometimes even unmistakenly 18:13:18 So in general, I'm always of the opinion that guidelines should either be MUST or not mentioned. 18:13:31 so, the disadvantage of a should is that we have some cron using stuff that already depends on systemd? 18:13:44 pjones: yeah, presets might be a crux there. No time at meeting to research what presets actually do. 18:13:44 sgallagh, well some guidelines might be actually recommendations and not guidelines 18:13:47 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 you'll notice I used the word "should" in that sentence :-P 18:14:22 :D 18:14:54 But yes, that's exactly how I'm reading this case, pjones 18:14:54 I'm not sure how presets figure in in the end... 18:14:54 abadger1999: presets are essentially an analog of the chkconfig line in sysvinit scripts, AIUI 18:15:05 So what do we want - any concrete proposal either for direct overruling of FPC or for "politely asking" FPC to reconsider? 18:15:06 pjones: AFAICS presets were not misunderstood but the policy on starting by default was 18:15:35 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 nirik: https://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd only enables units if the preset says so. 18:15:53 abadger1999: http://www.freedesktop.org/software/systemd/man/systemd.preset.html <-- fyi 18:16:03 but look at it from the existing cron jobs. 18:16:08 pjones: well "systemctl enable ..." is also an option 18:16:12 they are enabled if the package is installed now. 18:16:31 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 enablement needs to be decided on case by case bases 18:16:34 nirik, for that reason I would not insist on changing the first SHOULD 18:16:44 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 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 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 best case scenario we bind the enablement with the startup of the daemon/service the timer unit belongs to 18:17:24 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 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 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 but I would be in favor of must instead of should. 18:18:17 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 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 mitr: re: start by default.. fpc wrote that policy too... so it might be fesco that misunderstands that policy ;-) 18:18:20 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 mitr, we do not want cron behaviour 18:18:42 and enable everything 18:18:59 mitr: but basically the answer to remi's question seems like it was "no" but the conversation assumed it was "yes" 18:19:20 we want to enable things that already depend on systemd. 18:19:24 pjones: right 18:19:30 we specificially do not want to enable things that don't 18:20:06 nirik: s/enable/migrate/ ? 18:20:32 right. 18:20:33 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 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 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 nirik: b) was the concern and AFAICT b) doesn't exist 18:22:08 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 To avoid issues with containerization efforts? 18:22:27 c) 18:22:38 it seems like that means we should make filesystem own the directory so they grow the dependency on it instead? 18:22:56 mitr: well, we don't know. If it doesn't that could be must. If it does, it should be should. 18:22:58 so that they can optionally provide timers without depending on systemd. 18:23:08 pjones: directory? 18:23:10 (though I'm on the fence on that being a really valid concern at all tbh) 18:23:16 pjones, right workaround 18:23:35 nirik: er... the mechanism for creating a systemd timer. Have I completely misunderstood it? 18:23:54 nirik: it is a file, yes? 18:24:01 we are more than 15 minutes at this topic do we want to continue? 18:24:03 no adding dependency on something other then systemd is not the right way forward 18:24:07 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 I'd like to ask for concrete proposals 18:24:18 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 (typically we don't actually add dependencies on filesystem) 18:24:34 proposal: talk to FPC about replacing SHOULD with MUST. address concerns there. 18:24:34 So we don't want too many services to grow that dependency until we solve that problem 18:24:35 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 sgallagh, this is not limited to container 18:24:47 notting: +1 18:24:48 notting, +1 18:24:50 nirik: well, yes. 18:24:55 Viking-Ice: Perhaps not, but that's a representative case, I think? 18:24:56 notting: +1 18:25:02 notting: +! 18:25:04 +1 18:25:17 * abadger1999 goes back to paying attention to his real-life discussion again 18:25:19 systemd provides benefits which is explicitly tied to the init system what does not require it should not depend on it 18:25:21 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 abadger1999: when's FPC? 18:25:50 abadger1999: n/m, i can look that up 18:26:04 notting: Thursday at 2014-04-10 16:00 UTC 18:26:13 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 (but it's not on the agenda) 18:26:29 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 ack or nack it and we can put this matter to rest 18:26:42 #agreed Talk to FPC about replacing SHOULD with MUST, address concerns there (+6 -0 0:0) 18:27:05 notting, I counted you as implicit +1 18:27:23 t8m: yup. i can do it 18:27:29 sorry, got sidetracked. +1 18:27:45 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 Viking-Ice, apparently FESCo does not want to go to direct overruling of FPC just now 18:27:59 we would not ship those cron jobs 18:28:05 if upstreams converts them 18:28:10 it makes no sense 18:28:14 Viking-Ice: Agreed 18:28:18 Viking-Ice: if upstream converts to timers? 18:28:46 anyway we have spent too much time on this 18:28:47 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 #undo 18:28:49 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 #agreed Talk to FPC about replacing SHOULD with MUST, address concerns there (+7 -0 0:0) 18:29:14 Anybody wants to take #action to bring it to FESCo? 18:29:20 oops 18:29:23 you mean fpc? 18:29:31 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 yep, not FESCo but FPC 18:29:41 t8m: i thought notting said he would 18:29:58 you are talking about a meeting that will happen on the 27th of april 18:29:58 dgilmore, that was about the implicit +1 18:30:14 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 Viking-Ice: no. 18:30:29 Just that we aren't allowing them to be made *without upstream involvement* 18:30:35 t8m: i bring it up with FPC 18:30:39 notting: can you talk to FPC thursday? 18:30:48 #action notting will bring it up with FPC 18:31:08 let's move on next topic 18:31:29 #topic #1221 Product working group activity reports 18:31:29 .fesco 1221 18:31:31 t8m: #1221 (Product working group activity reports) – FESCo - https://fedorahosted.org/fesco/ticket/1221 18:31:53 Server: Spent the last two weeks organizing and filing Change Proposals 18:32:18 Work on the Role Infrastructure was stalled by my unavailability. 18:32:30 #info Server: Spent the last two weeks organizing and filing Change Proposals 18:32:34 #info Work on the Role Infrastructure was stalled by my unavailability. 18:34:48 other groups? 18:35:23 I know cloud has been busy filing changes and organising themselves in trac 18:36:07 #info Please, WG liaisons add the reports to the ticket if you have anything new to report 18:36:07 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 let's move on 18:36:31 dgilmore, that seems like a trivial thing to solve imo 18:36:46 workstation has been quiet. i've also been on PTO 18:36:49 jwb: there will be more deliverables than they want and list 18:37:13 #topic #1250 F21 Self Contained Changes 18:37:13 .fesco 1250 18:37:14 t8m: #1250 (F21 Self Contained Changes) – FESCo - https://fedorahosted.org/fesco/ticket/1250 18:37:26 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 anyway, we should discuss this elsewhere 18:37:41 So I suppose there are some self-contained changes that might be slightly controversial 18:38:20 I'm fine with all of them 18:38:25 anybody wants to exclude something from the list of changes to be approved in single vote? 18:38:26 I'm ok with all of them 18:38:32 * pjones has no objections 18:38:46 im okay with them all also 18:38:57 i'm OK with them. 18:39:09 I am actually OK with them all as well 18:39:49 I'm good with all of them 18:39:54 maybe all the hadoop ones could be merged into one 18:40:13 #agreed All F21 Self Contained Changes for 2014-04-09 meeting are approved (+7, -0, 0:0) 18:40:55 #topic #1269 Closing all 'Merge Review' bugs 18:40:55 .fesco 1269 18:40:57 t8m: #1269 (Closing all 'Merge Review' bugs) – FESCo - https://fedorahosted.org/fesco/ticket/1269 18:40:59 holy %^#% I lost track of time. Hi everyone :) 18:41:24 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 hi mattdm 18:41:36 sorry! 18:41:40 * mattdm reads scrollback 18:41:59 mattdm: we didn't assign you that much work, don't worry 18:42:01 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 does anyone want to take #action for the things we agreed on the last meeting? 18:42:28 ill take on organising the vfad 18:42:50 #action dgilmore to organise a vfad to finish off merge reviews 18:42:55 dgilmore++ 18:42:57 good 18:44:04 nirik, yep sending the devel-announce for provenpackagers seems to be the second #action needed 18:45:38 t8m: I can do that also, will fit in as part of organising a vfad 18:46:10 #action dgilmore will e-mail devel-announce to encourage provenpackagers to fix things from stalled merge reviews 18:46:37 finally onto new business 18:46:51 #topic #1272 Reschedule meeting for DST shift? 18:46:51 .fesco 1272 18:46:53 so now we talk about timezones? 18:46:54 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 unless we canb get done in an hour 18:47:43 I dont care. No preference. Will go with whatever is better for everyone else. 18:47:45 well, right now we're hitting new business in just under 50 minutes. 18:47:51 I have to go pick my daughter up at 2pm US Central time 18:48:10 #proposal let's move one hour earlier 18:48:13 +1 18:48:16 +1 18:48:20 +1 18:48:23 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 +1 18:49:00 0. 18:49:15 I have a slight preference for current time but a strong preference for accomodating dgilmore's needs 18:49:23 0 18:49:40 mattdm, will count you as 0 18:49:49 as long as that doesn't block the vote 18:50:08 mattdm: appears it passes anyway 18:50:09 we're already at +5 18:50:17 thanks all 18:50:30 #agreed The FESCo meeting is moved one hour earlier (+5, -0, 0:3) 18:50:51 #topic #1274 F21 System Wide Change: GCC49 - https://fedoraproject.org/wiki/Changes/GCC49 18:50:52 .fesco 1274 18:50:53 t8m: #1274 (F21 System Wide Change: GCC49 - https://fedoraproject.org/wiki/Changes/GCC49) – FESCo - https://fedorahosted.org/fesco/ticket/1274 18:51:31 +1 18:51:39 Proposal: Approve and schedule a mass-rebuild 18:51:40 +1 18:51:50 +1 18:51:52 +1 18:51:57 sgallagh: not sure we can do that yet 18:52:09 sgallagh, do we know of any other things that could need mass-rebuild? 18:52:18 Sorry, rephrasing "Account for it when we schedule a mass-rebuild" 18:52:24 sgallagh: there may be things other than gcc49 that need us to schedule a mass rebuild 18:52:24 dgilmore: not sure we can do one, or not sure we can schedule it yet? 18:52:37 notting: not sure we can schedule it yet 18:52:38 there's a ticket open to track that 18:52:40 in releng 18:52:48 dgilmore: ok, no problem. 18:53:03 * notting is +1 18:53:11 I think we're agreeing, just with different words 18:53:17 +1 to the Change proposal 18:53:21 +1 18:53:32 sgallagh, I think there is no controversy with the mass rebuild for gcc 4.9 18:53:39 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 #agreed F21 System Wide Change: GCC49 is approved (+7, -0, 0:0) 18:54:34 #topic #1275 F21 System Wide Change: GHC 7.8 - https://fedoraproject.org/wiki/Changes/GHC_7.8 18:54:34 .fesco 1275 18:54:35 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 +1 18:55:51 speaking of other things for mass rebuilds. 18:56:05 +1 18:56:08 +1 18:56:13 +1 18:56:14 +1 18:56:37 +1 18:56:45 +1 18:56:48 +1 18:56:50 Seems like the haskell-using packages could be mass-rebuilt within the mass rebuild 18:57:23 t8m: as long as we do not need to worry about build ordering 18:57:26 #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 #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 #topic #1276 F21 System Wide Change: lbzip2 as default bzip2 implementation 18:59:25 .fesco 1276 18:59:27 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 This one is more controversial 18:59:36 yeah... 18:59:44 there was quite some discussion on devel list 18:59:53 Yeah, "get more exposure to be accepted" / "be accepted to get more exposure" 18:59:59 Without a library interface, I'm a moderate -1 19:00:23 it does seem odd to replace just command line, but leave all the rest 19:00:37 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 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 there was some interest expressed in replacing the library bit too right? just not in scope for f21. 19:01:17 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 Moderate -1 as well, but wouldn't want to lose the the contribution/contributor. 19:01:30 t8m: I'm with you 19:01:50 Can we agree (but not strictly pre-commit) to criteria to approving this? 19:01:54 mitr: yeah, me too. -1, but if they can get the library side working so we can switch the entire thing... 19:02:16 t8m: yes. although mildly curious about the implications of an ABI-compatible library that introduces threads into decompression 19:02:34 notting, perhaps that could be some non-default option? 19:02:41 mitr: Yes, a compatible (preferably drop-in) replacement for the library would be my personal preference here 19:02:50 t8m: that's the main source of the speedup, isn't it? 19:03:11 sooooo.... 19:03:13 notting: Asking a single-threaded application to add a flag to be much faster isn't such a burden 19:03:23 mitr, exactly 19:03:24 proposal: mark bzip2 as deprecated in this release, intend to replace in f22 19:04:07 whats wrong with replacing the command line tool only for now? 19:04:10 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 drago01: "unexplicable" differences in behavior 19:04:38 drago01: the goal is one better implementation. a switchable implementation doesn't necessarily further that 19:04:41 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 "inexplicable" I'm pretty sure, but yeah. 19:05:04 mitr: which differences? 19:05:04 mitr: me too. 19:05:10 pjones: thanks 19:05:15 drago01: that's an awfully big "if" you're waiving around like a fait accompli there 19:05:52 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 mitr: that's not different behaviour thats a bug 19:06:42 so I am currently -1 with encouraging the author to work on the library 19:07:13 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 nirik: as it does... 19:08:09 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 #agreed F21 System Wide Change: lbzip2 as default bzip2 implementation was rejected 19:08:16 mitr +1 19:08:21 mitr, +1 19:08:22 (happy to accept a re-wording proposal, this doesn't read quite right) 19:08:25 mitr: +1 19:09:04 mitr: +1 19:09:21 mitr: I think "indication of project maturity" might be unfair 19:09:41 sgallagh: counterproposal? 19:09:42 If it's accepted as a Change, then we are implying that there is testing done on it 19:10:21 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 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 sgallagh: I'd call that an indication of project maturity 19:11:35 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 because you're saying "be a drop-in replacement for the thing you're cloning" 19:12:17 mitr: yeah, likewise. 19:13:17 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 anybody else would vote for the mitr's proposal? 19:13:27 0 19:13:51 mitr, are you +1 to yourself? 19:13:53 mitr: certainly we're not /introducing/ that burden; it's one he has (and all other software authors have) naturally. 19:13:59 t8m: +1 for the record 19:14:06 pjones: true 19:14:19 mitr: a copr with obsoletes: ... 19:14:23 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 #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 +1 19:14:37 I'd be +1 if we dropped the last part 19:14:46 #undo 19:14:46 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 mitr: +1 for the record 19:14:53 #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 #topic #1277 F21 System Wide Change: RPM-4.12 19:15:23 .fesco 1277 19:15:24 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 +1 from me 19:15:57 +1 19:16:05 +1 19:16:10 +LOTS 19:16:11 +1 19:16:16 +1 19:16:36 +1 19:16:50 +1, even if we won't use all the new stuff yet 19:16:55 #agreed F21 System Wide Change: RPM-4.12 is approved (+8, -0, 0:0) 19:17:17 #topic Next week's chair 19:17:27 * sgallagh will be at Summit next week 19:17:27 Anybody wants it? 19:17:49 why can't I get rid of the feeling this should be more difficult 19:17:57 who else other than sgallagh will be at summit? 19:18:23 ffesti, put more bugs into new releases and it might be :) 19:18:26 i.e. will we have enough people for a meeting 19:18:38 ? 19:18:44 ffesti: The hard part is getting the new features through FPC. 19:18:51 I'll be at summit too 19:19:09 * nirik won't be at summit, should be around. 19:19:20 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 good 19:19:38 #action notting will chair the next meeting 19:19:39 sgallagh, yup, that's expected. 19:19:41 * dgilmore will be around 19:20:00 #topic Open Floor 19:20:01 I'll show up for the meeting depending on summit schedule 19:20:14 Anybody has anything for Open Floor? 19:20:25 nothing here 19:20:27 * pjones will be around 19:21:08 * nirik has nothing 19:22:20 If nobody speaks up I'll close the meeting in a minute. 19:24:01 #endmeeting