FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.

» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora Development

LinkBack Thread Tools
Old 03-16-2010, 08:06 PM
Kevin Fenzi
Default Meeting Summary/Minutes for todays (2010-03-16) FESCo meeting

#fedora-meeting: FESCO (2010-03-16)

Meeting started by nirik at 19:00:01 UTC. The full logs are available at

Meeting summary
* init process (nirik, 19:00:17)

* #353 provenpackager request for walters (nirik, 19:02:24)
* AGREED: walters approved for provenpackager (nirik, 19:05:07)

* #352 Proposal: Fesco should have a procedure for removing members of
fesco (nirik, 19:05:30)
* AGREED: the proposal passes with an amendent for the chair/current
acting chair and with a standard impeachment rule that the cause
for the vote must be made explicit. (pjones, 19:15:59)

* #354 Desktop Spin size change should get a feature page (nirik,
* LINK: https://fedoraproject.org/wiki/Features/DesktopLiveImageTarget
(nirik, 19:19:57)
* LINK: https://fedoraproject.org/wiki/Features/DesktopLiveImageTarget
(Kevin_Kofler, 19:22:05)
* AGREED: This late feature is approved. Please finish up the page and
add it to the right categories/lists. (nirik, 19:23:47)

* #346 Drop LSB package (nirik, 19:24:17)
* AGREED: This proposal is rejected. (nirik, 19:27:48)
* AGREED: FESCo asks FPC investigate a guideline against direct
dependencies on redhat-lsb (nirik, 19:29:57)
* ACTION: notting will ask them to look into it. (nirik, 19:30:11)

