| --- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process | ||
| bpepple | FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren | |
|---|---|---|
| * tibbs here | ||
| dgilmore is here | ||
| bpepple | Hi everybody; who's around? | |
| * c4chris is here | ||
| nirik is here. | ||
| poelcat here | ||
| tibbs | I need a new font; it looks like bpepple's in Italy. | |
| spot | bpepple: abadger1999, f13, jeremy, and notting are not going to be here | |
| they're in "a meeting" | ||
| bpepple | ah, ok. | |
| * spot will unfortunately, be here. :) | ||
| warren here | ||
| bpepple | alright, 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 | ||
| rdieter | here | |
| warren | abadger1999 went to raleigh too? | |
| * nirik has no objections... all seems fine to me. | ||
| bpepple | FPC had a proposal for R packaging. anyone have any objections? | |
| spot | warren: apparently. | |
| tibbs | http://fedoraproject.org/wiki/PackagingDrafts/R | |
| c4chris | fine with me | |
| * bpepple didn't have any objections either. | ||
| tibbs | We already have R packages in the distro; this just makes things more consistent and a bit cleaner. | |
| c4chris | the RPM_OPT_FLAG thing is a bit unfortunate, but I don't see an easy way to fix it | |
| spot | c4chris: 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 | ||
| tibbs | +1 | |
| c4chris | spot: thx for trying | |
| bpepple | Alright. 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 | ||
| bpepple | spot: you want to lead this? | |
| spot | not really. | |
| spot | but i will. | |
| * bpepple can understand spot's reluctance. | ||
| dwmw2 | I'll do it if you like :) | |
| spot | this is my revised draft for the initial enablement of secondary architectures. | |
| warren | hmm, wiki down to other people too? | |
| dgilmore | spot: if you want i can do this | |
| bpepple | warren: yeah. | |
| spot | rather 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 | |
| tibbs | BTW, the wiki is giving Service Temporarily Unavailable for the link in the topic. | |
| rdieter | then, looks good to me! :) | |
| dgilmore | the draft as is i am fine with | |
| tibbs | Hmm, seems back now. | |
| spot | if not, i'll withdraw it from the schedule today | |
| and we can argue on the mailing list. | ||
| rdieter | vote +1 | |
| dgilmore | +1 | |
| rdieter | argue -1 | |
| dwmw2 | I don't want to interrupt the meeting arguing -- but if you vote please explicitly vote on the modified proposal too. | |
| c4chris | I like spot's version | |
| spot | dwmw2: i'm afraid to ask, but which one is this? | |
| tibbs | Link to this modified proposal? | |
| dwmw2 | http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitecturesDiscussion | |
| spot | no, i don't think we need to vote on your "discussion page" | |
| dwmw2 | basically, 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 | ||
| spot | albeit, one-sided | |
| since i'm not willing to get into it here. | ||
| dwmw2 | and 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. | ||
| spot | the question before FESCo | |
| dwmw2 | that's the alternative, anyway. | |
| spot | do you want to vote on the draft | |
| as is | ||
| or table it? | ||
| * dgilmore votes +1 for the proposal as it | ||
| rdieter | vote now, non-pass = tabled. | |
| * c4chris votes +1 to http://fedoraproject.org/wiki/TomCallaway/SecondaryArchitectures | ||
| nirik | I 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... | |
| tibbs | I believe the proposal is a good place to start. | |
| jwb | i'm here | |
| sorry i'm late | ||
| warren | +1 here | |
| spot | we 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. | |
| dgilmore | bpepple: i say its approved as is | |
| tibbs | Am I correct in assuming that the bulk of the disagreement stems from the second bullet in the "Structure" section? | |
| jwb | are we voting on secondary arches? | |
| bpepple | jwb: yes. | |
| rdieter | +1 spot's proposal | |
| * jwb quickly scrolls back | ||
| bpepple | I believe we've got seven '+1' to my count. | |
| dwmw2 | tibbs: 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. | |
| jwb | here's my opinion | |
| tibbs | In 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 | ||
| spot | jwb: when problems arise, we'll fix them. i don't claim perfection. :) | |
| bpepple | jwb: pretty much my thoughts. that's why I gave a '+1' to spot's proposal. | |
| dwmw2 | my 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. | |
| jwb | dwmw2, we aren't deciding the arches today | |
| dwmw2 | I know | |
| jwb | and i think we've said ppc will stay for the time being | |
| spot | dwmw2: i already have said that I'd support providing secondary before moving any current primary | |
| jwb | so for now, i give spot's proposal a +1 | |
| spot | err... "proving" | |
| not providing. | ||
| dwmw2 | which 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 | |
| spot | bpepple: i think this issue is done, feel free to move on. | |
| jwb | dwmw2, as an aside we should officially form the ppc arch team now anyway | |
| dwmw2, regardless of the status in the buildsys | ||
| dwmw2 | yeah. 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 :) | |
| bpepple | ok, 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 | ||
| dgilmore | bpepple: he is not here lets move on | |
| bpepple | dgilmore: agreed. | |
| --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Merge Reviews for F8 target - all | ||
| jwb | wait | |
| * bpepple waits. | ||
| jwb | could someone clarify what that last topic was? | |
| as in branch for f-8? | ||
| i guess it doesn't matter | ||
| move on | ||
| bpepple | jwb: yeah, we tabled the discussion when we wanted branches to occur until after F7 was released. | |
| jwb | ah, ok | |
| move on | ||
| :) | ||
| crap, i have to go to a real life meeting for work | ||
| * jwb regrettably bows out | ||
| bpepple | Ok, 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, | ||
| spot | ideally, this would have been a FUDCon item | |
| bpepple | spot: yeah. :) | |
| rdieter | push back to F9? | |
| spot | but since we're not having one, i think that review days are the next best thing | |
| warren | Would it be reasonable to declare merge reviews as a BLOCKER for F9? | |
| dgilmore | spot: we do have the virtual fudcon comming up | |
| bpepple | warren: I would like to. | |
| spot | warren: seems sane | |
| warren | Get as much done as possible before F8 | |
| of course | ||
| bpepple | dgilmore: that was one of the times I was hoping to hold the review days. | |
| tibbs | We've been making progress on the merge reviews, but so many of them are stalling. | |
| * rdieter thinks we need more pointy sticks. | ||
| nirik | would 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. | |
| warren | I think F9 needs to be an absolute deadline for all merge reviews. | |
| bpepple | warren: +1 | |
| c4chris | nirik: yea, I think that might be good | |
| warren | We need some kind of interim goal for F8 though | |
| nirik | warren: +1 on F9 deadline. | |
| bpepple | warren: agreed, but what to use as a goal? | |
| tibbs | All currently in-progress merge reviews completed? | |
| Everything in @base completed? | ||
| warren | bpepple, that is difficult =(. We can't make anything "binding" or that is a deadlie | |
| warren | deadline | |
| bpepple | tibbs: do you know how many that is right now by chance? | |
| tibbs | Sorry, I don't. | |
| warren | how about @base and gnome? (Gnome should be fairly easy to clean up.) | |
| tibbs | Let me do some checking. | |
| bpepple | tibbs: no worries. | |
| rdieter | heck @base/gnome could/should be done for f8 really, imo. | |
| nirik | I think there are around 700 or so in new/no reviewer | |
| bpepple | warren: does base include kernel & glib, etc? | |
| * spot will give a free sparc to whomever does the most merge reviews before f8... :) | ||
| warren | bpepple, glib yes. =) | |
| spot | (note: will not be good sparc) | |
| tibbs | bpepple: 87 merge reviews with fedora-review=? | |
| dgilmore | spot: you still trying to give away the sparc32 machines? | |
| spot | dgilmore: no, i solved that problem. | |
| * nirik gave away his last IPX a long time ago... no need for anymore. | ||
| bpepple | tibbs: that seems like a reasonable number to complete by F8. | |
| warren | bpepple, 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. | |
| tibbs | plus 32 with fedora-review=- | |
| warren | bpepple, OTOH our fedora kernel people keep improving the kernel spec. | |
| spot | warren: for the better, i might add. :) | |
| jima | spot: offering to punish people for doing merge reviews will do no good. | |
| tibbs | 22 of all reviews are in NEEDINFO. | |
| bpepple | warren: I think setting a goal of completing most of the core & gnome might be reasonable. | |
| tibbs | 9 of those NEEDINFOs have been there for three months. | |
| warren | Are 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. | ||
| tibbs | I think that's the case, yes, although I'd have to check. | |
| bpepple | do we know when the virtual fudcon is going to be held? | |
| warren | I 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. | |
| bpepple | warren: agreed. | |
| dwmw2 | dgilmore: on the subject of giving away sparc machines... I still have a pile of Ultra 5s here :) | |
| tibbs | There are also a few reviews that are really merge reviews but aren't marked as such; libsilc, agg, gaim, etc. | |
| warren | Ratify the F9 goal first, then the F8 goal... well that is more difficult to define. | |
| bpepple | proposal: making merge reviews a Blocker for F9. | |
| +1 | ||
| nirik | +1 | |
| tibbs | +1 | |
| warren | +1 | |
| c4chris | +1 | |
| tibbs | (but that's still a load of work) | |
| nirik | dwmw2: I'd take one, but the shipping would probibly make it not worth it. ;) | |
| warren | RH has business reasons to get it done before F9 too... improve quality for the next RHEL. | |
| dwmw2 | nirik: where are you? | |
| spot | +1 | |
| dwmw2 | I spend half my life in tin cans at the moment. Whatever continent you're on I could probably ship it overland | |
| nirik | dwmw2: lets take it to fedora-devel? | |
| warren | (Disclaimer: We don't know which Fedora RHEL6 will be based upon yet.) | |
| dgilmore | +1 | |
| spot | dwmw2: feel free to send some to me in westford. | |
| bpepple | I count six '+1' so far, anyone else? | |
| c4chris | I count 7 | |
| bpepple | c4chris: 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) | |
| bpepple | we 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? | ||
| tibbs | Yes. | |
| * bpepple give tibbs the floor. | ||
| tibbs | Do we actually have buy-in from RH management here, | |
| warren | tibbs, we can get it for F9 given the long run-way. | |
| tibbs | or are these merge reviews more of a volunteer effort by the engineers? | |
| spot | i don't think RH management is involved | |
| warren | For 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. | ||
| tibbs | Yes, agreed. | |
| c4chris | warren: good, please try to get the buy-in | |
| * warren writes mail | ||
| tibbs | My 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. | |
| c4chris | tibbs: agreed | |
| bpepple | anything else? | |
| tibbs | I'm done. | |
| bpepple | ok, let's move on. | |
| rdieter | i'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 | ||
| bpepple | rdieter: agreed. | |
| poelcat | I 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 | ||
| bpepple | Features/Policy seems fine to me. | |
| poelcat | also need to reassess if using Categories is going to work for managing wiki pages or if will rely on namespace instead | |
| mether | bpepple, any movement on deciding which members can freely fix issues in all packages? | |
| bpepple | mether: a solution for that is based on the package db, that still isn't in production yet. | |
| mether | bpepple, you can't decide and then grant access to cvs with the current solution? | |
| dgilmore | mether: the people that historically have fixed package issues were given access | |
| rdieter | mether: only duly-knighted fedora ninja's, obviously. :) Of course, we can't divulge any ninja's identity, cause well, you know... | |
| warren | tibbs, 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. | |
| tibbs | warren: Good to know. | |
| mether: Unfortunately the only blanket access we have is cvs administrator provilege. | ||
| Ugh, privilege. | ||
| mether | the 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 | |
| tibbs | We had a policy, but then ACLs came. | |
| rdieter | mether: people should always (at least try to anyway) ask first, regardless... | |
| mether | rdieter: i would think that fixing simple issues dont require permission | |
| tibbs | http://fedoraproject.org/wiki/PackageMaintainers/Policy | |
| mether | rdieter: obviously always asking is not going to be possible anyway | |
| tibbs | "Who is allowed to modify which packages". | |
| rdieter | mether: I said "try", then go ahead. :) | |
| warren | There are cases in the past where blanket access was clearly acceptable | |
| like mass rebuilds | ||
| nirik | Problem is that if there is some "simple thing" that needs intervention for all the time, why isn't the maintainer maintaining? | |
| warren | nirik, that is a valid question. | |
| mether | i dont know but i see the list of packages with EVR issues growing | |
| warren | nirik, as we improve infrastructure and data reporting later we could more easily identify where maintainership accountability is failing. | |
| tibbs | Yes, 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. | ||
| nirik | mether: yeah, thats likely due to bodhi... ;( | |
| bpepple | mether: 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 | |
| warren | bodhi doesn't enforce EVR? | |
| nirik | https://admin.fedoraproject.org/accounts/dump-group.cgi?group=cvsadmin&format=plain | |
| mether | warren: no and I think koji was supposed to have a RFE to prevent builds with such issues | |
| nirik | warren: 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... | |
| tibbs | warren: People aren't actually pushing their packages. | |
| warren | oh, 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. | ||
| warren | I'll write up a fedora-devel-announce "reminder" about this issue now. | |
| bpepple | warren: thanks. | |
| mether | nirik: why isnt Micheal Schwendt on that list? | |
| tibbs | Has he asked to be on that list? | |
| nirik | mether: I think he was asked and didn't want it. | |
| mether | ok. I thought he would have wanted it since he complained about ACL's preventing him | |
| warren | He 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 | ||
| tibbs | I recall addressing the idea that acls should be applied to new packages only upon request. | |
| warren | fortunately | |
| * nirik cheers. | ||
| tibbs | But I guess we left that for said automation. | |
| mether | tibbs, looks like we didnt agree on that at all | |
| warren | perhaps we could have a sub-level for CVS admin after pkgdb.... | |
| not quite full access, but the ability to change ACL's | ||
| nirik | perhaps 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? | ||
| nirik | mether: 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... | ||
| mether | nirik: just looking at the broken EVR list | |
| dgilmore | nirik: he has been offered it a couple of times and regected it | |
| warren | nirik, we had wanted to a few times in the past. | |
| mether | has anyone in FESCo | |
| looked at | ||
| http://andrewprice.me.uk/weblog/entry/to-sponsor-the-package-or-the-person | ||
| bpepple | mether: yeah, jeremy brought it up a few weeks back. | |
| mether | note that Debian seems to have a way to short circuit the long process | |
| see the comment in that blog | ||
| bpepple | we've talked about it briefly, but haven't really had much time to much beyond that. | |
| mether | there 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 | ||
| tibbs | I've been sponsoring many people, and the procedure is not that long or arduous, but I can only do so many. | |
| nirik | for EVR issues, can we update the docs to note that pushing FC6 before F7 is out will break EVR? | |
| mether | that would be a good idea and if we can fix the current issues that would be good too | |
| bpepple | nirik: I have no problem with that. go for it. | |
| mether | debian process - http://lwn.net/Articles/239231/ | |
| bpepple | ok, we're almost out of time. Any last items before calling it quits for today? | |
| mether | Fedora ACL issues - http://lwn.net/Articles/238284/ | |
| warren | when were these published? | |
| mether | couple of weeks before | |
| warren | Debian creating a lower level of developer | |
| tibbs | This is another "once we have packagedb" thing. | |
| warren | My developer rank proposal would have done something like this too. | |
| bpepple | tibbs: 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 | ||
| tibbs | I 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 | ||
| warren | tibbs, restricted meaning what? | |
| tibbs | restricted to modifying your own packages only. | |
| * warren focuses on writing mail | ||
| warren | bbl | |
| * bpepple will end the meeting in 15 | ||
| tibbs | BTW, 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!