--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Development/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo meeting ping -- bpepple, caillon, c4chris, dgilmore, dwmw2, f13, jeremy, jwb, notting, spot, nirik, tibbs, warren
* notting is here
jwbhere for a bi
* tibbs here
bpeppleHi everybody; who's around?
* warren here
f13although still somewhat in training.
* nirik is here.
abadger1999 buys some popcorn
bpeppleok, let's get started.
caillonabadger1999, would you like the popcorn seeds for 50cents or a bag for $8?
--- bpepple has changed the topic to: FESCO-Meeting -- Package dispute - https://www.redhat.com/archives/fedora-advisory-board/2008-February/msg00145.html - all
bpepplethis is about the ivtv-firmaware package the axel & kwizart have a disagreement about.
kwizart: shoot.
kwizartany question ?
abadger1999caillon: :-)
kwizartwell the review say it all
* dgilmore is here
caillonbasically, from what i can tell kwizart doesn't want any changes to the package to support RHEL, because he is unsure about the intricacies there.
nirikso, the sticking point is if there should be RHEL compatibility in the fedora package?
caillonwhereas axel wants to support it
nirik, that is my take on it, yes.
kwizartcaillon, supporting RHEL wihtout requesting EPEL-5 branch is without sense
f13kwizart: what's wrong with letting axel handle the RHEL aspects?
caillonkwizart, you can't request an EPEL branch if you deny the review.
tibbsFrom my understanding, Axel keeps neglecting to respond for long periods of time so kwizart opeend his own review.
bpepplenirik: well, that and axel feels the package was hijacked.
f13hrm, this would be easier if axel was here
nirikthere are no plans for an EPEL branch.
the kernel modules it needs are not in RHEL/epel
warrenwho has no plans?
caillontibbs, axel said that he had been on vacation and had listed it
on the vacation page
tibbsAnd then after he came back, he still neglected to respond to comments.
caillon(on the advisory board list)
kwizartthe ivtv-firmware package have been approved when the original review by Axel was closed to no answears...
* c4chris here now
nottingso, from a technical level
tibbsI mean, the first person to submit the package for review doesn't own it for all eternity.
nottingpackaging the firmware files in the old locations in the *current* fedora package is just nuts
dgilmorei honestly think that both axel and kwizart should work out a way to comaintain.  the RHEL part should be conditionalised so that it only happens on rhel builds
tibbsHas Axel offered to co-maintain?  Or does he demand to be the only person maintaining this package?
I mean, it's already in the distro.
caillondgilmore, tibbs, i suggested co-maintenance already on FAB.  axel doesn't believe it's possible.
kwizartdgilmore, that's what i have proposed to him. but he disagreed...
caillonthe /topic has my thoughts on it
dgilmoretibbs: axel wants it for himself currently
tibbsThe fact that Axel always denies cvsextras commits on his package seems relevant to me.
EvilBobAs an ivtv user, I am just glad to see it finally in the distro.
* c4chris dunno the tech details, but I found rude the way kwizart just closed axel's bz review request (several times)
* bpepple agrees with c4chris.
dgilmoretibbs: i honestly think denying cvsextras needs justification
tibbsI found it rude how Axel kept neglecting to respond to someone who was trying to help get things in the distro.
nirikwell, note there were month long gaps of no response there.
dgilmorec4chris: indeed that was very rude
kwizartc4chris, the bug was closed already once the package was left with needinfo to the submitters...
dgilmoretibbs: thats also rude
tibbsI mean, come on, we should not let one person hold a package hostage.  If someone else actually wants to do the work, then great.
* f13 thinks that trying to point fingers and rehash history doesn't solve anything.
tibbsWitness the distcc package.
f13lets start with the fact that the package is in Fedora now, and lets try to get some compromise between Axel and kwizart in the maintainership of said package.
caillontibbs, while that's true, we also don't want to make contributors feel like they are being subverted.
f13end of story.
bpepplef13: +1
warrenYou both want this puppy?  OK, you grab this end, you grab the other.
c4chrismy impression is that we should try to cool things down, but I'm pretty much at a loss to say exactly how...
cailloni fear this will turn into the same thing as the bug.
dgilmoref13: :)  i stand by  my earlier statement  both should co mainatian the package.  they both are passionate about it.  and the RHEL stuff should be conditionalised in the spec so that it only happens on RHEL
caillonaxel does one thing, kwizart reverts, or vice versa.
nottingtechnical proposal: explicit RHEL compatibility (file locations/symlinks, requirements, provides,  etc.) should be confined solely to EL-xxx branches, not to the main fedora packages
caillonif that happens, I will NOT be happy at all.
kwizartThe original review was created at the end of August by Axel... Fews days after I have raised many point that need to be fixed with the package most was easy... until the remaining "compat location problem", there were still issue with the package
dgilmorenotting: +100
f13caillon: right.  If that happens, I'll take the package hostage and neither one of them can touch it (:
niriknotting: no ifdef on dist ?
tibbsnotting: +1
warrenf13, puppy.
tibbsnirik: Actually I think it's the opposite.
nottingnirik: that's ok, if ugly. just not unconditional (as axel's package is at the moment)
caillonkwizart, but you still went ahead with your package after that one dispute when you knew axel was working on it.
f13notting: +1
bpepplenotting: +1
tibbscaillon: He came to #fedora-devel and asked about it.
c4chrisnotting: agreed
caillontibbs, did anyone else try to contact axel?
niriknotting: ok, +1 here... but isn't that something the packaging folks should approve? guess it doesn't matter much.
tibbsI don't know; I don't really see how that's relevant.
nottingnirik: possibly. caillon suggested in his mail above that it come to fesco, so i made a proposal
c4chrisok, so how about we formally ask both if comaintainership is OK ?  And revisit if necessary ?
warrenStrawman: If both don't agree, then neither can have it?
warrenWe really don't need to spend so much time on this seemingly simple dispute.
caillonc4chris, does my asking on FAB not count?  axel already said no.
c4chriscaillon: oh, right, sorry
yea, that counts
we draw dices ?
EvilBobif Axel was reading his bugzilla email he knew what was happening, everyone else could see it, users were forced to wait for this while Axel sat on his hands for days and weeks with nothing happening on the bug.
kwizartcaillon, Axel wasn't responding, for two months, some period was about holidays, ok - but He did commit on smart the 7/10/2007
caillonnotting, +1 to your proposal.  and we can push it down to FPC to draft an official doc if we need.
knurdwarren, I'm wondering why fesco even discussed this already; the other side wasn't herd yet and there was no real public discussion yet as Axel IMHo chose the wrong list
nirikknurd: is there a right list? devel?
c4chrisknurd: we were asked to discuss this AFAIK
knurdnirik, I'd say so
c4chris, caillon asked
c4chris, Axel asked the board, which is one step to far afaics
f13Proposal: Any future situations like this should continue to be handled on a case by case basis.  I see no reason to try and formulate some sort of 'policy' here.
c4chrisf13: yes
kwizartto be clear! i have nothing against co-maintain this package with Axel, but i care about riping out the compat location that are completely unneeded for inkernel ivtv.ko and ivtv-fb.ko modules
tibbs+1 (besides the existing stalled review policy, which I'm pretty sure was followed here).
nirikkwizart: what if they were in conditionals for only rhel?
warrenProposal: This waste of time is hurting our users and our development.  If they can't agree, then FESCo should just decide on something and just do it.  Maintaining a firmware package really isn't complicated!
caillonwarren, which is exactly why i brought it up here.
kwizartnirik, that's what i proposed him, he disagreed...i'm not against...
f13tibbs: can you show beyond doubt that the stalled review policy was followed ?
notting(random aside: these would require kmod packages on EL-xxx anyway, unless i'm missing something)
kwizartthe ivtv tools is still missing a reviewer because of this issue (i cannot continue to review this... with the current context)
c4chriswarren: sure.  But what do you propose as resolution of this case ?
niriknotting: yes. which are not allowed in epel.
warrenFurthermore, a maintainer who refuses to play with others when the package is really simple is less eligible to own a package.
dgilmorekwizart: i belive they are no longer needed
kwizartnotting, you get it right !
nottingnirik: doesn't that make adding the EL compat stuff in the package make even less sense?
nirikyes, I would say so.
kwizartbut now that ivtv is into the kernel , it may be possible to backport it...
dgilmorekwizart: i doubt RHEL will ever do that
kwizartat this time no work has been done about this AFAIK
f13so, if kwizart really did follow the stalled review policy, taking into account Axel's filed vacation, then I don't see much of a problem ehre.
warrennotting, it doesn't hurt EPEL to have the firmware, not our problem if they can't actually use it
f13Axel's review stalled, kwizart's didn't, and now axel doesn't like what kwizart is doing to the package, but that's just too bad.
tibbsf13: Well, failed to respond to comments for one month, comment added (and ticket set to needinfo, which is not required) and one week later ticket was closed.
f13warren: that's kind of lame.
tibbs: was Axel's vacation in that one month?
tibbsThat I don't know.
kwizartwarren, agreed also, there is care where a lib is only used outside of the fedoraproject. repositories
nottingwarren: i suppose. just seems odd to offer firmware+tools in epel if they can't work.
EvilBobnotting: it just leaves a hook in for atRPMs packages
tibbsThe whole needinfo->closed cycle repeated more than once.
warrennotting, it is a possibly valid criticism that we probably will not backport ivtv module, and a future RHEL not likely to even build it because we wouldn't want to support it?
tibbsI don't think Axel went on vacation three different times.
kwizartbut in this particular case, you can get ivtv > 1.0.x external kernel modules packaged without needing these particular compat locations...
nottingkwizart: firmware paths are a request_firmware()/hotplug interaction which shouldn't have anything to do with driver versions
warren: chances of it being backported to previous rhel are only a smidgen above zero
c4chrisI think f13's analysis is valid, so if we can all agree, we can dismiss this case using the MIA policy
warrenWe're approaching using half of the FESCO meeting only because we are uncomfortable about upsetting someone who regularly does not play with others.  Let's just decide on an owner and what exactly that owner is to do?
kwizartnotting, that's the point where older driver (that was using the own ivtv firmware loader implementation) would need thoses compat locations..
warrennotting, unless a big customer with $$$ wants it for some strange reason.
nottingkwizart: it implemented its own in-driver firmware loader? FAIL.
bpepplewarren: agreed, we need to resolve this and move on.
f13IMHO unless it can be shown that the stalled review policy was improperly followed, there is no dispute to discuss
c4chrisf13: +1
kwizartnotting, not since it is merged into the kernel (since kernel 2.6.20 )
f13and this is just a case of user A) filed a bug and maintianer B) doesn't agree with it.  Tough shit for user A).  No different than what we see on a day to day basis.
warrenkwizart, yeah, I was complaining at ivtv upstream years ago about the firmware loader but they didn't care. =)
27 minutes on this topic.
bpepplef13: +1.
nirikf13: +1
* bpepple agreed with warren that we need to move on.
warrenStraw: Perhaps a neutral 3rd party should take it for now and implement FESCO's recommendations?  Let the current parties cool down
f13that's 3 +1s here, can we vote and move on?
tibbsf13: +1 (but someone should double check, and it shouldn't be me because I reviewed the other ticket)
caillonwarren, that's what we do.  remember how long it took us to decide about freakin elections?
warrenvote on what exactly?
f13warren: that there is no real dispute here, unless somebody can prove that the stalled review policy was not followed.
jeremyf13: +1
warrenf13, +1
* warren really liked the puppy idea though. =)
cailloncan't normal users raise a packaging dispute without being the maintainer?
tibbsWe don't really have a policy for packaging disputes that I know of.
c4chriscaillon: sure, why not ?
tibbsWe probably need one.  (and something to cover the discc thing too).
caillonso it seems to me that there really is a dispute then.
warrenCase by case should theoretically work, but FESCO needs to have the guts to be assertive
f13caillon: they're called bugs
caillon: do you really want fesco to be involved every time somebody's bug gets closed and their feelers get hurt?
c4chriscaillon: axel should file a bz against the package first
caillonfair enough.
f13the interesting question will be if / when the package gets 'cvsextras' commit access
bpeppletibbs: I believe we (FESCo) would appoint a third party to resolve it.  I believe we decided this last summer (I can pull the irc log for it after the meeting).
warrenTheoretically you can have a package "open" in that way but the owner still has the right to decide
and somebody checking things in without permission is violating ownership
tibbsbpepple: I recall discussing it but I'm having trouble finding a page in the wiki that describes things.
nirikf13: it does. ivtv-firmware at least
warren"open" access is meant for things that would be considered obviously acceptable by the owner
bpeppletibbs: I'll pull a link for it after the meeting (I believe it was around june of last year).
caillonbpepple, maybe we should do that then
nirikok, so do we appoint such a mediator here?
* nirik notes 35minutes now. ;)
bpepplecaillon: I'm fine with that.
warrenHas jarod been involved in this dispute?
He has ivtv hardware
I have ivtv hardware but haven't used it in years...
caillonwarren, he seems like a good candidate to be the mediator then
EvilBobI have ivtv hardware that has been idle for two years
bpepplewarren: I don't recall seeing him in the discussion, so he would probably be a good candidate in my opinion.
caillonproposal: jarod mediates this issue
c4chriscaillon: +1
nirik+1 if he agrees, otherwise we can pick someone else.
warrenJarod has binding arbitration powers?
warren: yes.
warrenOK, +1
caillonwarren, on this issue, yes.
just move on already
bpepplef13: +1000.
warren: could you contact jarod?
bpepplewarren: thanks.
ok, let's move on.
is poelcat about?
--- poelcat has changed the topic to: vote http://fedoraproject.org/wiki/Features/JigdoRelease
poelcatrevisit based on questions and feedback from release engineering and feature owner
yes :)
* tibbs afk 3 minutes
bpepplef13: did they answer your questions sufficently?
nirikit sounds like he really wants to help and try and get it on track...
warrenI'm +1 on Jigdo, give them a chance?
poelcatbtw spot votes +1 in absentia
warrenWill it hurt us not to?
f13bpepple: I'm OK to +1 this as a feature, but if things aren't testable by beta, it'll have to be dropped.
bpepplef13: sounds reasonable.
nirik+1 here.
nirikkanarip: hopefully you have time to help out and try and get this setup... ;)
* jeremy continues to abstain on this one
bpeppleok, I see eight '+1', and one '0'.
nottingat least, +1 with the same caveats as spot (only as additional, not as default)
poelcatREMINDER: Next week is the last meeting before F9 feature freeze and thus last opportunity to propose new features for acceptance for F9
that's all i have
bpepplepoelcat: great, thanks!
--- bpepple has changed the topic to: FESCO-Meeting -- Decide on candidate announcement date for 2008 FESCo Election - all
warrendate to open nominations?
or close?
bpepplewarren: open.
warrenwhen did we make the election itself?
bpepplewarren: third tuesday after f9 release.
tibbs_And my campus lost its network connection.
nirikhow about nominations open first tuesday after release?
bpeppledo we want to open up nominations one month before the election or do we need more time?
caillon+1 to that since it's the first proposal
warrenbpepple, I hope that nominations wont interfere with frantic last minute work to stabilize F9.
nirikyeah, thats why I was thinking after release...
warrenor after hard freeze
bpeppleI'm fine with nirik's proposal.
dgilmorei think after feature freeze
warrennirik, +1
dgilmorebut im ok with nirik's idea
warrenThis doesn't need to be a bikeshed color decision.
f13yep, I'm happy to pick a date and deal with it
one was proposed. worksforme
bpepplef13: works for me also.
nirikanyone else ? more yes votes and we can move on?
bpeppleanything else in regard to the election or should we move on?
bpepplebtw, I've updated the election page for our most recent decisions. http://fedoraproject.org/wiki/PackageMaintainers/Policy/FESCoElections
dgilmorelets move
bpepplemoving on....
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
f13rebuild status...
dgilmoref13: how many are failing?
f13getting numbers right now
tibbskoji is really plowing through the rebuilds.  It should be done this evening.
f131425 successful builds
427 failed builds
probably 300 left to go
caillonhow many total submitted?
warrenf13, after those 300 perl goes in?
nirikis there news of the perl landing?
f13warren: that's up to spot
I have 2213 tasks to follow up on once the builds are done
but some tasks were lost due to outages and resubmissions and such
but I'm still running the need43 script so we'll know what things (except the blacklisted ones) still need rebuilding.
caillonf13, do we have a policy for making sure that those on the blacklist get rebuilt before $DATE?
f13caillon: not hard policy.
caillon: I"d consider them f9 targets
not blockers
after beta I'll remove the blacklist and make sure there are bugs filed for the things not yet built
caillonsounds good.  thanks.
f13this friday hopefully I'll trigger the follow up script and file bugs for the 450~ known failures.
bpepplef13: cool.
f13all in all, the buildsystem held up fairly well
most the outages weren't due to the mass build
warrenf13, was the weirdness due to IO?
caillonf13, note that some of the failures were subsequently rebuilt successfully
f13and we were able to get a good view of the buildsystem under full load for long periods of time
c4chrisf13 can you remind me if you already have a URL where the failed builds are listed ?
f13caillon: yes, the script will take that into account.
f13c4chris: it's a koji query for buildArch tasks, state failed, builder jkeating
bpeppleok, anything else?  Or should we wrap up for this week?
c4chrisf13: ah, ok, thx
* warren goes to talk to jarod
f13I'm happy with how quickly koji is getting through them, as well as other people's packages are getting through in reasonable times too
f13bpepple: I'm good
mbonnetf13: you might want to include state=canceled in that query, I canceled a few builds that were hanging
bpeppleok, let's put a fork in it then.
* bpepple will end the meeting in 60
f13mbonnet: hrm, ok.  I wasn't originally because I was counting those as the maintainer wished to nto have it built
* bpepple will end the meeting in 30
f13mbonnet: but I can file bugs for 'em anyway
* bpepple will end the meeting in 15
bpepple-- MARK -- Meeting End
dgilmoref13: id be happier if we had the blade centre but its coping pretty well considering
bpeppleThanks, everyone!
dgilmorethanks bpepple
f13dgilmore: oh yes, I very much want more hardware (:
c4christhanks bpepple

Generated by irclog2html.py 2.5 by Marius Gedminas - find it at mg.pov.lt!