* #347 tor is not compliant with Fedora guidelines (nirik, 19:30:20)
* AGREED: FESCo will ask tor maintainer to not use install_initd and
will see if FPC can codify scriptlet output issues. (nirik,
* ACTION: nirik will contact tor maintainer (nirik, 19:41:44)
* ACTION: ajax will talk to FPC about scriptlet output (nirik,

* #355 Let rel-eng untag embryo from F-13 because it breaks the chain
and upgrade path (nirik, 19:46:16)
* AGREED: FESCo will allow releg to untag this package for now,
revisit this next week if there are still issues. (nirik, 20:00:08)

* #348 Fedora Packaging Committee items for ratification (2010-02-24)
(nirik, 20:00:28)
* AGREED: Both guidelines changes are accepted. (nirik, 20:03:30)

* Fedora Engineering Services Tickets/Updates. (nirik, 20:03:46)

* #351 Create a policy for updates (nirik, 20:05:52)
(nirik, 20:06:42)
* AGREED: Section 1 of the proposal is approved. (nirik, 20:17:00)
(nirik, 20:25:16)
* AGREED: Section 2 is Approved. Implementation details will need to
be worked out for listing/noting important packages. (nirik,
* AGREED: Section 3 will not be entirely removed. (nirik, 20:32:18)
* AGREED: Section 3 + KevinK's Amendemnt B passes (nirik, 20:52:27)
* None of this will take effect until implementation is made and
announced and ready. (nirik, 20:53:28)

* Open Floor (nirik, 20:59:07)
* FESCo members will be voiced starting next meeting to help avoid
confusion. (nirik, 21:01:29)

Meeting ended at 21:04:45 UTC.
19:00:01 <nirik> #startmeeting FESCO (2010-03-16)
19:00:02 <zodbot> Meeting started Tue Mar 16 19:00:01 2010 UTC. The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:03 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:05 <nirik> #meetingname fesco
19:00:06 <zodbot> The meeting name has been set to 'fesco'
19:00:11 <nirik> #chair dgilmore notting nirik skvidal Kevin_Kofler ajax pjones cwickert mjg59
19:00:12 <zodbot> Current chairs: Kevin_Kofler ajax cwickert dgilmore mjg59 nirik notting pjones skvidal
19:00:17 <nirik> #topic init process
19:00:23 <pjones> I suppose I'm here.
19:00:25 * skvidal is here
19:00:25 * cwickert is here
19:00:33 <mjg59> Here
19:00:40 <ajax> a friend in need is a friend indeed
19:01:05 * notting is here. behind on some stuff, but here.
19:01:15 <Kevin_Kofler> Present.
19:01:31 <nirik> dgilmore: you around?
19:01:41 <skvidal> I just pinged him on jabber
19:01:46 <nirik> skvidal: thanks.
19:01:58 <dgilmore> nirik: i am
19:02:11 <nirik> ok, I would like to leave the updates policy for last, so hopefully we can get the rest of these agenda items taken care of...
19:02:24 <nirik> #topic #353 provenpackager request for walters
19:02:30 <nirik> .fesco 353
19:02:31 <zodbot> nirik: #353 (provenpackager request for walters) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/353
19:02:52 <pjones> I think we should give it to him. Seriously.
19:03:01 <mjg59> I can't see any reason why not
19:03:18 <Kevin_Kofler> I'm a bit worried about his plans to touch packages he doesn't own to add things which aren't in the guidelines.
19:03:29 <cwickert> +1
19:03:38 <Kevin_Kofler> And it was the only reason given for the request.
19:03:39 <dgilmore> im +1
19:03:47 <nirik> I'm +1 on it... I think it will help fedora to have him able to work on other items. I agree he shouldn't add things that are outside the guidelines.
19:03:51 <Kevin_Kofler> So I'm afraid I have to vote -1 due to lack of a valid rationale.
19:03:52 <dgilmore> I think he will be responsible
19:03:55 <notting> i'm +1 just for the desktop co-maintenance aspect
19:04:00 <mjg59> +1
19:04:01 <skvidal> +1
19:04:17 <cwickert> I agree with Kevin_Kofler. It's not that I think he is a bad maintainer, but the rationale is poor
19:04:34 <skvidal> cwickert: so you're not +1?
19:04:36 <pjones> Kevin_Kofler: I still don't know why you think he's going to run all across every package or something. he's talking about changing a smallish group of packages as a (benign) experiment, AFAICS.
19:04:47 <cwickert> skvidal, I was +1 to what Kevin_Kofler said
19:04:49 <pjones> I'm also +1 purely for the desktop co-maintenance aspect.
19:04:50 <ajax> the guideline, if it existed, would be optional anyway.
19:04:57 <skvidal> cwickert: so not to the proposal
19:05:03 <cwickert> right skvidal
19:05:07 <nirik> #agreed walters approved for provenpackager
19:05:12 <skvidal> cwickert: sorry, that wasn't clear fro mthe flow
19:05:15 <ajax> (+1 to provenpackager, for the record)
19:05:30 <nirik> #topic #352 Proposal: Fesco should have a procedure for removing members of fesco
19:05:34 <nirik> .fesco 352
19:05:38 <zodbot> nirik: #352 (Proposal: Fesco should have a procedure for removing members of fesco.) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/352
19:05:43 <nirik> there was some discussion of this in the ticket.
19:05:52 <cwickert> skvidal, my bad
19:06:25 <pjones> I think this should get s/Chair/Chair or de facto chair/ injected into it at the obvious place.
19:06:28 <Kevin_Kofler> I still think this policy needs to be restricted to concrete wrongdoings, not just "voting off".
19:06:32 <pjones> otherwise I'm pretty much for it.
19:06:43 <pjones> Kevin_Kofler: afraid you've done some of them?
19:06:55 <Kevin_Kofler> No.
19:07:03 <ajax> pjones: "de facto chair"? who would that be?
19:07:09 <skvidal> ajax: if the chair is absent
19:07:11 <skvidal> repeatedly
19:07:13 <skvidal> for example
19:07:14 <pjones> ajax: whoever is acting as chair if chair is missing.
19:07:17 <skvidal> and we have some sitting in
19:07:17 <nirik> I admit it's vuage... I suppose the fact that it would take 8 to do it would cause it to not be done lightly?
19:07:19 <Kevin_Kofler> I just don't think it makes sense to allow "voting off" people without a specific concrete reason.
19:07:36 <skvidal> nirik: I think it makes it fairly difficult, yes
19:07:37 <pjones> Kevin_Kofler: it requires a specific reason - it just doesn't require that the policy enumerated them all.
19:07:38 <cwickert> I think "serious misconduct" is to vague.
19:07:38 <Kevin_Kofler> And we should clarify beforehand what those concrete reasons are.
19:08:00 <Kevin_Kofler> cwickert: Right, "serious misconduct" is not concrete.
19:08:00 <notting> i would agree, but i don't think attempting to list all the things that could possibly qualify as 'serious misconduct' is practical
19:08:00 <skvidal> cwickert: if we get specific then we end up writing ourselves into a corner
19:08:01 <nirik> well, it's hard to list all the possible things that could come up
19:08:02 <Kevin_Kofler> It's abstract. :-)
19:08:06 <dgilmore> im +1 for the proposal
19:08:16 * skvidal is +1 too
19:08:17 <mjg59> Any policy which tries to enumerate concrete reasons will either fail in an awkward corner case or will have people try to push any situation they want into one of those concrete cases
19:08:29 <cwickert> I think if we really go for something like "serious misconduct", skvidal would be in danger of being removed for some os his statements in the last meeting
19:08:39 <dgilmore> I think that there would be a good obvious reason for removing someone. the community would uproar if there was not
19:08:49 <notting> i would assume it would be like stewart definition of obscenity
19:08:51 <skvidal> cwickert: bring it
19:08:56 <pjones> cwickert: I don't think you could get us all to agree to that; therefore, you're incorrect.
19:09:01 <Kevin_Kofler> Without requiring a concrete reason, this undermines democracy.
19:09:16 <pjones> notting: I can't define it, but I know it when I piss on your mom?
19:09:17 <ajax> people. let's save the personal attacks for the octagon.
19:09:20 * drago01 notes that there is something called "common sense" ... you don't have to write _everything_ down
19:09:31 <cwickert> skvidal, see mschwend's mail on f-a-b list
19:09:33 <skvidal> cwickert: and I'd love to see what the serious misconduct is
19:09:35 <skvidal> cwickert: hahahaha
19:09:39 <pjones> yeah, I really think this is a fine policy.
19:09:41 <notting> pjones: classy.
19:09:41 <nirik> Kevin_Kofler: well, for example the us has 'high crimes and misdemenors'... but thats also subject to subjective issues.
19:10:15 <skvidal> this policy is simply following on the board's policy
19:10:22 <pjones> I think subjective vague criteria is fine here.
19:10:23 <Kevin_Kofler> dgilmore's downplaying of the current contributions of one of Fedora's most longstanding contributors could also qualify as "serious misconduct".
19:10:24 <dgilmore> without listing evry possible thing and then missing something you cant be overly speciifc in the policy
19:10:26 <skvidal> I find it amusing that we're having more complicated discussion of it than they have
19:10:26 <cwickert> skvidal, "orphan your packages and go. I'll be glad to clean up that mess" IMHO is serious misconduct
19:10:36 <Kevin_Kofler> We really need to define what exactly is serious enough to get one voted off.
19:10:36 <ajax> i would be for this proposal with pjones' amendment about de facto chair, and with a standard impeachment rule that the cause for the vote must be made explicit.
19:10:37 <pjones> so long as it's clear that there must be some concrete reason for the removal vote.
19:10:51 <dgilmore> i think it will be obvious when we need to remove someone
19:10:54 <pjones> ajax: exactamundo.
19:10:58 <skvidal> cwickert: then by all means - vote for the policy
19:10:59 <mjg59> cwickert: I think it's inappropriate, but not serious misconduct. So, in its proposed form, the proposal would not have resulted in Seth being removed
19:11:13 <skvidal> cwickert: and then argue for my removal.
19:11:19 <skvidal> cwickert: that's how it is supposed to work
19:11:25 <cwickert> skvidal, it was not my intention
19:11:25 <mjg59> Ok. How about we vote on the amendment?
19:11:33 <pjones> mine or ajax's or both?
19:11:43 <mjg59> ajax's subsumes yours
19:11:43 * notting is +1 to the proposal with ajax's amendments
19:11:46 <cwickert> my question is: who is to define "serious misconduct"?
19:11:46 <mjg59> So let's go with that first
19:11:51 <mjg59> nirik: ?
19:11:59 <skvidal> cwickert: WE ARE
19:12:01 * skvidal is +1
19:12:03 <nirik> I'm +1 to the proposal with ajax's amendments...
19:12:08 * pjones is +1 to ajax's
19:12:09 <mjg59> +1 from me
19:12:12 <cwickert> skvidal, simple majority?
19:12:19 <Kevin_Kofler> mjg59: That's why "serious misconduct" needs to be defined.
19:12:25 <mjg59> Kevin_Kofler: Nonsense.
19:12:27 <ajax> obviously i'm in favor of my own proposal.
19:12:34 <nirik> cwickert: no, it would be 8 of 9 of us agree the other was doing 'serious misconduct'
19:12:39 <pjones> cwickert: any one of us can come and say "hey, I think you're engaging in serious misconduct." then we discuss it as a group and decide if, by unanimous vote, we want rid of the plausible misconductor.
19:12:39 <skvidal> cwickert: did you even read the policy? the FESCO member in question may be removed by unanimous vote of the other members of FESCO
19:12:40 <mjg59> Kevin_Kofler: If it's not defined, it gets interpreted by the current committee
19:12:55 <Kevin_Kofler> I'm -1 to the policy with or without ajax's amendment.
19:13:09 <pjones> of course you are.
19:13:19 <cwickert> skvidal, this is the second step AFTER voting if something is "serious"
19:13:24 <skvidal> cwickert: no
19:13:36 * nirik tries to tally
19:13:41 <ajax> cwickert: yeah, i don't really think that's the case...
19:13:44 <pjones> cwickert: no, it's one step. "I think you're engaging in serious misconduct. "
19:13:44 <skvidal> nirik: I see 4 +1 and 1 -1
19:13:46 <mjg59> Kevin_Kofler: So, obviously, it would be possible for everyone to decide that the use of the word "KDE" was serious misconduct, and then vote someone off because of that. But then nobody would ever listen to that committee about anything again ever, the board would get involved and things would get fixed.
19:13:48 <Kevin_Kofler> pjones: Is this an implied accusation? :-/
19:13:54 <pjones> Kevin_Kofler: no.
19:14:01 <nirik> skvidal: did you get dgilmore's? I think it's 5 +1 and 1 -1
19:14:06 <mjg59> skvidal: I see 5 +1
19:14:11 <skvidal> nirik: I missed his
19:14:12 <skvidal> you're right
19:14:13 <skvidal> sorry
19:14:18 <pjones> Kevin_Kofler: I think you're generally against everything you didn't write, but that's not misconduct, it's just annoying.
19:14:29 <mjg59> Shall we move on?
19:14:30 <ajax> cwickert: i mean, it doesn't even matter. if a simple majority says something is "gross misconduct", and it goes to a vote, and it's still only simple majority, then it's no effect.
19:14:33 <nirik> can we drop the back and forth please?
19:14:38 <skvidal> in favor we have: nirik, skvidal, notting, pjones, mjg59, dgilmore
19:14:39 <cwickert> pjones, ok, but what if we all agree if this or that is serious but not if foo should be removed? this are two different decisions IMO
19:14:46 <ajax> skvidal: and myself.
19:14:49 <pjones> cwickert: only the last one matters.
19:14:53 <skvidal> ajax: of course, right
19:14:55 <skvidal> so it's in
19:15:00 <nirik> #agreed the proposal passes with an amendent for the chair/current acting chair.
19:15:00 <skvidal> nirik: I think we're done, right?
19:15:14 <pjones> nirik: you got that wrong
19:15:17 <nirik> skvidal: yes, except can someone write this up in the wiki and announce it?
19:15:23 <nirik> pjones: ok.
19:15:24 <Kevin_Kofler> pjones: I'm against everything that doesn't make sense.
19:15:25 <nirik> #undor
19:15:27 <nirik> #undo
19:15:27 <zodbot> Removing item from minutes: <MeetBot.items.Agreed object at 0x284fbd10>
19:15:30 <Kevin_Kofler> Whether I wrote it or not is irrelevant.
19:15:31 <ajax> cwickert: this is why i said the charge needs to be written.
19:15:33 <nirik> pjones: care to try?
19:15:33 <pjones> Kevin_Kofler: I know that to be false.
19:15:43 <mjg59> Hurrah for meetbot!
19:15:50 <skvidal> mmm, democracy successfully undermined
19:15:59 <pjones> #agreed the proposal passes with an amendent for the chair/current acting chair and with a standard impeachment rule that the cause for the vote must be made explicit.
19:16:04 <cwickert> ajax, just for the record what exactly was your amendment?
19:16:17 <nirik> pjones: thanks.
19:16:26 <ajax> cwickert: i might think that pjones needs to be removed because he called me fat. but if he's brought to vote for sabotaging other people's packages, when he didn't, i would be acting in bad faith if i voted to remove him anyway.
19:16:28 <nirik> who will write this up /announce it?
19:16:31 <pjones> cwickert: exactly as quoted just now
19:16:37 <pjones> ajax: fat.
19:16:55 <ajax> 15:10 <ajax> i would be for this proposal with pjones' amendment about de facto chair, and with a standard impeachment rule that the cause for the vote must be made explicit.
19:16:59 <ajax> cwickert: ^^^
19:17:07 <skvidal> nirik: I'll write it up
19:17:20 <skvidal> nirik: and post a draft to the wiki - where should it be put in?
19:17:30 <nirik> skvidal: thanks. Should go in the fesco policy wiki space and go to devel-announce I would guess? or should we announce it?
19:17:53 <pjones> I don't think there's any real need for an announcement.
19:18:01 <Kevin_Kofler> And why can such a policy be passed with only 6 +1 votes when those wouldn't be sufficient to carry the power of voting somebody off even under the policy itself.
19:18:01 <adamw> devel-announce doesn't seem right. it's nothing specific to development.
19:18:02 <notting> given that we have Board/SuccessionPlanning, i suspect it would go in FESCo/SuccessionPlanning, or similar
19:18:04 <nirik> yeah, perhaps not.
19:18:22 <nirik> ok, moving on.
19:18:22 <Kevin_Kofler> This is quite illogical.
19:18:27 <cwickert> ajax, thanks, IMO this is not enough, so just for the record I'd like to point out that I'm -1 to the current proposal
19:18:34 <cwickert> anyway, lets move
19:18:36 <nirik> #topic #354 Desktop Spin size change should get a feature page
19:18:42 <nirik> .fesco 354
19:18:43 <zodbot> nirik: #354 (Desktop Spin size change should get a feature page) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/354
19:19:14 <dgilmore> +1 we need to make it loud and clear that you must have a dvd for the live image
19:19:36 <pjones> why does it need a feature page? it needs to be announced, but that's handled in the second comment.
19:19:38 <mjg59> s/dvd/dvd or usb stick/
19:19:45 <mjg59> But yeah, this seems like something that's worth noting
19:19:48 <notting> i'm waffling on this. if it's prominent in the release notes, i'm not sure it needs a specific Feature page
19:19:57 <nirik> https://fedoraproject.org/wiki/Features/DesktopLiveImageTarget
19:19:57 <ajax> +1 to announcing it somehow, and not just because i hate the live installer.
19:20:03 <Kevin_Kofler> FWIW, AFAIK we're still targeting 700 MB for KDE (the Alpha overflowed due to bad kickstarts).
19:20:06 <pjones> it's already /in/ the release notes. we do not need a feature.
19:20:08 <dgilmore> pjones: because the feature pages is where the release notes come from
19:20:11 <Kevin_Kofler> So we can point the CD users to the KDE spin. :-)
19:20:17 <pjones> dgilmore: not the documentation beat?
19:20:19 <adamw> i definitely think it needs to be announced (I mailed a suggestion to that effect to the -desktop mailing list). it's catching quite a lot of users by surprise
19:20:21 <nirik> Kevin_Kofler: or lxde/xfce.
19:20:22 <drago01> or to the 1990s
19:20:23 <mjg59> pjones: I think "300MB more software" is a feature
19:20:26 <adamw> they tend to assume it's a bug and ask if they should report it
19:20:41 <ajax> well it'll get reported no matter what we do...
19:20:47 <nirik> a feature page will mean press will pick it up more.
19:20:55 <adamw> sure, but the existence of that behaviour rather indicates it needs an announcement
19:20:57 <Kevin_Kofler> (Actually, the reason for the KDE spin overflowing was bad timing of freeze overrides and stuff, not really the kickstart's fault.)
19:20:59 <nirik> there already is a release note.
19:21:15 <cwickert> +1 for a feature page, this needs to be in the release notes and in the wiki, so it is a feature
19:21:21 * nirik is a +1 I guess. It seems kinda a pain, but I think it will help.
19:21:30 * pjones is -1 because it seems redundant.
19:21:42 <mjg59> +1
19:21:51 <notting> before i vote +1, who are we telling to write the page?
19:22:00 <notting> that should probably be part of what we're deciding
19:22:01 <Kevin_Kofler> It's already written.
19:22:05 <Kevin_Kofler> https://fedoraproject.org/wiki/Features/DesktopLiveImageTarget
19:22:08 <nirik> notting: the desktop folks have a draft... see my link above
19:22:25 <notting> oh. so this is essentially ACKing an existing (late) feature page. ok, +1
19:22:36 <Kevin_Kofler> +1, the feature page is written and it's an important change which should be mentioned.
19:22:42 <pjones> if the problem is that people won't notice because they don't read the release notes, adding a feature page is only perpetuating the problem.
19:23:03 <Kevin_Kofler> "User Experience" is wrong.
19:23:09 <Kevin_Kofler> (copied from another feature page)
19:23:09 <nirik> pjones: sure, but its a nasty cycle...
19:23:13 <notting> pjones: that is a large problem to solve than just the context of this single feature. unless this is your line in the sand? this far, no farther?
19:23:28 <EvilBob> pjones: users don't read, does not mean that it should not be documented
19:23:40 <pjones> notting: my line of the sand with feature pages is well behind us, and I'm not going to be the one dragging us farther from it.
19:23:47 <nirik> #agreed This late feature is approved. Please finish up the page and add it to the right categories/lists.
19:23:48 <cwickert> we already have 5 +1s I think, have we?
19:23:52 * nirik nods
19:23:52 <adamw> EvilBob: pjones' line of thinking is that providing a Feature page to try and get the news to people who don't read release notes is a workaround not a proper fix
19:24:10 <adamw> EvilBob: where the 'proper fix' would be reprogramming users' brains with a large lump of wood with rusty nails in it until they *do* read release notes
19:24:17 <skvidal> adamw: and it is sorta like giving someone a pamphlet on illiteracy
19:24:17 <nirik> #topic #346 Drop LSB package
19:24:20 <EvilBob> adamw: +1
19:24:25 <nirik> .fesco 346
19:24:25 <zodbot> nirik: #346 (Drop LSB package) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/346
19:25:04 <notting> -1. it has a willing, if occasionally vacant packager. if we dropped everything i thought was crazy.....
19:25:04 <nirik> the list pointer in question is about the tor package (an upcoming topic)
19:25:05 <pjones> as much as I love the idea of dropping the lsb package, I think this is the wrong thing to do unless we've at least e.g. made a policy that says not to use lsb stuff for init scripts.
19:25:09 <Oxf13> competent packaging/reviews are hard, lets go shopping?
19:25:12 <pjones> (which I think we /should/ do.)
19:25:30 <pjones> we should certainly try to make as little as possible in the distro depend on it
19:25:33 <skvidal> dropping lsd is probably not a good idea
19:25:33 <notting> there's already a bug for making redhat-lsb more granular
19:25:40 <skvidal> oh, wait - you said lsB!
19:25:42 <Kevin_Kofler> pjones: BTW, #354 is something I voted for and I didn't write. :-)
19:25:42 <ajax> says you.
19:26:04 <pjones> Kevin_Kofler: a miracle!
19:26:07 <mjg59> I'm not enthusiastic about dropping a package just because someone misused it
19:26:22 <pjones> so obviously -1 on the title to this proposal. but what /should/ be done?
19:26:26 <ajax> i would rather see lsb split more granularly, and have a guideline that packages in fedora should not depend on the umbrella package.
19:26:36 <nirik> I am -1 on this at this time, but think we should ask packaging to see about adding a guideline to not use lsb... then retire it when nothing uses it.
19:26:41 <ajax> the umbrella package is for portability for ISVs.
19:26:44 <Kevin_Kofler> The rationale for dropping redhat-lsb is that we don't actually guarantee any level of actual LSB compliance.
19:26:47 <dgilmore> -1
19:26:47 <mjg59> Yeah, it makes sense for the lsb code to primarily be there for *non*-Fedora packages
19:26:53 <pjones> or would we rather discuss this with #347?
19:26:59 <Kevin_Kofler> And in fact some of the tools don't even work and don't get fixed, if Enrico is telling the truth.
19:27:12 <notting> Kevin_Kofler: nor do we guarantee POSIX compatibility, but we don't drop -D_USE_POSIX
19:27:15 <ajax> i think 347 is a separate issue...
19:27:16 <mjg59> Kevin_Kofler: We don't actually guarantee any level of actual POSIX compliance either
19:27:17 <cwickert> -1, dropping is not a solution. but what IS the solution here?
19:27:29 <skvidal> change the policy
19:27:30 <Kevin_Kofler> That said, I'm also -1 to dropping the package.
19:27:40 <notting> so, i think the proposal failed
19:27:41 <ajax> notting: what's the bug # for splitting lsb further?
19:27:41 <Kevin_Kofler> But the right solution is to explicitly ban packages from using it.
19:27:48 <nirik> #agreed This proposal is rejected.
19:27:48 <mjg59> The lsb package does need fixing, so if the maintainer isn't doing that then we should probably contact him directly
19:28:08 <nirik> perhaps we could ask for/get more lsb package maintainers?
19:28:09 <notting> proposal: have FPC investigate a guideline against direct dependencies on redhat-lsb?
19:28:19 <notting> ajax: 47263{0,3}
19:28:22 <mjg59> notting: I'd be +1 on that
19:28:23 <nirik> +1 to nottings proposal.
19:28:32 <ajax> +1 @notting
19:28:32 <notting> also 245494
19:28:36 <cwickert> notting, +1, good starting point
19:28:39 <skvidal> +1
19:28:40 <Kevin_Kofler> The tor package's abuse of redhat-lsb probably also violates the initscripts guidelines, but we'd also want to avoid any other redhat-lsb deps in Fedora packages.
19:28:50 <pjones> +1 to notting
19:28:53 <Kevin_Kofler> +1 to the above proposal from notting.
19:28:57 <pjones> Kevin_Kofler: that's the next topic
19:29:03 <pjones> (maybe next, certainly later)
19:29:10 * notting is +1 to his own proposal
19:29:18 <dgilmore> +1
19:29:24 <nirik> who will take this to packaging?
19:29:48 <notting> i can
19:29:57 <nirik> #agreed FESCo asks FPC investigate a guideline against direct dependencies on redhat-lsb
19:30:11 <nirik> #action notting will ask them to look into it.
19:30:20 <nirik> #topic #347 tor is not compliant with Fedora guidelines
19:30:25 <nirik> .fesco 347
19:30:27 <zodbot> nirik: #347 (tor is not compliant with Fedora guidelines) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/347
19:30:49 <nirik> I am still confused about which guideline it's not meeting... non 0 return from post?
19:30:59 <nirik> .fesco 347
19:31:00 <zodbot> nirik: #347 (tor is not compliant with Fedora guidelines) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/347
19:31:06 <Kevin_Kofler> I see at least 2 guideline compliance issues:
19:31:08 * nirik fails a up arrow.
19:31:13 <ajax> nirik: i think the consensus was that we really wished "output from %post" was a guideline, but that it's not.
19:31:14 <Kevin_Kofler> 1. noisy scriptlet output and
19:31:28 <pjones> ajax: yeah, looks that way to me.
19:31:29 <Kevin_Kofler> 2. non-usage of standard initscripts scriptlet snippets.
19:31:32 <nirik> Kevin_Kofler: there is no guideline against scriptlet output. ;(
19:31:51 <Oxf13> there is just cranky releng / qa folks when that happens
19:31:57 <Kevin_Kofler> I think the usage of subpackages for the initscripts is also outright bizarre.
19:32:10 <Oxf13> although I think we'd prefer that failures did get logged somewhere, but perhaps not all over the screen
19:32:11 <pjones> I think I'm more concerned that it's using the lsb initscripts stuff than that it's using "nonstandard" scriptlets.
19:32:14 * dgilmore does not see what it is volating
19:32:16 <Oxf13> or lost behind packagekit
19:32:21 <dgilmore> though it could probably be cleaner
19:32:23 <Kevin_Kofler> He should use the one style of initscripts we support (as written in the guidelines) and put those in the main package, using the standard snippets.
19:32:50 <Kevin_Kofler> Oxf13: This isn't actually a failure, at least not one that matters to the actual user.
19:33:02 <notting> scripts, for reference: http://fpaste.org/8mIc/
19:33:11 <Oxf13> Kevin_Kofler: I'm talking in general, not specific to Tor
19:33:13 <Kevin_Kofler> And it wouldn't happen if his initscripts-related snippets were compliant with the initscripts guidelines.
19:33:14 <nirik> for the record I dispise the tor and clamav packaging. I find it overcomplex, confusing for users, difficult for other maintainers, and for no gain for 99.99% of fedora users.
19:33:23 <skvidal> nirik: +1
19:33:28 <nirik> that said, I don't think it's violating any guidelines. ;(
19:33:34 <Oxf13> Kevin_Kofler: I do twitch a little when I see 2>&1 > /dev/null stuff in scriptlets
19:33:51 <dgilmore> nirik: i generally dont like the fedora-usermanagement stuff
19:33:52 <Kevin_Kofler> nirik: IMHO it violates both the letter and the spirit of the guidelines for initscripts.
19:34:04 <dgilmore> ebut im not about to ask that it be removed
19:34:08 <Kevin_Kofler> But all the other Enrico-isms are also weird.
19:34:13 <ajax> okay, so, i count two issues
19:34:13 <Kevin_Kofler> Subpackage abuse in particular.
19:34:31 <ajax> 1) not using standard initscripts practice: http://fedoraproject.org/wiki/Packaging/SysVInitScript
19:34:57 <ajax> 2) chatty scriptlets are lame
19:35:19 <ajax> 2 is pretty clearly just something someone needs to write down.
19:35:33 <ajax> you can't rely on scriptlet output ever being seen
19:35:44 <nirik> ajax: except new yum does save it.
19:35:49 <notting> we only ban interactive scriptlets?
19:35:49 <pjones> so I propose that we ask FPC to codify #2, and in the mean time ask enrico to fix #1
19:35:59 <pjones> notting: right, not noisy ones.
19:36:12 <dgilmore> pjones: thats reasonable
19:36:48 <ajax> pjones: he will almost certainly refuse to fix #1 until #522053 is fixed
19:37:04 <ajax> which is fair, i suppose
19:37:13 <nirik> .bug 522053
19:37:15 <zodbot> nirik: Bug 522053 install_initd fails on Required-Start - https://bugzilla.redhat.com/show_bug.cgi?id=522053
19:37:17 <pjones> ajax: my thought was more that he shouldn't be using install_initd ...
19:37:27 <Kevin_Kofler> Indeed.
19:37:43 <Kevin_Kofler> install_initd has no business being used by any Fedora package.
19:37:53 <Kevin_Kofler> The initscript guidelines clearly write down what to use.
19:37:56 <pjones> install_initd, while broken, seems like something exclusively reserved for non-fedora packages.
19:38:04 <ajax> does he have other packages where he does this?
19:38:04 <cwickert> exactly
19:38:04 <nirik> ok, shall we vote on pjones proposal?
19:38:09 <mjg59> +1
19:38:12 <pjones> +1
19:38:13 <cwickert> ajax, I hope not
19:38:14 <nirik> +1 here
19:38:17 <ajax> +1 @pjones
19:38:20 <cwickert> +1 to pjones
19:38:24 <Oxf13> before it's lost, I think what pjones just said should be added tothe initscripts guideline
19:38:25 <skvidal> +1
19:38:30 <Oxf13> (not using install_initrd within Fedora)
19:38:31 <Kevin_Kofler> +1 to pjones's proposal.
19:38:37 <nirik> ajax: I don't think clamav does, because clamd only ships a sample script you must modify for your specific use case.
19:38:40 <ajax> cwickert: i have to imagine he does it this way because he thinks there's some good reason to
19:38:53 <pjones> Oxf13: that should be an FPC dictum, I suspect.
19:38:57 <dgilmore> +1 to pjones
19:39:01 <pjones> (so let's ask them to ban it
19:39:18 <Oxf13> pjones: just what I meant.
19:39:24 * notting closes 522053
19:39:25 <nirik> #agreed FESCo will ask tor maintainer to not use install_initd and will see if FPC can codify scriptlet output issues.
19:39:29 <Kevin_Kofler> pjones: It's a bit redundant with banning redhat-lsb usage entirely as we've just asked FPC to.
19:39:36 <Oxf13> ajax: he uses Fedora packages, but not really Fedora. He hacks the crap out of it for his own personal OS
19:39:43 * nirik wonders if he summed up correctly what people voted for?
19:39:43 <pjones> Kevin_Kofler: I'm all for one action that bans both
19:39:46 <Kevin_Kofler> (see the previous meeting point)
19:39:51 <pjones> nirik: seems about right
19:40:07 <Oxf13> Kevin_Kofler: that's probably my fault, I didn't realize install_initrd was an lsb function
19:40:11 <nirik> ok, who will talk to tor maintainer, and who will talk to FPC?
19:40:21 <dgilmore> install_initd sounds like it should be a wrapper for chkconfig
19:40:24 * nirik tries to make sure this stuff gets followed up on.
19:40:32 <skvidal> nirik: speaking of following up https://fedoraproject.org/wiki/FESCo/SuccessionPlanning
19:40:54 <nirik> I can update the bug for the tor maintainer if no one else wants to.
19:41:08 <nirik> skvidal: excellent.
19:41:11 <notting> dgilmore: it's a symlink.
19:41:44 <nirik> #action nirik will contact tor maintainer
19:41:56 <nirik> who wants to talk to FPC about scriptlet output?
19:42:08 <dgilmore> notting: we should ask fpc to give us a guideline then that says use chkconfig only and not install_initd just for clarity
19:42:12 <pjones> dgilmore: it actually parses lsb-only crap in the initscript and does shit based on it
19:42:34 <pjones> dgilmore: lsb basically re-implements sysv init scripts + chkconfig in its own wildly sillier way.
19:42:53 <nirik> and our current guidelines say they are not required, but can be used.
19:43:12 <pjones> right. but we should be clear that that's about the stuff in the initscript, not the use of the associated shitty stupid tools.
19:43:13 <dgilmore> pjones: eww
19:43:17 <Kevin_Kofler> Yet our review guidelines say we should verify compliance of initscripts with the initscripts guidelines.
19:43:23 <Kevin_Kofler> (if I'm not mistaken)
19:43:54 * nirik notes we are coming up on 15min on this topic.
19:43:59 <ajax> compliance with the guidelines does not mean implementing all optional features.
19:44:03 <notting> dgilmore: note that chkconfig invoked as install_initd does change the behavior slightly
19:44:15 <Oxf13> question from the peanut gallery, how much of this "goes away" if/when we move to full upstart init style?
19:44:16 <notting> and i think that's enrico's bug. install_initd is actually enforcing the standard.
19:44:33 <notting> Oxf13: oh, i suspect we'll get an entirely different set of issues then.
19:44:40 <nirik> "LSB Headers are not required for Fedora SysV-style initscripts, but they may be used. There is no requirement in the LSB certification for any system scripts to be LSB compliant, and it can cause issues with ordering."
19:45:36 <nirik> no takers on talking to FPC about scriptlet output?
19:45:40 <ajax> i really don't want to have to cite rfc2119 in the guidelines, but, here we are.
19:45:44 <ajax> nirik: i'll do that.
19:45:51 <nirik> hurray.
19:46:02 <nirik> #action ajax will talk to FPC about scriptlet output
19:46:16 <nirik> #topic #355 Let rel-eng untag embryo from F-13 because it breaks the chain and upgrade path
19:46:21 <nirik> .fesco 355
19:46:23 <zodbot> nirik: #355 (Let rel-eng untag embryo from F-13 because it breaks the chain and upgrade path) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/355
19:46:27 <nirik> cwickert: just updated this
19:46:49 <nirik> so, I am happy with waiting a week to give them a chance to fix it.
19:46:54 <pjones> I think we should probably untag this, since people may have it installed but they certainly can't be /using/ it.
19:47:10 <Oxf13> yeah, it's extremely unlikely they would have installed it
19:47:12 <mjg59> pjones: But if they've managed to get it installed, updates will then be broken?
19:47:13 <Oxf13> let alone use it
19:47:18 <Kevin_Kofler> Untagging without an Epoch bump means making the version go backwards.
19:47:29 <nirik> please read the last comment in the ticket.
19:47:35 <Kevin_Kofler> So it has been suggested that they should just bump Epoch.
19:47:40 <Oxf13> Kevin_Kofler: which is only really a problem if it's actually been on somebody's system.
19:47:47 <cwickert> IMO this really is a social problem
19:47:48 <Kevin_Kofler> But maybe upgrading the whole stack instead would be the better solution.
19:47:51 <thomasj_> Nobody will have it installed. It's only used for Enlightenment.
19:47:54 <cwickert> cassmodiah, can you comment on this?
19:47:59 <Kevin_Kofler> It's already done in Rawhide, it just needs to go into F13.
19:48:16 <mjg59> Oh, fine
19:48:19 <mjg59> Just leave it for a week
19:48:22 <notting> Kevin_Kofler: ok then. go forth and do, etc.
19:48:31 <ajax> +1 to defer for a week
19:48:41 <Kevin_Kofler> Well, actually it's not complete in Rawhide yet.
19:48:44 <notting> +1 to defer
19:48:49 <dgilmore> -1 to untagging the build
19:48:51 <pjones> Kevin_Kofler: no, putting in a new package reusing the old VR makes the version go backwards. either way, I'm +1 to defer.
19:48:54 <cassmodiah> i think 1 week isn't enough. I'm currently not briefed
19:48:57 <cwickert> +1, give them a week to fix ot. not a fesco thing IMO
19:49:03 <nirik> +1 to waiting and revisiting
19:49:06 <Oxf13> thomasj_: do not underestimate the ability for our users to do silly things we never expect them to do (:
19:49:07 <cwickert> cassmodiah, che will help you
19:49:18 <pjones> mjg59: updates wouldn't be broken so long as the next version is still newer than the broken one (i.e. release=2 or whatnot.)
19:49:34 <Kevin_Kofler> I'm a bit worried about the schedule for doing an update of the whole E17 stack for Rawhide now.
19:49:39 <skvidal> +1
19:49:42 <cassmodiah> cwickert i hope that this help isn't too late! :-/
19:49:43 <thomasj_> cwickert, by the way, thanks for the social comment. I will bring it up again later in a different discussion.
19:49:55 <thomasj_> Oxf13, you're right
19:49:59 <cwickert> thomasj_, welcome
19:50:13 <dgilmore> We have in the past refused requests like this
19:50:23 <Kevin_Kofler> pjones: The point is, it will not be! The proposal is to revert to an old build without an Epoch bump.
19:50:25 <Oxf13> dgilmore: we have when it was already on people's systems
19:50:35 <dgilmore> I think we need to be consistent and have them fix the issue in the packaging
19:50:44 <Oxf13> the way I see it, currently nobody can install/test E stuff
19:50:52 <pjones> Kevin_Kofler: right, but that doesn't matter as long as there's another update /after that/ that fixes the problem and has a newer VR than the broken one.
19:50:52 <thomasj_> yep
19:50:56 <Oxf13> so we could gain back a week of some limited testing by untagging
19:50:57 <dgilmore> Oxf13: there is no reason that they cant just build a new nvr
19:51:12 <dgilmore> the latest tagged package will win
19:51:12 <thomasj_> Oxf13, and if the new packages go into F-13 it is untested.
19:51:13 <pjones> Kevin_Kofler: the people with a broken version already will remain affected, it's true, until there's a Real Fix.
19:51:15 <Oxf13> then when everything is ready to go to the newer stuff, we can re-tag, or get a new build.
19:51:16 <cwickert> Oxf13, the old stuff was tested and used for two years now
19:51:32 <pjones> Oxf13: yeah, that's what I'm seeing
19:51:38 <Kevin_Kofler> dgilmore: That's also against the same "the branch should not go backwards" rule though.
19:51:40 <Oxf13> cwickert: which doesn't mean it will work with the rest of F13
19:51:46 <cwickert> true
19:52:00 <Oxf13> so the real question here, to me, is how important is that week~ of testing?
19:52:03 <Kevin_Kofler> And it has no real advantage over just untagging the newer unwanted build.
19:52:06 * thomasj_ want's the old stuff in F-13 for now, that's why i asked rel-eng to untag it.
19:52:10 <Oxf13> are the E folks OK with it being impossible to install for a while?
19:52:26 * thomasj_ thinks it's better to have the new stuff tested first
19:52:38 <nirik> an addition week of testing the already known stable one doesn't seem to usefull.
19:52:38 <cwickert> Oxf13, I guess, it's already broken for weeks and nobody complained
19:52:54 <nirik> but it does mean that new users can't install it for now.
19:53:01 <Kevin_Kofler> thomasj_: If you want the old stuff in F-13, then bump Epoch.
19:53:15 <Oxf13> Kevin_Kofler: that's completely unnecessary
19:53:18 <nirik> (and in rawhide as well to preserve upgrade path)
19:53:23 <cwickert> I think this can be fixed within one or two days, if all people work together
19:53:25 <thomasj_> Kevin_Kofler, i can do that as well. cwickert told me to ask rel-eng
19:53:28 <Kevin_Kofler> nirik: Right.
19:53:49 <thomasj_> Kevin_Kofler, and rel-eng said they need the ok from FESCo there.
19:53:53 <nirik> so, we have enough votes to defer and revisit, shall we just do that and move on?
19:53:56 <Oxf13> how about we actually look past the words of a rule, and try to understand the /reason/ for the rule
19:54:00 <cassmodiah> cwickert +1 this can be fixed soon, if there is any teamwork
19:54:08 <Kevin_Kofler> Oxf13: Isn't the current policy that Rawhide should never go backwards, let alone branched releases?
19:54:16 <Kevin_Kofler> I don't care all that much about that policy.
19:54:26 <Kevin_Kofler> But if we don't want to enforce it, why do we have such a policy at all?
19:54:41 <Oxf13> Kevin_Kofler: such a policy exists yes, to protect users from being left out in the cold if the package they have installed goes backwards
19:54:48 <Kevin_Kofler> (FWIW, I think Rawhide or unreleased releases going backwards is not a big problem.)
19:54:50 <Oxf13> in this case, it is extremely unlikely anybody actually has this package installed
19:55:00 * nirik does.
19:55:00 <Oxf13> /and/ there would be a newer n-v-r coming soon, after testing
19:55:29 <cwickert> Oxf13, they *cannot* install the package because it's broken/the broken deps prefent people from installing it
19:55:33 <Oxf13> untagging may break the words of the rule, but certainly not the spirit or reason for the rule.
19:55:39 <notting> if it's going to be fixed soon, just fix it
19:55:40 <Oxf13> cwickert: that's... not true
19:55:47 <nirik> cwickert: not true. You can install it by itself. You can't install it with any of the rest of the stack
19:55:49 * cwickert looks...
19:55:53 <abadger1999> cwickert: .... they could have installed embryo without the other deps.
19:56:00 <mjg59> Do we need to discuss this any further?
19:56:01 <thomasj_> yep
19:56:06 <thomasj_> oh, yep to abadger1999
19:56:23 <dgilmore> mjg59: nope we need to say that it cant be untag and needs fixed within the packaging
19:56:23 <nirik> I guess we have votes to defer and revisit...
19:56:24 <cwickert> I doubt that anybody has installed it embryo, it's not in comps, it's a lib
19:56:40 <thomasj_> Yep
19:56:45 <Oxf13> cwickert: right, which is why I said it's highly unlikely, but not impossible.
19:56:54 <cwickert> ok then Oxf13
19:57:05 <nirik> I have it installed... because I was curious about it... others might have installed it due to our dicussions?
19:57:14 <Kevin_Kofler> Well, the lead Release Engineer says we should just untag this.
19:57:25 <mjg59> But we've also decided that we can leave it for a week
19:57:31 <Kevin_Kofler> So IMHO we should do as he said.
19:57:42 <Oxf13> untagging would actually be better than leaving it for a week and waiting for a fix
19:57:50 <Kevin_Kofler> His arguments make sense.
19:57:51 <pjones> yeah, I'm with Oxf13 here
19:57:51 <Oxf13> untagging would allow people who want to install E to actually be able to
19:58:00 <mjg59> Oxf13: Ok, fine, utterly happy to defer to you on this
19:58:17 <pjones> right. people with it already installed will have a broken one, but everybody else avoids damage. untagging is best.
19:58:17 <Oxf13> the time to fixed package doesn't really change here.
19:58:25 <cwickert> +1 for untagging, but rel-eng closed the untag request WONTFIX
19:58:34 * notting defers to Oxf13, then. +1 to untag
19:58:39 <mjg59> +1 for untagging
19:58:42 <dgilmore> anytime something like this has come up we have consistently said if it has been pushed to rawhide(i.e. any repo really) it can not be untagged and needs to be fixed via a epoch if it must go backwards
19:58:45 <Kevin_Kofler> +1 to untagging (and we can reopen the rel-eng request)
19:58:47 * nirik shrugs. I don't much care except that we might get more people with diffrerent issues asking us to untag things.
19:58:49 <pjones> +1 for untagging since I've said that like 50 times now.
19:58:58 <notting> cwickert: rel-eng was not going to break policy to untag w/o fesco approval, as i understand it
19:59:06 <dgilmore> there is a reason we ahve always said no to untagging
19:59:07 * skvidal is with nirik - having hard time caring
19:59:09 <Oxf13> dgilmore: the reason behind that is to protect people who have potentially installed it.
19:59:10 <cwickert> notting, i see
19:59:12 <ajax> 0, don't care, just make it go away.
19:59:17 <Oxf13> dgilmore: please please read past the bare words of the rule.
19:59:20 <skvidal> ajax: I like this answer
19:59:23 <dgilmore> Oxf13: right and people may have in this case also
19:59:26 <mjg59> I think we're done
19:59:32 * nirik tallys
19:59:37 <pjones> dgilmore: right, but not untagging it doesn't protect them any in this case
19:59:37 <dgilmore> Oxf13: at least nirik has it installed
19:59:46 <mjg59> Especially as we'll be at 15 minutes in 2 minutes
19:59:50 <cwickert> untag and revisit next week (if still necessary)
19:59:57 <cwickert> period
20:00:08 <nirik> #agreed FESCo will allow releg to untag this package for now, revisit this next week if there are still issues.
20:00:14 <mjg59> Full stop carriage return carriage return THE END
20:00:18 * dgilmore is going to leave the meeting now
20:00:19 <mjg59> Ok
20:00:28 <thomasj_> Thank you.
20:00:28 <nirik> #topic #348 Fedora Packaging Committee items for ratification (2010-02-24)
20:00:38 * nirik sighs
20:00:40 <Oxf13> untagged.
20:00:46 <mjg59> Does anyone have any arguments against these proposals?
20:00:54 <nirik> .fesco 348
20:00:54 <ajax> nope.
20:00:55 <zodbot> nirik: #348 (Fedora Packaging Committee items for ratification (2010-02-24)) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/348
20:00:58 <pjones> I vote we rubber stamp these with great force.
20:01:08 * skvidal waits for it
20:01:19 <ajax> i say your three cent titanium tax doesn't go too far enough.
20:01:29 <ajax> +1
20:01:30 <nirik> should we do them one at a time?
20:01:31 <cwickert> +1 to all of them
20:01:44 <mjg59> nirik: Unless anyone has any arguments against, no real point
20:01:49 <nirik> true.
20:01:49 * notting is +1 to both
20:01:51 <nirik> +1 to both
20:01:52 <mjg59> Both seem sane, so I'm +1 to both
20:02:00 <Kevin_Kofler> Wait a minuteā€¦
20:02:00 <pjones> looks like 5.
20:02:01 <skvidal> +1 to both
20:02:06 <Kevin_Kofler> About the "Add a Dummy Macro" part.
20:02:16 <Kevin_Kofler> Can we not just mass-change all the packages instead?
20:02:30 <mjg59> Kevin_Kofler: My recollection is that one of the font maintainers was unhappy about doing so
20:02:46 <Kevin_Kofler> That's what we have provenpackagers for.
20:02:56 <nirik> Kevin_Kofler: there are also still font packages that don't use the current guidelines.
20:02:56 <Kevin_Kofler> But I'm +1 to both guideline changes.
20:02:58 <mjg59> And while we could mandate that, the packaging committee have found a mechanism that doesn't require it
20:03:20 <mjg59> So, while it's not ideal, it's also not obviously damaging
20:03:20 <pjones> yeah, I think the reason for the dummy macro is really that we expect packages to lag behind the guidelines, if only slightly.
20:03:28 <ajax> i would certainly prefer that all the font packages be updated, but i'm not going to insist on it this week.
20:03:30 <nirik> #agreed Both guidelines changes are accepted.
20:03:36 <skvidal> next!
20:03:46 <nirik> #topic Fedora Engineering Services Tickets/Updates.
20:03:56 <nirik> I don't have much to report here, so I am not going to go over them all.
20:04:04 <nirik> There is steady progress on most of the larger ones.
20:04:11 <nirik> mmcgrath: you have anything to note?
20:04:33 <mmcgrath> Nothing major, incremental progress from last week. I got a few broken deps fixed
20:04:47 <mmcgrath> For the most part though it seems most of the broken deps are actually known by the packagers.
20:05:05 <nirik> cool.
20:05:08 <mmcgrath> It's just the fix sometimes requries work from upstream.
20:05:12 <mmcgrath> so generally things are good.
20:05:29 <nirik> if anyone would like to join in and help things, follow the wiki page...
20:05:37 <nirik> if anyone has additional tickets to work on, file away.
20:05:41 <nirik> thanks mmcgrath
20:05:47 <nirik> and now the fun part.
20:05:52 <nirik> #topic #351 Create a policy for updates
20:05:56 <nirik> .fesco 351
20:05:57 <zodbot> nirik: #351 (Create a policy for updates) - FESCo - Trac - https://fedorahosted.org/fesco/ticket/351
20:06:10 <nirik> notting made a number of changes last week.
20:06:27 <notting> yeah, i made some changes after talking with QA
20:06:30 <nirik> Kevin_Kofler has some amendments to discuss.
20:06:42 <nirik> https://fedoraproject.org/wiki/UpdatePolicy(draft)#notting.27s_Proposal
20:06:48 <notting> if it makes things simpler, we can vote on each of the three segments separately
20:06:51 <nirik> can everyone take a minute to just re-read the proposal?
20:06:54 <notting> they stack on top of each other, more or less
20:07:30 <adamw> quick note: QA is still working on a policy to document the whole process of how updates are actually managed
20:07:33 <Kevin_Kofler> FWIW, I'm also still -1 to the proposal as a whole, even amended, as I don't see a need for such a policy at all.
20:07:41 <wwoods> ...
20:08:10 <Kevin_Kofler> But if the policy is taken as a given, then let's at least get my amendments to a vote (and hopefully approve them).
20:08:12 <pjones> Kevin_Kofler: can we just take that as a given from here on out?
20:08:21 <adamw> since last week's meeting didn't show much enthusiasm for merging it with notting's policy on update requirements during the draft phase, and notting said he'd prefer to work on his update requirements document just as it is for now, i'm trying to nudge the broader QA proposal in the direction of being a 'shell' into which notting's update requirements document would plug
20:08:49 <pjones> adamw: sounds backwards.
20:08:50 <adamw> so fesco could approve notting's requirements policy and then consider the broader process policy whenever we're done drafting it, and the agreed requirements policy would not need to change
20:09:39 <adamw> pjones: how do you mean?
20:09:58 <jlaska> pjones: notting's proposal focuses on package acceptance criteria, which is what QA is hoping to get consensus on so we can refine https://fedoraproject.org/wiki/User:Kparal/Proposal:Package_update_acceptance_test_plan
20:10:26 <pjones> jlaska: yes, but wedging something else around it later sounds unlikely to produce fruitful results
20:11:04 <nirik> so, how should we move forward here? shall we discuss Kevin_Kofler's amendments first? or decide we want more QA buyin of nottings proposal in general before voting?
20:11:09 <adamw> pjones: i don't think it's particularly tricky, we just yank the stuff about specific requirements out of the draft we had last week, and instead link into notting's policy when saying what the actual requirements to move from step to step are
20:11:49 <nirik> adamw: so, nottings proposal would be a subset of the overall updates qa flow?
20:11:53 <notting> nirik: i'd like to offer up section 1 for a vote first. i would think it's the least controversial, and Kevin didn't have an amendment to it
20:12:01 <nirik> ok.
20:12:22 <nirik> I have a question. Point 4.... is that taking into account multilib?
20:12:36 <adamw> nirik: right. and if we never manage to agree on a policy to cover the whole process, notting's policy on requirements can still stand alone. so i think the approach is fairly safe.
20:12:39 <notting> nirik: sure.
20:12:48 <Oxf13> fwiw, from a releng pov, section 1 is very good
20:12:59 <nirik> so, packages with broken multilib would fail and be unable to push as updates?
20:13:04 <notting> nirik: the overriding theme of those requirements is DON'T BREAK THE REPO
20:13:07 <Oxf13> in fact, it's the type of thing I plan to put as a barrier of entry to /any/ published Fedora package collection
20:13:15 <Oxf13> eg rawhide, branched, etc...
20:13:28 <nirik> in any case thats nitpicking. I'm +1 for section 1.
20:13:32 <pjones> adamw: I don't think you're necessarily wrong. I do think we shouldn't discuss this until after we've /got/ a policy ratified.
20:13:48 <Kevin_Kofler> +1 to section 1, that's something that sounds obvious even to me. :-)
20:14:10 <Kevin_Kofler> (and it's pretty much why AutoQA is being developed in the first place)
20:14:40 <nirik> ok, thats +1
20:14:44 <nirik> +2 rather
20:15:02 * notting is +1, obvs.
20:15:03 <mjg59> +1
20:15:04 <Kevin_Kofler> Though maybe "Packages must not break upgrade path" should be clarified to ensure that it's possible to queue the same update to multiple releases at the same time.
20:15:05 <abadger1999> Question on scope: Does this section (or the whole policy) cover updates only or updates + updates-testing?
20:15:06 <cwickert> +3 at least
20:15:09 <adamw> pjones: yeah, no, i agree, at this meeting, just discuss notting's proposal. i just wanted to make sure the fate of QA's proposal was on the record in case anyone wondered where it had disappeared to after last week =)
20:15:30 <nirik> abadger1999: see the bottom of that section.
20:16:04 <nirik> "As a discussion point, some subset of these tests could be run on pending updates, and the results used to block updates going to updates-testing as well."
20:16:09 <pjones> what, precisely, is being voted on?
20:16:21 <nirik> pjones: https://fedoraproject.org/wiki/UpdatePolicy(draft)#notting.27s_Proposal
20:16:21 <notting> pjones: section 1 of the proposal.
20:16:22 <abadger1999> ah... so pending updates are updates in updates-testing, not updates that are pending in bodhi...
20:16:23 <nirik> section 1
20:16:27 <pjones> +1 to section 1 then
20:16:42 <nirik> abadger1999: yeah, I guess thats confusing...
20:16:42 * skvidal +1's section one
20:17:00 <nirik> #agreed Section 1 of the proposal is approved.
20:17:08 <nirik> next section.
20:17:08 <ajax> +1 to section one (late)
20:17:14 <Oxf13> Kevin_Kofler: re multiple updates at the same time, lets leave that for implementation
20:17:24 <notting> ok, section 2. Kevin_Kofler has an amendment to this section.
20:17:29 <adamw> section 1 lists whether the tests should be applied to updates-testing as a 'discussion point'
20:17:32 <adamw> was that settled yet?
20:17:50 <mjg59> adamw: Given that we've already voted on it, can we please delay discussion until later?
20:18:01 <nirik> adamw: no. We could discuss adding that after?
20:18:21 <adamw> nirik: sure, so for now it's unsettled.
20:18:26 <nirik> adamw: yep.
20:18:33 <notting> i'm not in favor of Kevin_Kofler's amendment, as rather than "ensur[ing] the SIGs controlling the desktops can make autonomous decisions about when to push updates to their desktops without being reliant on external groups such as QA.", i'd prefer the SIGs work with and within QA
20:18:54 * skvidal is -1 to the amendment, too
20:19:14 <Kevin_Kofler> Can we at least seed the initial list with at least 1 member of each desktop's SIG until we have more of it?
20:19:16 <mjg59> Wait
20:19:17 <nirik> I would also be -1, but I would hope the criteria to be a proventester would allow anyone from those SIGs who already does testing to be able to have that status
20:19:17 <Oxf13> where is this amendment ?
20:19:24 <mjg59> Are we voting on the amendment, or the amended proposal?
20:19:26 <nirik> Oxf13: in the ticket.
20:19:33 <ajax> Oxf13: https://fedorahosted.org/fesco/ticket/351#comment:12
20:19:52 * nirik thought we were voting on the amendment. Should we vote on the proposal first?
20:19:56 <Kevin_Kofler> I'd nominate rdieter for KDE, he's done that "job" as a rel-eng member for pending releases so far and he did it well (even for non-KDE packages).
20:19:58 <mjg59> And, given the constraints Kevin imposed, are we looking at section two or section 3?
20:20:07 <skvidal> I think we are looking at
20:20:08 <skvidal> Amendment proposal C: In section 2, codify that the group of testers empowered to give the magic karma needs to include at least 1 member (or in the event the criteria get changed to require some karma n rather than 1, n members) of each SIG behind one of the desktops considered "critical" by section 2.
20:20:08 <skvidal> Rationale: This ensures the SIGs controlling the desktops can make autonomous decisions about when to push updates to their desktops without being reliant on external groups such as QA.
20:20:16 <mjg59> nirik: It's generally faster to just vote on the amended proposal
20:20:19 <adamw> for information, the current proposal for having people become 'proven testers' is http://lists.fedoraproject.org/pipermail/test/2010-February/088824.html . it's still heavily under discussion, though
20:20:22 <mjg59> nirik: That way you don't need to have a second vote if it passes
20:20:45 <Oxf13> fwiw, as an outsider, I'm also against that amendment.
20:20:50 * gholms|mbp rings the 15 minute bell
20:20:52 <Oxf13> to date, we do not have any criteria for the proventesters group
20:21:11 <nirik> yeah, 15min. Shall we continue? votes?
20:21:13 <nirik> +1 here
20:21:14 * cwickert would like to give this another 15 minutes
20:21:15 <pjones> adamw: please stop injecting confusion to this discussion. it is not helping.
20:21:16 <mjg59> Continue
20:21:16 * notting is +1 to continuing discussion
20:21:18 <Oxf13> therefor the amendment text would be better served on the proposal for the proventesters group composition
20:21:19 <skvidal> +1 to continuing
20:21:27 <pjones> I think we should continue. What's the url for kevin's amendment?
20:21:34 <Oxf13> leaving the updates policy to just reference the proventesters group
20:21:40 <nirik> pjones: https://fedorahosted.org/fesco/ticket/351#comment:12
20:21:49 <adamw> pjones: it was in response to nirik's question about the criteria to be a proven tester. i thought that in context it would be fairly helpful for nirik to see what the discussion about those criteria was.
20:21:52 <pjones> Oh, it's on the ticket. how interesting.
20:22:16 <nirik> I would hope that sigs/desktops/important app/critical path using people would be able to become proventesters.
20:22:29 <Oxf13> they should be
20:22:30 <adamw> nirik: at present i think that's very likely to be the case. oxf13 would you agree?
20:22:31 <nirik> especially those people who already do that kind of testing for their sig/app/desktop/etc
20:22:49 <nirik> ie, if KDE has some folks who do a lot of their testing, I would hope they would be able to get this status...
20:23:00 <Oxf13> proventesters would be in line with provenpackagers, no real restrictions on who can join, just a criteria to meet and peer approval
20:23:03 <nirik> so, no need to mandate it.
20:23:25 <nirik> Kevin_Kofler: would that meet your concerns?
20:23:49 <Kevin_Kofler> I guess it would.
20:23:56 <nirik> so, any other general comments on section 2?
20:24:03 <Oxf13> but again, any sort of verbiage about who makes up the 'defined group of testers' should go in the proposal and policy for proventesters, not in the update policy
20:24:12 <nirik> notting: we don't have a current list do we?
20:24:28 <notting> nirik: list of...?
20:24:41 <nirik> notting: 'important packages'
20:24:52 <Kevin_Kofler> Other than that I don't see the need for such added bureaucracy at all? :-) (But section 3 is the worst.)
20:25:03 <notting> there is the critical path list. we can, if people want, expand the definition of critical path as described
20:25:08 <nirik> Kevin_Kofler: we will get to 3 next.
20:25:13 <wwoods> Kevin_Kofler: think we agreed to take that objection as a given.
20:25:16 <nirik> http://kojipkgs.fedoraproject.org/mash/branched-20100316/logs/critpath.log
20:25:18 <notting> in which case, it's just a matter of tweaking the tools that create that llist
20:25:27 <abadger1999> Is there a rationale for having two separate lists (critpath and non-critpath important packages).
20:25:38 <nirik> notting: ok, but it currently doesn't have KDE/LXDE/XFCE in it.
20:25:45 <adamw> i thought the original reason we came up with critpath in the first place was to feed into a policy like this
20:25:46 <nirik> abadger1999: which is?
20:25:53 <Oxf13> for the sake of the proposal at this time, I think section 2 lists enough package names in addition to critpath
20:25:59 * nirik notes that still has the xfce4-notifyd thing in it.
20:26:12 <cwickert> nirik, this is a yum problem
20:26:14 <adamw> so it would seem a bit odd to have critpath exist and then be expanded when we actually use it. would we actually use the non-expanded critpath list for anything?
20:26:15 <notting> abadger1999: only that critpath is not currently defined for the other desktops, and i think this proposal should cover them
20:26:22 <wwoods> there's definitely rationale for having multiple layers above critpath; section 2 seems to be defining one of those layers
20:26:35 <abadger1999> notting: In that case, I'd rather see critpath expandedtoo voer them instead.
20:26:38 <Kevin_Kofler> That's also something kinda weird: Why would those be critical for updates, but not for new releases?
20:26:39 <wwoods> no.
20:26:49 <skvidal> cwickert: a yum problem?
20:26:50 <Oxf13> .... and we're getting lost in teh weeds
20:26:51 <Oxf13> look
20:26:57 <notting> ok, duly noted... separate proposal:
20:27:02 <Oxf13> does it really matter if the packages are 'critpath' or "critpath + some other stuff' ?
20:27:03 <abadger1999> * expanded to cover them
20:27:06 <Oxf13> that's not the real issue here
20:27:06 * nirik thinks this is a sort of implementation detail.
20:27:10 <skvidal> yes
20:27:12 <Oxf13> nirik: very much so
20:27:13 * notting redacts his typing
20:27:15 <abadger1999> Oxf13: Implementatoin wise, yes.
20:27:23 <mjg59> I'm +1 for section 2 as is
20:27:38 <Oxf13> abadger1999: for the sake of "does this policy make sense to work toward" it really doesn't matter.
20:27:41 <wwoods> "critpath" has a specific definition that (e.g.) does not include desktops other than the default. If you want to define another larger group that's a superset of critpath, that's an excellent idea
20:27:45 <mjg59> And now I'm going to find some caffeine
20:27:46 * notting is +1 for section 2 as written
20:27:49 <Kevin_Kofler> skvidal: It picks the notification daemon with the shortest name because the requirement is intentionally not specific.
20:27:55 <abadger1999> Oxf13: We can now modify critpath in the pkgdb... maintaining a second list for no reason means extra coding needs to be done in pkgdb and the mash driver script. bpodhi, etc
20:27:57 <cwickert> skvidal, right, both notification-deamon and xfce4-notifyd provide "desktop-notification-daemon" and this makes yum think that several xfce packages are critical path
20:27:58 <nirik> I'm +1 for section 2 and we can worry about the implementation details later.
20:28:11 <Kevin_Kofler> Not really a "problem" in yum, but in the way yum is being used to compute transitive closure here.
20:28:12 <Oxf13> abadger1999: again, not really important for today's meeting and today's vote.
20:28:15 <skvidal> cwickert: and how is that yum's fault - specify what you mean...
20:28:18 <pjones> nirik: likewise.
20:28:25 * skvidal is +1 for section 2
20:28:32 <cwickert> skvidal, problem != fault
20:28:34 <wwoods> (and if you want to use those newly-defined larger groups in various proposals/policies that's also excellent. but don't go throwing new things into critpath willy-nilly.)
20:28:44 <abadger1999> Oxf13: Are you going to write the bodhi and pkgdb and mash patches?
20:28:50 <mjg59> Ok, we're at 5 for section 2 as written
20:28:54 * nirik nods.
20:29:13 <cwickert> +1 for section 2
20:29:15 <mjg59> And we've got 30 minutes to get through section 3
20:29:16 <Kevin_Kofler> For the record: -1 to section 2, not needed.
20:29:17 <nirik> #agreed Section 2 is Approved. Implementation details will need to be worked out for listing/noting important packages.
20:29:36 <nirik> ok, on to section 3.
20:29:51 <Oxf13> abadger1999: not if the proposal doesn't get approved because we're too busy worried about the road signs 500 miles down the road and can't even get intot he car and start driving.
20:29:55 <mjg59> I'd like to propose that we firstly vote on section 3 as amended by Kevin's first proposal, ie the complete striking of section 3
20:29:55 <notting> Kevin's first amendment here i think can just be construed as a -1 vote on this section
20:30:09 <mjg59> To which I am -1
20:30:13 <Kevin_Kofler> Right, the first proposal is to strike it entirely.
20:30:23 <pjones> I'm -1 to striking section 3
20:30:29 <nirik> mjg59: you are -1 to not remove it? man, thats a lot of negativity.
20:30:33 <Kevin_Kofler> The second one is to at least allow 1 proventester to approve stable pushes as for critical packages.
20:30:33 <abadger1999> Oxf13: How does having an accurate map before you get in the car sound like a bad idea to you?
20:30:51 <Oxf13> abadger1999: we've moved on, you should too.
20:31:07 * skvidal is -1 to striking section 3
20:31:12 * nirik is -1 to striking section 3.
20:31:20 <Kevin_Kofler> +1 to striking section 3, for the reasons given in the ticket.
20:31:29 * notting is -1 to pre-emtpively striking it
20:31:35 <skvidal> that's 5
20:31:37 <pj

Thread Tools

All times are GMT. The time now is 08:25 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright ©2007 - 2008, www.linux-archive.org