1:42 p.m.
===================================
#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-...
.
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