FESCO Meeting 071407

--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
bpeppleFESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren
* tibbs here
dgilmore is here
bpeppleHi everybody; who's around?
* c4chris is here
nirik is here.
poelcat here
tibbsI need a new font; it looks like bpepple's in Italy.
spotbpepple: abadger1999, f13, jeremy, and notting are not going to be here
they're in "a meeting"
bpeppleah, ok.
* spot will unfortunately, be here. :)
warren here
bpepplealright, let's start off slowly with something easy.
--- bpepple has changed the topic to: FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-maintainers/2007-July/msg00127.html
warrenabadger1999 went to raleigh too?
* nirik has no objections... all seems fine to me.
bpeppleFPC had a proposal for R packaging. anyone have any objections?
spotwarren: apparently.
c4chrisfine with me
* bpepple didn't have any objections either.
tibbsWe already have R packages in the distro; this just makes things more consistent and a bit cleaner.
c4christhe RPM_OPT_FLAG thing is a bit unfortunate, but I don't see an easy way to fix it
spotc4chris: i spent a good hour trying to figure out how to cleanly override it and couldn't find one
* dgilmore is ok with it +1
c4chrisspot: thx for trying
bpeppleAlright. I don't see any objections here or on the mailing list, so we can consider this approved.
moving on, unless someone objects...
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Secondary Arches - http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures -spot
bpepplespot: you want to lead this?
spotnot really.
spotbut i will.
* bpepple can understand spot's reluctance.
dwmw2I'll do it if you like :)
spotthis is my revised draft for the initial enablement of secondary architectures.
warrenhmm, wiki down to other people too?
dgilmorespot: if you want i can do this
bpepplewarren: yeah.
spotrather than waste the whole meeting listening to people argue, i'd like to see if people are willing to vote on the draft as is
tibbsBTW, the wiki is giving Service Temporarily Unavailable for the link in the topic.
rdieterthen, looks good to me! :)
dgilmorethe draft as is i am fine with
tibbsHmm, seems back now.
spotif not, i'll withdraw it from the schedule today
and we can argue on the mailing list.
rdietervote +1
rdieterargue -1
dwmw2I don't want to interrupt the meeting arguing -- but if you vote please explicitly vote on the modified proposal too.
c4chrisI like spot's version
spotdwmw2: i'm afraid to ask, but which one is this?
tibbsLink to this modified proposal?
spotno, i don't think we need to vote on your "discussion page"
dwmw2basically, we shouldn't ship failed builds automatically. The packager should make an explicit _decision_ to ship it
that's all.
they should be _allowed_ to ship the partially-failed build, of course. But a lot of the time it'll actually be a generic problem. So they should at least look before the package hits the repos
* spot notes that this consists of argument
spotalbeit, one-sided
since i'm not willing to get into it here.
dwmw2and a lot of the time there's no _urgency_ to getting the new package out, so it's much nicer to the arch teams to give them a chance to fix it first, before their build systems get out of sync
* dwmw2 done.
spotthe question before FESCo
dwmw2that's the alternative, anyway.
spotdo you want to vote on the draft
as is
or table it?
* dgilmore votes +1 for the proposal as it
rdietervote now, non-pass = tabled.
* c4chris votes +1 to http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures
nirikI would say +1 for now, and we revisit once we have a secondary arch and can adjust... perhaps we can revisit dwmw2's concerns when we have data...
tibbsI believe the proposal is a good place to start.
jwbi'm here
sorry i'm late
warren+1 here
spotwe can always fine tune once we've gotten the foundation down.
* spot votes +1
bpepple+1, agrees it is a good place to start.  we can always modify it later.
dgilmorebpepple: i say its approved as is
tibbsAm I correct in assuming that the bulk of the disagreement stems from the second bullet in the "Structure" section?
jwbare we voting on secondary arches?
bpepplejwb: yes.
rdieter+1 spot's proposal
* jwb quickly scrolls back
bpeppleI believe we've got seven '+1' to my count.
dwmw2tibbs: not quite. I don't think they should necessarily be fatal either. You shouldn't need to put the whole build through again. You'd only need to click a 'ship it anyway' button after you decide it's not actually a generic issue.
jwbhere's my opinion
tibbsIn case it's not clear, +1 to spot's proposal from me.
jwb(like anyone cares)
i think what spot has is a _great_ start. i also think there will be some time before we truly know if it needs adjustment. dwmw2's proposal makes sense to me, but i don't see it being needed to start with
or rather, i don't see it as a blocker to get started on secondary arches
spotjwb: when problems arise, we'll fix them. i don't claim perfection. :)
bpepplejwb: pretty much my thoughts.  that's why I gave a '+1' to spot's proposal.
dwmw2my concern is that it would be a regression. If we keep PPC as a primary arch for now, until we've shown the secondary arch thing can work (whichever way we end up doing it) that would be acceptable.
jwbdwmw2, we aren't deciding the arches today
dwmw2I know
jwband i think we've said ppc will stay for the time being
spotdwmw2: i already have said that I'd support providing secondary before moving any current primary
jwbso for now, i give spot's proposal a +1
spoterr... "proving"
not providing.
dwmw2which is why I'm still concerned about the 'do it spots way and screw over the arch teams, and then demote ppc too' outcome. spot: yes, I know that's been said. It's also been denied. But I'll shut up now
spotbpepple: i think this issue is done, feel free to move on.
jwbdwmw2, as an aside we should officially form the ppc arch team now anyway
dwmw2, regardless of the status in the buildsys
dwmw2yeah. and the x86_64 and i386 teams too, with people who actually know assembly, compilers, etc. But that's off-topic and I've already shut up :)
bpeppleok, unless there's anything else I think we can move on.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Schedule for future branching of CVS - f13
dgilmorebpepple: he is not here lets move on
bpeppledgilmore: agreed.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Merge Reviews for F8 target - all
* bpepple waits.
jwbcould someone clarify what that last topic was?
as in branch for f-8?
i guess it doesn't matter
move on
bpepplejwb: yeah, we tabled the discussion when we wanted branches to occur until after F7 was released.
jwbah, ok
move on
crap, i have to go to a real life meeting for work
* jwb regrettably bows out
bpeppleOk, regarding merge reviews I sent out an e-mail to the lists, and I believe I got one reply on how we should handle the remaining merge reviews.
my thought is that we shouldn't have it be a goal for F-8, but plan some organized review days possibly,
spotideally, this would have been a FUDCon item
bpepplespot: yeah. :)
rdieterpush back to F9?
spotbut since we're not having one, i think that review days are the next best thing
warrenWould it be reasonable to declare merge reviews as a BLOCKER for F9?
dgilmorespot: we do have the virtual fudcon comming up
bpepplewarren: I would like to.
spotwarren: seems sane
warrenGet as much done as possible before F8
of course
bpeppledgilmore: that was one of the times I was hoping to hold the review days.
tibbsWe've been making progress on the merge reviews, but so many of them are stalling.
* rdieter thinks we need more pointy sticks.
nirikwould announcing now that they have to be done before F9 help motivate reviewers/maintainers to do more ? Right now there is no real goal, so I think lots of people are just ignoring them.
warrenI think F9 needs to be an absolute deadline for all merge reviews.
bpepplewarren: +1
c4chrisnirik: yea, I think that might be good
warrenWe need some kind of interim goal for F8 though
nirikwarren: +1 on F9 deadline.
bpepplewarren: agreed, but what to use as a goal?
tibbsAll currently in-progress merge reviews completed?
Everything in @base completed?
warrenbpepple, that is difficult =(.  We can't make anything "binding" or that is a deadlie
bpeppletibbs: do you know how many that is right now by chance?
tibbsSorry, I don't.
warrenhow about @base and gnome?  (Gnome should be fairly easy to clean up.)
tibbsLet me do some checking.
bpeppletibbs: no worries.
rdieterheck @base/gnome could/should be done for f8 really, imo.
nirikI think there are around 700 or so in new/no reviewer
bpepplewarren: does base include kernel & glib, etc?
* spot will give a free sparc to whomever does the most merge reviews before f8... :)
warrenbpepple, glib yes. =)
spot(note: will not be good sparc)
tibbsbpepple: 87 merge reviews with fedora-review=?
dgilmorespot: you still trying to give away the sparc32 machines?
spotdgilmore: no, i solved that problem.
* nirik gave away his last IPX a long time ago... no need for anymore.
bpeppletibbs: that seems like a reasonable number to complete by F8.
warrenbpepple, some of the core bootstrapping stuff will be weird by definition and I'm not sure anyone wants to subject themselves to that kind of mental torture... and we really don't want to screw with the work that the tools people do as few people understand it.
tibbsplus 32 with fedora-review=-
warrenbpepple, OTOH our fedora kernel people keep improving the kernel spec.
spotwarren: for the better, i might add. :)
jimaspot: offering to punish people for doing merge reviews will do no good.
tibbs22 of all reviews are in NEEDINFO.
bpepplewarren: I think setting a goal of completing most of the core & gnome might be reasonable.
tibbs9 of those NEEDINFOs have been there for three months.
warrenAre NEEDINFO against a RH engineer who has failed to respond for a while?
I can ask engineering management to prod RH engineers to at least RESPOND to NEEDINFO by a certain timeout.
tibbsI think that's the case, yes, although I'd have to check.
bpeppledo we know when the virtual fudcon is going to be held?
warrenI think ratifying "F9 is the absolute deadline for merge reviews." would encourage getting some done before F8.  If people realize the pain this will be at F9 they might do something earlier.
bpepplewarren: agreed.
dwmw2dgilmore: on the subject of giving away sparc machines... I still have a pile of Ultra 5s here :)
tibbsThere are also a few reviews that are really merge reviews but aren't marked as such; libsilc, agg, gaim, etc.
warrenRatify the F9 goal first, then the F8 goal... well that is more difficult to define.
bpeppleproposal: making merge reviews a Blocker for F9.
tibbs(but that's still a load of work)
nirikdwmw2: I'd take one, but the shipping would probibly make it not worth it. ;)
warrenRH has business reasons to get it done before F9 too... improve quality for the next RHEL.
dwmw2nirik: where are you?
dwmw2I spend half my life in tin cans at the moment. Whatever continent you're on I could probably ship it overland
nirikdwmw2: lets take it to fedora-devel?
warren(Disclaimer: We don't know which Fedora RHEL6 will be based upon yet.)
spotdwmw2: feel free to send some to me in westford.
bpeppleI count six '+1' so far,  anyone else?
c4chrisI count 7
bpepplec4chris: your right.  I missed spot's vote.
ok, so we've approved making merge reviews a blocker for F9.
rdieter+1 (for the record, sorry got pulled away for a couple minutes)
bpepplewe probably need to discuss what kind of goal we want for F8 on the mailing list, and also plan for a few review days.
is there anything else people want to discuss in regard to this?
* bpepple give tibbs the floor.
tibbsDo we actually have buy-in from RH management here,
warrentibbs, we can get it for F9 given the long run-way.
tibbsor are these merge reviews more of a volunteer effort by the engineers?
spoti don't think RH management is involved
warrenFor F9 I believe I can get buy-in for some engineering time.
For F8 I think I can get buy-in to at least RESPOND to NEEDINFO.
That is reasonable enough.
tibbsYes, agreed.
c4chriswarren: good, please try to get the buy-in
* warren writes mail
tibbsMy concern is that we can set all the deadlines we want, but if people feel secure just ignoring them then we know we won't finish.
c4christibbs: agreed
bpeppleanything else?
tibbsI'm done.
bpeppleok, let's move on.
rdieteri'm sure we can come up with appropriate threats if need-be, but it would be sad if it really had to come to that.
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
bpepplerdieter: agreed.
poelcatI made Feature proposal final by rolling in feedback from last meeting and previous requests for a process flow and example template.  spot reviewed and concurred with lastest changes.
I can't decide if namespace for policy matters...
Releases/Features/Policy or Features/Policy
bpeppleFeatures/Policy seems fine to me.
poelcatalso need to reassess if using Categories is going to work for managing wiki pages or if will rely on namespace instead
metherbpepple, any movement on deciding which members can freely fix issues in all packages?
bpepplemether: a solution for that is based on the package db, that still isn't in production yet.
metherbpepple, you can't decide and then grant access to cvs with the current solution?
dgilmoremether: the people that historically have fixed package issues were given access
rdietermether: only duly-knighted fedora ninja's, obviously. :)  Of course, we can't divulge any ninja's identity, cause well, you know...
warrentibbs, that is a valid concern, but our improved communication with engineering management lately might make this possible.  If we give a LONG run-way and set expectations and the ability to plan resources for it, it can be done.
tibbswarren: Good to know.
mether: Unfortunately the only blanket access we have is cvs administrator provilege.
Ugh, privilege.
metherthe problem is that without a policy in place,  there is no general information on who can fix the issues and people still have to ask others permission before fixing them
tibbsWe had a policy, but then ACLs came.
rdietermether: people should always (at least try to anyway) ask first, regardless...
metherrdieter: i would think that fixing simple issues dont require permission
metherrdieter: obviously always asking is not going to be possible anyway
tibbs"Who is allowed to modify which packages".
rdietermether: I said "try", then go ahead. :)
warrenThere are cases in the past where blanket access was clearly acceptable
like mass rebuilds
nirikProblem is that if there is some "simple thing" that needs intervention for all the time, why isn't the maintainer maintaining?
warrennirik, that is a valid question.
metheri dont know but i see the list of packages with EVR issues growing
warrennirik, as we improve infrastructure and data reporting later we could more easily identify where maintainership accountability is failing.
tibbsYes, php-syck is the poster child.
It has a maintainer; he's even active in the alpha port. But he never works on the package.
nirikmether: yeah, thats likely due to bodhi... ;(
bpepplemether: I mentioned briefly in one of the weekly FESCo summaries about some of the people that have access.  Look at the ACL section: http://fedoraproject.org/wiki/Extras/SteeringCommittee/Meeting-20070531
warrenbodhi doesn't enforce EVR?
metherwarren: no and I think koji was supposed to have a RFE to prevent builds with such issues
nirikwarren: bodhi has F-7, so someone imports a new package and builds on all branches, and FC-6 goes right out, but F7 goes to updates-testing...
tibbswarren: People aren't actually pushing their packages.
warrenoh, that.
Since bodhi and merge for FC6 was rejected, I don't think we will be able to fix this until FC-6 is retired.
* nirik is carefull to wait until something goes to F7-updates to push FC-6 builds, but I suspect many people don't notice/realize the EVR issue.
warrenI'll write up a fedora-devel-announce "reminder" about this issue now.
bpepplewarren: thanks.
methernirik: why isnt Micheal Schwendt on that list?
tibbsHas he asked to be on that list?
nirikmether: I think he was asked and didn't want it.
metherok. I thought he would have wanted it since he complained about ACL's preventing him
warrenHe was invited numerous times but declined
he declined because he thought he would be expected to do the cvsadmin procedure which he found to be tedious
(it is...)
we'll automate most of the cvsadmin procedure soon
tibbsI recall addressing the idea that acls should be applied to new packages only upon request.
* nirik cheers.
tibbsBut I guess we left that for said automation.
methertibbs, looks like we didnt agree on that at all
warrenperhaps we could have a sub-level for CVS admin after pkgdb....
not quite full access, but the ability to change ACL's
nirikperhaps we could ask mschwent again and see if he would like access to fix issues? I would be happy to allow him access...
warren(That way somebody can still change access levels but all activities are logged by commit mail.  cvsadmin members can do all kinds of things not watched.)
After pkgdb goes live we really don't need that many people with full CVS access.
anyway, this is a different topic
nirik, could you ask mschwendt?
nirikmether: if you spot any specific issues you think should be fixed, but can't due to acl's feel free to ping me. I would be happy to help...
warren: sure, if FESCO is ok with giving him that permission...
methernirik: just looking at the broken EVR list
dgilmorenirik: he has been offered it a couple of times and regected it
warrennirik, we had wanted to a few times in the past.
metherhas anyone in FESCo
looked at
bpepplemether: yeah, jeremy brought it up a few weeks back.
methernote that Debian seems to have a way to short circuit the long process
see the comment in that blog
bpepplewe've talked about it briefly, but haven't really had much time to much beyond that.
metherthere was a LWN article on the ACL's issues in Fedora and a article on the Debian process next week
If folks havent looked at both, I would suggest doing so
tibbsI've been sponsoring many people, and the procedure is not that long or arduous, but I can only do so many.
nirikfor EVR issues, can we update the docs to note that pushing FC6 before F7 is out will break EVR?
metherthat would be a good idea and if we can fix the current issues that would be good too
bpepplenirik: I have no problem with that.  go for it.
metherdebian process - http://lwn.net/Articles/239231/
bpeppleok, we're almost out of time.  Any last items before calling it quits for today?
metherFedora ACL issues - http://lwn.net/Articles/238284/
warrenwhen were these published?
methercouple of weeks before
warrenDebian creating a lower level of developer
tibbsThis is another "once we have packagedb" thing.
warrenMy developer rank proposal would have done something like this too.
bpeppletibbs: agreed.  a lot of the problems can be resolved once it's in production.
Alright, I think we can probably wrap-up now.
* bpepple will end the meeting in 60
tibbsI offered to modify the current acl enforcement code to allow restricted users but was told not to bother because packagedb was coming.
* bpepple will end the meeting in 30
warrentibbs, restricted meaning what?
tibbsrestricted to modifying your own packages only.
* warren focuses on writing mail
* bpepple will end the meeting in 15
tibbsBTW, we've finally made it below 900 reviews in the queue.
bpepple-- MARK -- Meeting End
thanks, everyone!

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