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