=================================== #fedora-meeting: FESCO (2012-02-27) ===================================
Meeting started by nirik at 18:00:01 UTC. The full logs are available at http://meetbot.fedoraproject.org/fedora-meeting/2012-02-27/fesco.2012-02-27-18.00.log.html . Meeting summary --------------- * init process (nirik, 18:00:01) * #799 Issues with maintainer responsiveness (clamav) (nirik, 18:02:30) * LINK: https://bugzilla.redhat.com/show_bug.cgi?id=787434#c23 seems like a good reason not to rush changing things (mitr, 18:04:32) * AGREED: close ticket and ask for reporter to reopen with a real violation, or with a specific use case (as opposed to a single configuration item) that is broken by this packaging (nirik, 18:16:06) * #802 F17 Features - progress at Feature Freeze (nirik, 18:16:25) * LINK: http://gcc.gnu.org/ml/gcc-patches/2012-02/msg01219.html (nirik, 18:23:14) * ACTION: check on RealHotSpot / NMEnterprisenetworking and close ticket. (nirik, 18:24:56) * #803 Add johannbg to provenpackager explicitly to work on sysv2systemd conversion (nirik, 18:25:32) * AGREED: The proposal doesn't pass. (nirik, 18:44:22) * LINK: https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd-F17 (nirik, 18:45:55) * #806 Request for exception for iptables and ip6tables to provide a small init script (nirik, 18:47:25) * AGREED: ask FPC if we can add to systemd guidelines to allow for non standard service commands to continue to work in a systemd world. (nirik, 19:05:29) * ACTION: nirik to file a FPC ticket asking for them to look into this. (nirik, 19:06:22) * #810 Clarify our position on forks (nirik, 19:06:51) * AGREED: forks are allowed provided they do not conflict or interfere with other packages. FPC may add additional guidelines to forks as they see fit" (nirik, 19:21:38) * Open Floor (nirik, 19:21:47) * ACTION: limburgher will announce systemd migrations for f17 accepted until Beta, include link to BZ list and invite PP assistance. (limburgher, 19:27:57) * AGREED: for ibus (ticket 798): treat other cases (e.g. ibus running in en_US) as bugs, no FESCo decission necessary (nirik, 19:36:12) * ACTION: notting to chair next week. (nirik, 19:41:13) Meeting ended at 19:41:22 UTC. Action Items ------------ * check on RealHotSpot / NMEnterprisenetworking and close ticket. * nirik to file a FPC ticket asking for them to look into this. * limburgher will announce systemd migrations for f17 accepted until Beta, include link to BZ list and invite PP assistance. * notting to chair next week. Action Items, by person ----------------------- * limburgher * limburgher will announce systemd migrations for f17 accepted until Beta, include link to BZ list and invite PP assistance. * nirik * nirik to file a FPC ticket asking for them to look into this. * notting * notting to chair next week. * **UNASSIGNED** * check on RealHotSpot / NMEnterprisenetworking and close ticket. People Present (lines said) --------------------------- * nirik (135) * mitr (61) * mjg59 (51) * sgallagh (51) * pjones (36) * notting (36) * Viking-Ice (30) * limburgher (25) * t8m (19) * zodbot (10) * rbergeron (7) * tibbs (4) * drago01 (2) * OzBorne (1) * mmaslano (0) -- 18:00:01 <nirik> #startmeeting FESCO (2012-02-27) 18:00:01 <zodbot> Meeting started Mon Feb 27 18:00:01 2012 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot. 18:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic. 18:00:01 <nirik> #meetingname fesco 18:00:01 <zodbot> The meeting name has been set to 'fesco' 18:00:01 <nirik> #chair notting nirik mjg59 mmaslano t8m pjones sgallagh mitr limburgher 18:00:01 <nirik> #topic init process 18:00:01 <zodbot> Current chairs: limburgher mitr mjg59 mmaslano nirik notting pjones sgallagh t8m 18:00:09 <nirik> who all is around for a fesco meeting? 18:00:12 * notting is here 18:00:13 <t8m> Hi 18:00:15 <pjones> I am here this time. 18:00:16 * sgallagh waves 18:00:24 <pjones> (sorry about last week; was busy saving the world.) 18:00:24 <mitr> Hello all 18:00:54 <mjg59> Hi 18:01:13 <nirik> pjones: cool. I like the world... 18:01:50 <sgallagh> I'd rather we gave up on this one and started exploring other worlds 18:02:25 <pjones> sgallagh: noted. 18:02:27 <nirik> ok, shall we go ahead and get started? 18:02:30 <nirik> #topic #799 Issues with maintainer responsiveness (clamav) 18:02:30 <nirik> .fesco 799 18:02:32 <zodbot> nirik: #799 (Issues with maintainer responsiveness (clamav)) – FESCo - https://fedorahosted.org/fesco/ticket/799 18:02:48 * limburgher here 18:03:05 <sgallagh> So it does look like there are actual packaging violations at play here, if I read it correctly 18:03:07 <nirik> so, I don't see any comment from the maintainer... which is sad. 18:03:25 <pjones> sgallagh: also the bullshit watermark is pretty high 18:03:46 <sgallagh> pjones: Sorry, ambiguous. Whose bullshit are you referring to? 18:03:58 <pjones> oh wait, was looking at the wrong ticket. sorry. 18:04:04 <mitr> sgallagh: If you are referring to comment#9, I can't see that these are actually violations 18:04:32 <mitr> https://bugzilla.redhat.com/show_bug.cgi?id=787434#c23 seems like a good reason not to rush changing things 18:05:33 <sgallagh> mitr: That reads more like "the approach will be ineffective" not harmful 18:05:48 <sgallagh> Because it won't work for existing installations, especially those using config management 18:06:21 <mitr> sgallagh: opening up the file permissions but restricting the config file only on new installations => upgrades are insecure, IIUC 18:06:25 <nirik> people using config management need to handle things themselves... we can't never change config for them. 18:07:01 <sgallagh> I'm inclined to agree that we shouldn't try to change config in %post anyway 18:07:24 <sgallagh> That this has changed should be called out in the bodhi update text 18:07:27 <nirik> so, what do we want to do here? look at appointing someone to mediate that could look at both sides? 18:07:46 <sgallagh> Do we have a FESCo member with ClamAV experience? 18:08:01 <sgallagh> (also, the lack of response from the maintainer may make this difficult) 18:08:13 <limburgher> Some, not too in depth. 18:08:19 <mitr> sgallagh: ensc did update the clamd-README .... but didn't add the required rationale 18:08:19 <nirik> I dislike/can't stand the current fedora clamav spec. 18:08:26 <limburgher> Used to run it on my old email server. 18:08:27 <nirik> so, I would likely not be unbiased. 18:08:54 <mjg59> Are we still at the point that what we have is a disagreement over packaging without any specific complaints about policy violation? 18:09:06 <mjg59> specific *and* justifiable, that is 18:09:14 <t8m> I think so 18:09:19 <limburgher> That's my interpretation. 18:09:43 <mjg59> And we're being asked to overrule the maintainer? 18:09:44 <nirik> I asked for specifics in the ticket. 18:10:06 <pjones> if there are yet to be specifics produced, it's really not clear that it's our problem to solve. 18:10:11 <mjg59> Can we just punt this until there are actual specifics? 18:10:15 <nirik> the first one doesn't seem a violation... the second seems like a bug. 18:10:31 <mjg59> Because right now for better or for worse we tend to let maintainers do their thing on the assumption that they know how to do their thing 18:10:40 <sgallagh> My personal view: I don't like the way ClamAV is packaged, but if it works for the primary maintainer, we should just let it continue as-is. 18:10:49 <t8m> sgallagh, +1 18:10:51 <mjg59> And if they're not breaking other packages in the process then hey go wild 18:11:02 <mitr> The second one is not a violation either - the updates policy mandate "don't change user experience" is not applicable to how things are packaged in general, unless they changed in an updated 18:11:21 <mjg59> Yeah, it seems like an F15->F16 change 18:11:24 <mjg59> Not an update 18:11:27 <t8m> yes 18:11:42 <limburgher> So then it's acceptable, esp. if it's in the relnotes. 18:11:55 * nirik is looking for that commit 18:12:31 <mitr> "not breaking other packages" is not enough IMHO - it should also not be breaking legitimate use cases. But it seems that the current packaging does make it possible to do what philipp wants to do, although in a different way. 18:12:49 <pjones> it does kindof suck, but... if FPC doesn't want that to be true, they have the power. Until then, there's no real reason for intervention. 18:13:41 <nirik> ok, so does anyone wish to propose an action here? defer ? ask for a specific violation? close? 18:13:43 <notting> if no one from fesco would like to volunteer, should we tap a third-party in the community to adjudicate? 18:13:57 <sgallagh> Proposal: Not our problem. WONTFIX. 18:13:58 * nirik would be fine with a mediator if we could find one. 18:15:04 <mitr> +1 to sgallah, perhaps softening that to "reopen with a real violation, or with a specific use case (as opposed to a single configuration item) that is broken by this packaging" 18:15:10 <mjg59> +1 18:15:14 <notting> +1 18:15:27 <limburgher> +1 18:15:33 <t8m> +1 18:15:40 <sgallagh> +1 to the rewording 18:15:49 * nirik is ok with that I guess... +1 18:15:58 <sgallagh> My tact-processor has been on the fritz lately 18:16:06 <nirik> #agreed close ticket and ask for reporter to reopen with a real violation, or with a specific use case (as opposed to a single configuration item) that is broken by this packaging 18:16:13 * mitr fully expects the ticket to be reopened... 18:16:20 * nirik too 18:16:25 <nirik> #topic #802 F17 Features - progress at Feature Freeze 18:16:25 <nirik> .fesco 802 18:16:26 <zodbot> nirik: #802 (F17 Features - progress at Feature Freeze) – FESCo - https://fedorahosted.org/fesco/ticket/802 18:16:29 <pjones> +1 18:16:43 <pjones> not to progress at feature freeze, obviously. 18:16:48 <mitr> #note FESco required rationale for the current packaging, which has not been documented yet 18:16:51 <nirik> so, did we get all our reports in? did we want to move things/check if they all moved? 18:18:27 <rbergeron> pjones: LOL 18:18:37 <mitr> NMEnterpriseNetworking eems to be the only unknown on th e critical list 18:18:59 <pjones> rbergeron: well, it didn't seem like it's the sort of thing you can really be for or against ;) 18:19:23 <sgallagh> FWIW, the issue with systemd and PrivateTmp has been resolved last week 18:19:33 <rbergeron> pjones: mustard! 18:19:42 <rbergeron> enterprise networking got updated to 75% 18:19:48 <sgallagh> pjones: Sure you can be against progress. For reference, see any politician. 18:19:53 <rbergeron> on 2/24 18:19:57 * rbergeron is failing to raise her hand, sorry 18:20:15 <zodbot> Beefy Miracle: The mustard indicates progress. 18:20:25 * nirik notes https://fedoraproject.org/wiki/Features/RealHotspot still says f17 at 30%... 18:20:32 <nirik> I think it's really gonna have to go to f18. 18:20:36 <pjones> sgallagh: that's progress as an action; this is progress as a question. 18:21:04 <nirik> I can ask dcbw for sure. 18:21:11 <nirik> and NMEnterprise. 18:21:18 <nirik> Do we have any other outstanding ones? 18:21:49 <rbergeron> not from the fesco list, i don't think; I'm still making progress with the Shiny stuff. 18:22:00 <mitr> More importantly, are there any we need to worry about? 18:22:01 * rbergeron really thanks everyone for their wrangling assistance here 18:22:16 * mitr has heard something about more rebuilds necessary for gcc 4.7 18:22:24 <nirik> shall we leave this ticket open to keep tracking? or close now? 18:22:28 <nirik> mitr: yeah, sadly. ;( 18:22:58 <sgallagh> nirik: Let's leave it open until we have an answer on RealHotspot, but then close it. 18:23:02 <notting> correct, there was an unintentional C++ ABI break that needed fixed, which requires rebuilding 18:23:14 <nirik> http://gcc.gnu.org/ml/gcc-patches/2012-02/msg01219.html 18:23:27 <nirik> sgallagh: sounds fine to me. 18:23:28 <sgallagh> notting: Only C++ packages? 18:23:47 <notting> sgallagh: correct. (and only C++ ones that use a specific feature/class/etc) 18:23:53 <sgallagh> ok 18:23:59 <sgallagh> So rebuilds, not mass-rebuilds 18:24:33 <nirik> dgilmore was going to identify the packages and rebuild them 18:24:35 <notting> *shrug* it's a matter of how much mass 18:24:56 <nirik> #action check on RealHotSpot / NMEnterprisenetworking and close ticket. 18:25:01 <nirik> anything else on this one? 18:25:31 <nirik> ok, on to new business... 18:25:32 <nirik> #topic #803 Add johannbg to provenpackager explicitly to work on sysv2systemd conversion 18:25:32 <nirik> .fesco 803 18:25:33 <zodbot> nirik: #803 (Add johannbg to provenpackager explicitly to work on sysv2systemd conversion) – FESCo - https://fedorahosted.org/fesco/ticket/803 18:26:00 <nirik> Viking-Ice: you around? anything you want to note here? 18:26:10 <sgallagh> I wish someone had asked Johann before we filed this ticket. But I'm in favor of granting him this privilege. 18:26:23 <nirik> mmaslano has a -1 in ticket. 18:26:26 <sgallagh> I know mmaslano had some reservations about his collaboration 18:26:32 <sgallagh> yeah 18:27:01 <Viking-Ice> not really 18:27:07 <mitr> This is clearly a second best to maintainers caring about their packages... 18:27:39 <mitr> ... but then, when the maintainers don't care, I can't see a good cause for preventing other people from changing the packages. 18:27:53 <sgallagh> Yeah, that's my opinion to a tee 18:27:59 * nirik nods. 18:28:05 <Viking-Ice> the problem we are faced with are clearly outlined in that ticket and by adding me to the pool of proven packagers results in less time to migrate more time to package instead 18:28:05 <sgallagh> Maintainers have had plenty of time to make this change themselve. 18:28:12 <mitr> (note that this is only an "enablement", not a "request to do more work", at least the way I read the ticket) 18:28:15 <nirik> I think there's a lot of 'I'll apply this when I have time to look and understand systemd' and that time never comes. 18:28:26 <notting> mitr: would seem sort of odd to do enablement w/o expectation 18:28:38 <nirik> Viking-Ice: how many more are around to migrate/ 18:28:57 <mitr> notting: The ticket is sort of odd :) 18:29:22 <nirik> I guess we also didn't send this to sponsors for feedback? 18:29:25 <nirik> or did we 18:29:33 <t8m> I have to say I have some reservations about Viking-Ice communication abilities as well. 18:29:47 <notting> nirik: no, because it didn't seem to be of the normal sort. (and was put on the meeting agenda almost immediately anyway) 18:29:59 <nirik> yeah, it's a bit different. 18:30:13 <Viking-Ice> nirik, none today other than me ( others have left due flames and unresponsive packagers left after F15 more or less ) otherwise we had migrated all the stuff already ( since I've migrated units for 100+ components by myself for f17 aline ) 18:30:23 <pjones> well, it is and it isn't. I mean, we've got a specific reason here, but he'd still be getting the bit set, right? 18:31:20 <mitr> I'm not too worried about the bit - git makes reverting easy enough, and in general I prefer opening up provenpackager somewhat more anyway 18:31:32 <nirik> Viking-Ice: well, I meant how many services don't have a bug with a patch to migrate them? is that what you are working on mostly? or are all those done now? 18:31:37 <notting> given Viking-Ice's comment about it resulting in less time to migrate, and his request to not have 'special treatment', i'd be inclined to -1 the ticket on those grounds and just going to the normal process. 18:32:07 <notting> TBH, bringing someone into PP to commit changes of this sort seems a bit odd if it's about existing in bugzilla changes - if we want those to happen from PP, any one of us could do it now 18:32:10 <pjones> mitr: fair point, but it's still not that different as a result. 18:32:27 <pjones> notting: and yet we haven't. 18:32:41 <mjg59> If he wants to do it, I'm in favour of enabling it. If he doesn't want to do it, I don't think we should do anything 18:32:47 <mitr> mjg59: +1 18:32:53 <pjones> I can be +1 to that. 18:33:08 <mjg59> (Other than, y'know, we should step up and do the work ourselves and all) 18:33:12 <Viking-Ice> nirik, sorry not following I'm currently finishing packages that start with M of the alphabet A --> M is more or less done migrating and have units attached to them 18:33:22 <nirik> Viking-Ice: ok, cool. 18:33:36 <mjg59> Viking-Ice: Would PP make your life better? 18:33:43 * nirik would be inclined to say -1 to this for now, and let Viking-Ice continue to migrate services. 18:33:51 <mitr> Viking-Ice: so it's a reasonable assumption that granting the privilege would be a no-op at least for the f18 development process? 18:34:01 <nirik> perhaps we could try and revive some FES action and file a bug asking provenpackagers to work on these specifically. 18:34:32 <Viking-Ice> mjg59, I could do more work not only in the migration process but if/when logging stuff needs to fixed as well due to journal 18:35:21 <mitr> Viking-Ice: "the logging stuff" is much more controversial, let's not open that right now... 18:35:27 <Viking-Ice> not having PP means less work for me in the long run more work for PP and maintainers 18:35:43 <Viking-Ice> in general 18:35:53 <Viking-Ice> and longer completion of features as well 18:36:14 <Viking-Ice> I'm always happy having to do less work =) 18:36:24 <limburgher> sorry, /me was called away. back now. 18:36:32 <pjones> yeah, let's not discuss "journal" right now. 18:36:38 <nirik> so, whats our votes? 18:37:08 <Viking-Ice> basically what I seek is the ability to do less nagging more helping 18:37:34 <Viking-Ice> then I can just channel my frustration if I encounter any in fixing things 18:37:37 <mjg59> +1 then 18:37:41 <pjones> +1 18:38:09 <tibbs> Did this request get run by the rest of the provenpackagers as usual? If so I must have missed it. 18:38:24 * nirik is a weak -1 (would prefer more migrating until we get those done) and possibly we can ping other pp's to work on that end. 18:38:24 <notting> tibbs: no, see scrollback 18:39:07 <mitr> Given the past disagreements, could we agree that the PP is not used to override maintainer's technical objections (i.e. "I don't want it done this way" vs. "I don't have time")? 18:39:33 <notting> that sort of goes with the PP territory in general 18:39:41 <Viking-Ice> btw PP privileges can be revoked right or does that never happen? 18:39:53 <pjones> Viking-Ice: well, it never has, but we do reserve the right 18:39:56 * nirik notes we would also have to grant packager here. 18:40:06 <nirik> I think we have actually done so once. 18:40:09 <Viking-Ice> if people are unhappy with my work those privileges can always be revoked right? 18:40:22 <pjones> if we're that unhappy, yes. 18:41:01 <nirik> more votes? (+2 / -2 so far) 18:41:04 <Viking-Ice> I think trial period is in order for people that like we that dont want to be packager but do want to help if we can 18:41:14 <limburgher> Eh. +1. Less work for the rest of us. 18:41:20 <Viking-Ice> and by packager in this term I mean maintain package in the distribution 18:41:29 <nirik> +3/-2 18:41:45 <notting> -1 for same reasoning as stated earlier. also, PP w/o packager first seems odd. 18:41:52 <limburgher> Except he's not a sponsored packager? 18:41:52 <nirik> +3/-3 18:41:58 <limburgher> Oh. 18:42:36 <sgallagh> I'm +0 18:42:43 <t8m> I'm +0 as well 18:42:45 <pjones> Well, the proposal fails. 18:42:45 <limburgher> I didn't realize that. -1. Nothing personal, but I think pp requires a level of experience with the SCM and build system. 18:42:45 <mitr> Given that this is explicitly restricted to systemd conversion, +1 ... 18:43:05 <limburgher> I'll keep helping though. :) 18:43:24 <tibbs> Has there been a more public call for other PP folks to get involved with this? 18:43:44 <tibbs> I mean, I don't even recall seeing any report about how many packages remain to be converted. 18:43:59 <nirik> There's a feature page with a list. 18:44:22 <nirik> #agreed The proposal doesn't pass. 18:44:23 <mitr> tibbs: Viking-Ice has been fairly vocal on fedora-devel 18:44:28 <nirik> we could mail provenpackagers? 18:44:37 <Viking-Ice> not from me no but this has been a know issue after looking and analyze the migration process from F15 18:44:51 <Viking-Ice> mitr, I've not been vocal on devel in F17 18:44:54 <tibbs> I mean, I see a lot of flaming and was the recipient of insults myself, but I don't recall seeing a simple list of what remains to be done. 18:45:42 <Viking-Ice> flaming on my behalf? 18:45:55 <nirik> https://fedoraproject.org/wiki/User:Johannbg/Features/SysVtoSystemd-F17 18:46:49 <nirik> so, do we want to make a announcement to provenpackagers? or just move on. 18:46:56 <sgallagh> I feel like we've been on this topic for too long already today 18:47:03 <pjones> indeed. 18:47:08 <nirik> ok. 18:47:15 <pjones> nirik: I'm all for trying to get the issue some more publicity 18:47:25 <nirik> #topic #806 Request for exception for iptables and ip6tables to provide a small init script 18:47:25 <nirik> .fesco 806 18:47:26 <zodbot> nirik: #806 (Request for exception for iptables and ip6tables to provide a small init script) – FESCo - https://fedorahosted.org/fesco/ticket/806 18:47:29 <nirik> pjones: me too. 18:48:29 <pjones> I'm mildly +1 on this, but before I'm really +1 it seems like there should be a plan in place to fix docs and such to refer to some other mechanism. 18:48:33 <t8m> I'm fine with that although some general solution would be nice as well. 18:48:37 <pjones> (another mechanism may also be good to have in place) 18:48:41 <nirik> so, on this one, I thought just shipping some stub init scripts would make sense, but seems like scope has expanded a lot. 18:48:42 <t8m> So +1 18:48:54 <mitr> I'm -1 to iptables-specific fixes. 18:49:00 <mitr> This is not an iptables problem. 18:49:04 <notting> nirik: stub init scripts would work OOTB. scripts somewhere else require further infrastructure. 18:49:11 <sgallagh> I'm -1 on this. I think that if systemd is going to provide a compatibility layer, it should be 100% compatible 18:49:42 <sgallagh> Sorry, that was poorly phrased. 18:49:50 <nirik> I fear if we wait for the 'solve all these' solution it will be so long from now that everyone will have already moved on. ;) 18:49:59 <mitr> sgallagh: "/sbin/service" is owned by Fedora's own initscripts. systemd is not 100% compatible, that ship has sailed I'm afraid. 18:50:48 <sgallagh> I would prefer that we avoid exceptions, especially exceptions for such core functionality. 18:51:50 <nirik> so, I'm also ok with passing the buck to FPC, but we should be clear on what we are asking them. Change to allow stubs? change to allow these non standard things somehow? something else? 18:52:22 <mitr> notting: where "further infrastructure" is ~10 lines of shell code + one directory, right? I suppose the important question is "how many of the packagers would do the work to add back the non-standard actions". 18:52:59 <nirik> this should also just be a temp compat thing... it should point them to the new command. 18:52:59 <notting> mitr: it's defining new, fedora-specific inifrastructure, yes. 18:53:23 <mitr> nirik: _which_ new command? iptables upstream does not provide the same functionality. 18:53:23 <notting> mitr: whereas packaging the old initscript as well is at least not fedora-specific 18:53:34 <mjg59> I can sort of see this for F15 and F16 18:53:45 <mjg59> And /arguably/ F17 if it's purely for the static firewall case 18:53:58 <mjg59> But only if that code is absolutely being dropped in F18 18:54:22 <nirik> mitr: '/usr/libexec/iptables.init save' I guess... 18:54:37 <nirik> mjg59: yeah, and the boat has already left the harbor 18:55:08 <mitr> mjg59: "we broke Fedora's usual commands, we'll temporarily fix them but break them again in a year"? That doesn't make sense to me. 18:56:02 <nirik> yeah, so perhaps the window has closed and we should just say no thanks to the entire thing. 18:56:09 <pjones> nirik: pointing people to the new command there sucks; there's automation to consider. 18:56:12 <mitr> Considering that these special actions were Fedora/RHL-specific for so long (decades in the case of iptables), I can't see a good cause for upstreams to suddenly accept this functionality 18:56:42 <nirik> pjones: ? someone automates iptables save? that seems... an odd way to do things. 18:56:56 <mitr> nirik: kickstarts? 18:57:01 <mitr> ... right, odd 18:57:01 <mjg59> mitr: It's a transition to new commands. If the expectation was that those commands continue working in old releases then we should make sure they keep working 18:57:02 <pjones> nirik: for example system-config-firewall? 18:57:13 <mitr> mjg59: _which_ new commands, again? 18:57:21 <mjg59> If there's no expectation of that then the new way of doing things should be documented and this entirely ignored 18:57:31 <nirik> pjones: it calls the init script? I would hope not, but who knwos... 18:57:32 <mitr> I think we can either decide that a) all special commands should arrive upstream, and it's fine to break the Fedora-specific commands, or b) Fedora will have non-upstream commands, and in this case there's absolutely no reason to break the old ones 18:58:08 <mjg59> mitr: I was under the impression that the new dynamic code would have support for saving and restoring rulesets 18:58:27 <mitr> mjg59: That merely avoids the iptables problem, doesn't solve the general case. postgresql, network, ... 18:58:40 <notting> to clarify: i'm fine with an exception for iptables for shipping the old init script to support these. i'm a little leery of creating a fedora-specific extensions to the /sbin/service helper script that won't be exposed elsewhere. 18:58:42 <mjg59> Yes. They all need to provide equivalent functionality 18:59:02 <mjg59> Or, alternatively, accept that there's been a reduction in functionality, and that should be documented 18:59:23 <nirik> I think they all do, but they are just different commands now... 18:59:33 <nirik> since they can't hang off service/the init script 18:59:47 <mjg59> If it's "This old howto doesn't work any more" then CLOSED->WELCOME_TO_2000 19:00:55 <mitr> mjg59: Breaking users' functionality without providing them any benefit in return? what's the point? 19:01:19 <mjg59> mitr: Backward-compatibility via Fedora-specific hacks? 19:01:34 <mitr> mjg59: Backward compatibility to Fedora-specific code would necessarily be Fedora-specific 19:01:34 <nirik> I still think it's worth it to provide the old command as a compat option for a few more releases... 19:01:53 <nirik> but perhaps I am in the minority. 19:02:02 <mjg59> I'm struggling with why "This old way no longer works, you have to do it a new way" is an unacceptable option 19:02:12 <mjg59> Given that that's what we upload approximately every 30 seconds 19:02:37 <nirik> mjg59: the only pointer to 'the new way' is in release notes or other places no one reads/ 19:02:41 <mjg59> If we're committing to providing backwards compatibility, then let's make that policy 19:02:50 <mjg59> If we're not, then let's get on with life 19:03:23 <nirik> proposal: ask FPC if we can add to systemd guidelines to allow for non standard service commands to continue to work in a systemd world. 19:03:27 <t8m> we are not committing to anything (mostly) 19:03:47 <notting> nirik: +1 19:03:47 <mjg59> So let's get on with life 19:03:49 <t8m> nirik, +1 19:03:54 <mitr> mjg59: Given that it would take someone ~4-16 hours to keep the old way working, and save ~4 hours for thousands of users.... the tradeoff seems easy enough for me, especially where there is 0 benefit to doing ti the other way 19:03:54 <mjg59> It's just another case where we broke backwards compatibility 19:04:00 <mitr> +1 19:04:05 <nirik> right. 19:04:18 <mjg59> mitr: The benefit is that we don't end up carrying Fedora-specific hacks for an arbitrary period of time 19:04:25 <mjg59> So I'm -1 19:04:36 <nirik> +4/-1 19:04:39 <nirik> more votes? 19:04:56 <sgallagh> +1 why not 19:04:57 <t8m> mjg59, yep I noticed that we are very happy to break backwards compatibility very often for no real reason recently 19:05:15 <nirik> +5/-1 19:05:23 <mjg59> I'm entirely in favour of requiring that this kind of thing be documented, though 19:05:29 <nirik> #agreed ask FPC if we can add to systemd guidelines to allow for non standard service commands to continue to work in a systemd world. 19:05:38 <nirik> would someone step up to file a FPC ticket ? 19:05:42 <mitr> mjg59: Where is the line betweeen "Fedora functionality" and "Fedora-specific hack"? In the extreeme, what good does a "Fedora distribution" do if everything it does is "a Fedora-specific hack"? 19:05:51 <pjones> I'm very +0 on this. Very difficult to care about more than "it needs to be documented". 19:06:08 * nirik can do so if no one else wants to. 19:06:20 <t8m> mitr, +1 19:06:20 <notting> nirik: that sounds like volunteering! 19:06:22 <nirik> #action nirik to file a FPC ticket asking for them to look into this. 19:06:39 <nirik> anything else here? 19:06:51 <nirik> #topic #810 Clarify our position on forks 19:06:51 <nirik> .fesco 810 19:06:53 <zodbot> nirik: #810 (Clarify our position on forks) – FESCo - https://fedorahosted.org/fesco/ticket/810 19:07:22 <pjones> sgallagh: also the bullshit watermark is pretty high 19:07:25 <sgallagh> Proposal: (as made on devel@): Forks should be allowed if they can be parallel-installed. 19:07:29 <sgallagh> hahaha 19:07:30 <pjones> (there we go, got that on the right ticket) 19:07:52 <t8m> sgallagh, +1 19:07:57 <nirik> mmaslano has "+1 for accepting forks, but it needs defined boundaries, probably given by FPC." 19:08:02 <nirik> in ticket 19:08:14 <mjg59> Most of the arguments in favour of this are also arguments in favour of bundled libraries, providing that the maintainer is aware of the bundled library 19:08:42 <pjones> mjg59: not necessarily; you could read it in favor of also having forked libraries 19:08:43 <sgallagh> mjg59: I'm not sure that's true. I think this is an argument for how to unbundle 19:09:05 <nirik> If we say 'no forks', who's going to remove libreoffice and repackage openoffice. ;) 19:09:06 <mjg59> Bundled libraries are ok if you make them a subpackage? 19:09:12 <mitr> mjg59: ... which the maintainer demonstrates by unbundling the library, resulting in a "fork" 19:09:17 <mitr> +1 to sgallagh 19:09:18 <pjones> mjg59: right. 19:09:27 <limburgher> sgallagh: +1 19:09:47 <mjg59> I'm +1 providing that FPC will define broader policy 19:09:48 <t8m> mjg59, not a subpackage - full package with real upstream releases 19:10:02 <notting> with the specific example that generated this, even if it's not signficantly different now, it's certainly implied that it *will* diverge in short order 19:10:08 <mjg59> notting: Oh sure 19:10:21 <mjg59> notting: I look forward to seeing how many copies of gconfd we can have running at once 19:10:23 <pjones> yeah, the key difference is real upstream releases. the trick is going to be in telling if that requirement is satisfied before there's a second one. 19:10:48 <pjones> notting: perhaps it's not worth allowing until it has? 19:11:25 <nirik> I think any qualitative measure may be doomed... if we require 2 releases, someone could just do another one... etc. 19:11:25 <notting> pjones: not accepting forked version of mutter in this case would require non-upstreamable changes to miuffin's dependencies, so... meh. 19:11:28 <mitr> mjg59: I find it sort of hard to believe that an UI fork would feel the need to fork gconfd as well 19:11:31 <mjg59> pjones: Except then we're forbidding Gnome forks because we're part of the Gnome 3 cabal 19:11:36 <mjg59> mitr: Yeah, uh. 19:11:44 <pjones> mjg59: *eyeroll* 19:11:47 <mjg59> mitr: At least one of them did 19:12:56 <mjg59> Anyway. I think this is probably going to end up as a great way to get more mostly bitrotting code into the distribution because people are unable to play nicely together, but if it weren't for that then we'd probably all be running Minix, so +1 19:13:04 <nirik> Proposal: ask FPC to clarify when Forked packages are acceptable to add to the collection, taking into account parallel installing, lack of interfereing with other packages, viability of maintainance. 19:13:19 <mjg59> Providing FPC stuff and yeah what nirik says 19:13:25 <limburgher> +1 19:13:29 <nirik> (I guess drop the last bit. 19:13:39 <nirik> since we don't require any level of maint already. 19:13:41 <mitr> I'd s/viability of maintenance// away, we never ask about this for new packages 19:13:42 <limburgher> Right. 19:13:49 <drago01> (fwiw the mutter fork makes no sense because mutter is not supposed to be tied to gnome-shell but ot) 19:13:49 * nirik nods. 19:13:49 <limburgher> Or old ones. 19:13:56 <notting> is there a reason it needs to go to fpc? 19:14:01 <nirik> Proposal: ask FPC to clarify when Forked packages are acceptable to add to the collection, taking into account parallel installing, lack of interfereing with other packages, or other factors. 19:14:13 <notting> i.e., "proposal: forks are allowed provided they do not conflict or interfere with other packages" 19:14:20 <mitr> +1 to notting 19:14:26 <sgallagh> +1 to notting 19:14:27 <nirik> yeah, I suppose not... 19:14:33 <t8m> +1 to notting 19:14:36 <mitr> Let's involve FPC when actual conflicts need to be solved, and the involved parties have something specific to discuss 19:14:46 <mjg59> I'd like some definition of what interfering with other packages actually means 19:14:49 <notting> oh, also: provided they are not the kernel. 19:14:51 <sgallagh> Ultimately, a fork is no different than allowing in two disparate packages with similar functionality. 19:15:07 <drago01> notting: hah good point 19:15:18 <sgallagh> mjg59: Not shipping a competing libc, for example? 19:15:24 * nirik gets to packaging mock microkernel. 19:15:45 <mjg59> As long as I call it libsuperc.so that'd be fine? 19:15:47 <pjones> sgallagh: why not? we've shipped several before. 19:15:55 <mitr> sgallagh: Hm, we had "interesting" discussions about dietlibc and others 19:15:59 * nirik has to step away for a minute. 19:16:04 <sgallagh> pjones: I meant where it assumed libc.so 19:16:10 <sgallagh> If it's libsuperc.so, that's fine with me 19:16:30 <mitr> I guess I don't care about packaging forks, but we'd want to know if any are dragged into the default DVD / $other_important_package_set 19:16:30 <sgallagh> I just would want people to have to target it specifically at link-time 19:16:36 <mjg59> But, for instance, if you have two packages that have no filespace collisions but use the same socket name? 19:16:47 <mitr> s/any/two or more forks/ 19:16:52 <pjones> mjg59: oh, like gconfd and whateverconfd? 19:16:54 <notting> mjg59: like... nginx and apache? 19:17:01 <mjg59> pjones: That kind of thing, yes 19:17:04 <mjg59> notting: Ha. 19:17:19 <mjg59> notting: Less bad with leaf packages, I guess 19:17:37 <sgallagh> mjg59: I think socket collision still falls in my "parallel-installable" restriction I proposed 19:17:46 <mjg59> But if there's an assumption that these stacks are parallel installable then the entire stack needs to be audited for that 19:18:01 <mjg59> Because otherwise breakage will be subtle and unexpected 19:18:32 <nirik> FPC may come up with some additional guidelines/policy for forks... dunno. 19:18:46 * nirik is +1 in general, but wouldn't mind FPC weighing in. 19:19:58 <nirik> how about: "proposal: forks are allowed provided they do not conflict or interfere with other packages. FPC may add additional guidelines to forks as they see fit" ? 19:20:07 <notting> wfm. +1 19:20:15 <limburgher> nirik: +1 19:20:17 <mitr> +1 19:20:29 * nirik is +1 too 19:21:23 <t8m> no problem +1 19:21:24 <sgallagh> +1 19:21:38 <nirik> #agreed forks are allowed provided they do not conflict or interfere with other packages. FPC may add additional guidelines to forks as they see fit" 19:21:47 <nirik> #topic Open Floor 19:21:53 <nirik> Anyone have items for open floor? 19:21:54 <Viking-Ice> I got one 19:21:58 <sgallagh> Yes 19:22:05 <sgallagh> Viking-Ice: Go ahead 19:22:07 <nirik> go head Viking-Ice ... 19:22:21 <Viking-Ice> clear if systemd units are allowed to be shipped up to beta like they could last release cycle 19:22:29 <Viking-Ice> afaik nothing has changed to not warrant that? 19:22:52 <notting> we certainly haven't decided/voted on any changes to that 19:22:58 <notting> afair 19:23:08 <sgallagh> Seems reasonable to me 19:23:14 <t8m> yep 19:23:55 <Viking-Ice> did not think so but maintainers are unsure so if you send any announcement to -devel regarding systemd that info should be included in that announcement ( if it's allowed or not ) 19:23:58 <nirik> yeah, I'm fine with that... 19:24:31 <nirik> any objections? would someone like to send out an announcement? 19:25:43 <limburgher> I have no objections if the maintainers agree and/or do it themselves. 19:26:05 <Viking-Ice> well PP helping should be building this for F17 in that case 19:26:29 <limburgher> I can do the announcement, do we want to go over wording, or should I Just Do It? 19:26:53 <mitr> just do it :) 19:26:55 <nirik> limburgher: fine with me if you want to just do it. ;) Might also point to the list and note that pp's are welcome to help. 19:26:57 <limburgher> Viking-Ice: Now that we've got that cleared up, going forward, with the maintainer's ok, yes. :) 19:27:09 <Viking-Ice> =) 19:27:14 <limburgher> Will do. 19:27:57 <limburgher> #action limburgher will announce systemd migrations for f17 accepted until Beta, include link to BZ list and invite PP assistance. 19:28:07 <nirik> excellent. 19:28:38 <nirik> sgallagh: ? 19:29:42 <sgallagh> When do we want to start looking at F18 Features? I know of a few that are already in FeatureReadyForWrangler (including one of my own that we want to start landing in Rawhide ASAP) 19:29:43 * mitr queues after sgallagh for the open floor 19:30:11 <limburgher> Next week maybe? 19:30:21 <notting> ... whenever rbergeron wants to throw them at us, IMO 19:30:33 * Viking-Ice got another minor one 19:30:50 <notting> or 'the fedora program manager', to be more precise 19:30:54 * mitr would prefer sooner rather than later 19:31:14 <sgallagh> Yes, same here. Especially for features that touch multiple packages 19:31:18 <nirik> yeah, sooner would be fine here too. 19:31:30 <nirik> perhaps see if we can get robin or someone to wrangle them for next week? 19:31:35 <nirik> oh, who wants to chair next week? ;) 19:31:38 <sgallagh> (To avoid ambiguity, I'm talking about the Kerberos CcacheMove feature, specifically) 19:31:51 <limburgher> sgallagh: I assumed as much. :) 19:32:17 <mitr> nirik: 2 more things for open floor, I think 19:32:48 <sgallagh> Ok, I'll talk to rbergeron about getting F18 Features on the queue for next week 19:32:49 <nirik> mitr: go ahead 19:33:06 <mitr> Update on #798 (Ctrl-Space taken over by ibus) 19:33:07 <OzBorne> salut je suis un utilisateur de base... 19:33:27 <sgallagh> OzBorne: FESCo meeting is running long. We should be done in a few more minutes. 19:33:37 <mitr> AFAICS ( https://fedorahosted.org/fesco/ticket/798#comment:17 ) ibus is supposed to run only in CJK locales, and I think that's a reasonable default. 19:34:10 <notting> mitr: CJKI, but sure. 19:34:13 <mitr> Assuming that is the intent, proposal: treat other cases (e.g. ibus running in en_US) as bugs, no FESCo decission necessary 19:34:30 <sgallagh> mitr: +1 19:34:35 <limburgher> mitr: +1 19:34:54 <nirik> sure, +1 19:35:40 <notting> seems reasonable. +1 19:35:58 <t8m> mitr, +1 19:36:12 <nirik> #agreed for ibus (ticket 798): treat other cases (e.g. ibus running in en_US) as bugs, no FESCo decission necessary 19:36:20 <mitr> Thanks 19:36:23 <nirik> mitr: thanks. Did you have another item? 19:36:25 <mitr> Viking-Ice had one more item 19:36:26 <Viking-Ice> just a minor procedural issue. It would be good if deprecation/orphan notice ( as in "if you plan to no longer maintain or know if your package is going to be obsoleted/dropped/removed etc" ) should be sent now ( or as early as possible ) so feature owners can be working on the bits that actually will be in the release. Sounds most logical to do this stuff at branched time as in the beginning of the next rawhide cycle 19:36:48 <mitr> Would it be easy enough to list all dependent packages (... recursively) in the notice? 19:37:12 <notting> Viking-Ice: that's generally done "whenever someone decides to give it up". we could encourage people, certainly. 19:37:39 <Viking-Ice> notting, that would help 19:39:12 <Viking-Ice> I spent time on migrating stuff for components that later got deprecated or remove 19:39:18 <Viking-Ice> s/remove/removed 19:39:30 <notting> Viking-Ice: ok, i'll go looking through the wiki to see where that's logical to add, and can add a note to the list re: f18 development 19:39:42 <nirik> cool. 19:39:45 <Viking-Ice> thanks 19:39:47 <nirik> any other open floor items? 19:40:16 * nirik will close out in a minute then. 19:40:49 <nirik> oh, chair next week? 19:40:49 <notting> did we get a chair? 19:40:50 <nirik> anyone? 19:41:08 <notting> i can do it 19:41:13 <nirik> #action notting to chair next week. 19:41:15 <nirik> thanks! 19:41:19 <nirik> Thanks for coming everyone. 19:41:22 <nirik> #endmeeting
signature.asc
Description: PGP signature
-- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
