Extras/SteeringCommittee/Meeting-20070315

= 2007 March 15 FESCo Meeting =

Present

 * Brian Pepple 	(bpepple)
 * Jason Tibbitts	(tibbs)
 * Christian Iseli	(ch4chris)
 * Rex Dieter  	(rdieter)
 * Toshio Kuratomi	(abadger1999)
 * Kevin Fenzi 		(nirik)
 * Dennis Gilmore	(dgilmore)
 * Jesse Keating	(f13)
 * Warren Togami	(warren)
 * Tom Callaway		(spot)
 * Josh Boyer		(jwb)
 * Bill Nottingham	(notting)

Absent

 * Jeremy Katz		(jeremy)

Core Review Process

 * The Merge Review is only a cleanup sweep, and the cleanup changes need to end at Test4. The merge will happens whether or not they are approved in a Merge Review. The cleanup will continue after F7.

Packaging Committee Report

 * FESCo approved the Packaging Committee's guidelines regarding:
 * http://fedoraproject.org/wiki/PackagingDraft/ScriptletsWriteDirs
 * http://fedoraproject.org/wiki/PackagingDrafts/BuildRootHandling

Log
--- bpepple has changed the topic to: /topic FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process i'm here I'm here as well. FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren I'm here. i'm here here howdy nirik is here. hi everybody. Let's start slowly and see if the other show up. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Extras 7 preparation nirik: have you had a chance to add anything on the wiki for this? I haven't... :( There was a post on someone who setup a tasktracker type thing with all the info on it... is that what we were looking for? I guess we need to talk about the PPC64 builds as well. https://poelcat.108.redhat.com/nonav/fedora/schedules/fc7/fc7-sched.png nirik, personally, i don't think so nirik, that is going to get out of date too quickly to really be of use unless someone is policing it full time nirik: I'm not really sure, I haven't had time to look a it. bpepple: so im going to add ppc64 to the extras buildsys yeah, I got sick and swamped at work and haven't had much time to look at it... what were we looking for here? Milestones for a regular development release? nirik: something like that. mmcgrath, project management means you have control over things. he doesn't.  he'd more likely just be doing project tracking dgilmore: do you think it is possible to rebuild what has already been built to pick up the ppc64 package, or will there have to be a mass rebuild? poelcat did say "I am willing to be that person." s/management/coordination/ f13: its possible to build same versions for everything that does build f13: there is some cicular deps in there i'd like to avoid a mass rebuild if we can circular yeah, I guess the important part is for people to all know when things have to be done... like all broken deps must be fixed, etc. yeah, I don't like the idea of having one arches packages built with potentially different things in the buildroot than the rest of the package though. nirik: right, I think that's what we're looking for. jwb: we may have to :/ so hopefully its just a minor rebuild f13, dgilmore: can we just have a small committee to it? rather than have all the developers dgilmore: no mass rebuilds are 'minor' :/ bpepple: yeah, I can look more this weekend now that I am feeling better... nirik: I should have some time this weekend to help also. cool. jwb: should be able to, would probably need to enforce some sort of outage so that random maintainer doesn't step on the rebuilder's toes. jwb: a good project manager does not "control things" are we going to do bump + rebuild? or just rebuild on the side? f13: its minor in that somethings (hopefully most) wont need any attention at all notting: unless you have a better idea (: I'm willing to work on getting things to build if we can work around the ACLs . poelcat, you would be the first i've experienced to not do that :) do we have a dep-sorted list? poelcat, and my statement wasn't meant to be insulting. sorry if you took it as so I suspect anything that excludes ppc or x86_64 will need to exclude ppc64 as well. tibbs: probably just ppc dgilmore: mattd's extras rebuild list should prove as a data point ofr what will fail. notting: 64 bit issues? notting: i think what ill do is create a target just for this build what we have currently when thats done merge it in and fix and rebuild the rest f13: i dobut it will help much tibbs: hard to tell whether it's 64-bit issues or !x86_64 issues notting: we dont have that list yet dgilmore: it'll tell us what things are currently not going to rebuild cleanly jwb: np; a good project manager tracks and coordinates keeps info current so people can make good decisions; maybe a better term would be program manager dgilmore: since what is _in_ the buildroot now has changed from when a lot of the Extras packages were built. f13: sure it will be a guide dgilmore: probably need that to avoid doing things twice so, a mass rebuild, a new build system, and merged scm. Oh and a freeze next week. Heeee! anything noarch wont need building notting: yeah ok, anything else in regard to the ppc64? bpepple: not really so dgilmore is going to rebuild it all for now? needs more planning jwb: w/ taskjuggler keeping that schedule current would not be that hard and I might be able to get company time to do it poelcat, if you'd like to do that, go for it. i have no objections. jwb: needs more planning but probably for a large part part ill look after it ok, we can probably move on then. dgilmore, if you need help ping me and/or dwmw2. we can look into some of the build issues --- bpepple has changed the topic to: FESCO-Meeting -- Core Package Review Process -- warren warren: Is there anything else we need to discuss regarding the merge? warren: are you still alive? f13, not sure if I'm alive IRC from the beyond.... bpepple, the review process is almost irrelevant now meaning... Merge Review is only a cleanup sweep. The cleanup changes need to end at Test4. Merge happens whether or not they are approved in a Merge Review. Cleanup continues after F7. warren: ok, I note that in my summary. I'll make a big announcement on this point specifically today. when is the merging then? soon rdieter, merge doesn't block on reviews, but rather infrastructure and policies being ready. rdieter: once koji goes live, which might be right after Test3 well, koji going live and merging are sort of both at the same time kind of thing we should keep being able to do reviews now tho right? don't tell people to stop? correct warren: btw, should we keep this item on the schedule? Or do you want it removed? might? ok, I can wait for details, but I'd really like to be able to get to work on kde packages. and technically they can continue after Test4, but no changes from the review will be built after TEst4 bpepple, wouldn't hurt to keep it there. f13, do we have koji test systems up? warren: ok. rdieter: If I knew exactly when Koji would be ready, I could give you a time. jwb: yes. nirik, right, reviews keep going until a deadline. jwb: http://koji.fedoraproject.org f13, need testers? jwb: not atm, we're able to find enough problems with just me and mikeb and dgilmore f13, koji auth allows cert (not just kerberos) now? jwb: we will soon. warren: that isn't complete yet. ah warren: currently we're testing with username/pass since htat was already in koji f13, ok. i think we can find a few folks to help test when needed. ping me jwb: will do. rdieter: there is a question about whether or not to allow package changes for deps in Extras after koji goes live, unless we move the feature freeze once again. rdieter: since I don't believe koji+merge can happen in the next week since the freeze is a week from today rdieter: see the thread on maintainers-list f13: sounds like a chicken-n-egg problem for kde-spin. if we can't make mods until merged... rdieter: I know. It really sucks. btw, while on the review topic: Mike has now setup a review status page on fp.o: http://fedoraproject.org/PackageReviewStatus please provide input on maintainers-list Ok, unless there is anything else, we can probably move on.... nirik, did you get the canned queries done? --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- cvs-import changes - c4chris I have some queries that work, but not sure how to make them 'canned'... off my wiki page are links: http://www.fedoraproject.org/wiki/KevinFenzi no progress on cvs-import... yet... nirik, k c4chris: No problem. --- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs we have "touched" about 21% of the core merge reviews. Everyone saw the summary sent to fedora-maintainers, I take it. tibbs: yes. tibbs, yes So there are two issues up for FESCO discussion: tibbs, yes thanks http://fedoraproject.org/wiki/PackagingDraft/ScriptletsWriteDirs This defines when the various phases of an rpm build can touch the various directories like the build root. Basically, the buildroot shouldn't be written to during prep, build or check. seems reasonable. Does rpmlint warn about any of those? can it be made to? It warns about "buildroot-usage" in some cases. side question: do we ever audit existing packages for adherence to these guidelines? ok, seems fine to me. +1 jwb: not officially. jwb: There's the whole merge review, of course. tibbs, i mean existing already reviewed packages. Other than that, we haven't but perhaps in the future we could consider it. ok jwb: in some far distant time we might have manpower to do checks on existing packages... or flag them for review if they have problems, etc... jwb: No. There's just so much to review right now. yes, i know tibbs: +1 its ok with me +1 BTW, the rpmlint complaint is "rpm-buildroot-usage": +1 $RPM_BUILD_ROOT should not be touched during %build or %prep stage, as it will break short circuiting. +1 +1 here also. speaking of which, i have a volunteer willing to write a reviewing-for-dummies to train an army to do the 'easy' part of reviews +1 +1 notting, that would be excellent OK, if anyone has further comments on that proposal, please let fedora-maintainers kjnow before next Tuesday. notting, who? notting, sounds cool :-) The other proposal: Disallowing %config files under /usr: http://fedoraproject.org/wiki/PackagingDrafts/UsrConfigs +1 from me +1 wait... that was already ratified wasn't it? do we have an idea if anything is going to break? nirik: I think you're remembering initscripts will not be %config +1 tibbs: that was already ratified i think i ask because this seems like a guideline that wouldn't have been made without somebody already using %config in /usr... Crap, I'm pasting from the wrong section. the other item should have been: PackagingDrafts/BuildRootHandling http://fedoraproject.org/wiki/PackagingDrafts/BuildRootHandling Is the real proposal. My fault. argh buildroot again ? Yes, and there's more to come. c4chris: just that you need to nuke it at the beginning of %install (for now) BuildRootHandling +1 from me. +1 spot, oh, I thought that was already the case This has been the de-facto thing to do for a long time now. +1 here also. +1 +1 But it's not in the guidelines, just in rpmlint. *crickets* tibbs: anything else? Nope, that's it. Again, please send any comments to fedora-maintainers. tibbs: great, thanks. moving on.... --- bpepple has changed the topic to: FESCO-meeting -- MISC -- garbage-collector rpm I left this on the schedule, though I think this probably needs to be discussed on the mailing lists. I don't think there has been any good flashes of brillance on that so far... Has notting or jeremy chimed in an opinion on that? warren: jeremy is on vacation. warren: bad idea. have a repo-upgrade plugin that warns you of dead things notting, yea, I'd like that much better repo-upgrade plugin could know about specific E-N-V-R instead of having huge lists that slow down transactions and never die? it would be nice to have some way to inform end users: "hey, this thing is orphaned, and not supported, use at your own risk"... but I have no idea how to do that cleanly. Is the goal of garbage-collector for updates within a regular distro or upgrades between distros? between IIRC the fear is that an orphaned package will lead to broken deps a repo-upgrade plugin could also handle "backwards" N-V-R cases in rawhide. repo-upgrade plugin would be disabled by default, except rawhide and one-time "between" upgrade users could use it at their own risk? That way long lists of Obsoletes don't pollute regular fedora users, slowing things down warren, sounds fine possibly... will be interesting to see how fc6->fc7 yum upgrades work. fc5->fc6 was very painless... "a repo-upgrade plugin could also handle "backwards" N-V-R cases in rawhide." makes an entire class of testers more happy, while giving us more flexibility in rawhide. how would it know that a N-V-R went backwards? nirik, repo-upgrade plugin could have a list of specific N-V-R's that were bad and should lose to whatever is newest in the repo. Not exactly sure, might be a bad idea. seems like that could be both a maint nightmare to keep up to date, and something that would make people think it's ok to do that kind of thing all the time in rawhide. ;( bottom line here I think a garbage collection package is a bad idea. nirik: davej posted that fc6->f7 would cause issues. Vote to remove this from schedule as a bad idea? Have to be careful with the new kernel+mkinitrd. abadger1999: that was more for kernel changes than package oopses. abadger1999, he posted that yes. it didn't though f13: +1 abadger1999: when? with the s/hda/sda/ ? f13: +1 f13: +1 f13: +1 abadger1999, it's highly dependent on the hw too +1 to myself. f13: +1 +1 +1 jwb: Ah.  k. garbage collection isn't for normal users. Ok, I'll remove it from the schedule. warren: fedora sanitation engineers? I think the idea has mostly bad implementations possible, but it has merit, just don't know exactly how. +1 to remove it from the schedule for now ok, let's move on... --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora Anything people want to discuss? doom will the meeting stay at 5 UTC? (just curious) c4chris: you mean '1PM US eastern, whatever that converts to?' should we start expecting some more review response from redhat folks now that RHEL5 is out the door? i hope so notting, yea, I think I mean that (and I hate DST)... c4chris: I'm for leaving our meeting at the regular time, once we sync back up with europe. bpepple, and that's 1PM US eastern I take it ? c4chris: correct. k the time we just met in, leave it at that for how long? until most people can't make it and we have to switch? The 1PM eastern seem to work for most people doesn't it? or someone yells loud enough :-) c4chris: agreed. Works for me. lets get this straight. warren: were you going to get someone to mass change the blocker bugs over to flags? or did we decide to not do that? We just had a meeting, and the time which started this meeting will not change for the forseeable future? f13, yes f13: correct. right except when US does DST, and then we adjust accordingly? 17:00 UTC. f13, it's always at 13:00 EST f13, yes, we shhot for 1PM US Eastern shoot jwb: er.. EST vs EDT? aren't timezones fun?  (: E.T 13:00 in the state f13 presently resides in argh heh abadger1999, right c4chris, me too 1700UTC for now, 1800UTC during US Daylight Savings. right but we are in US daylight savings time now. ;) ok, everyone on the same page? http://www.worldtimezone.com/index24.php http://www.worldtimezone.com/daylight.html btw, if it moves to any other time, i'd likely be screwed. i have trouble making it at this time some weeks Anything else people want to discuss? FYI -- I finished the initial front end to the package db last night otherwise we can start to wrap things up. abadger1999: cool. https://admin.fedoraproject.org/pkgdb/ wrap++ abadger1999, cool bpepple will end the meeting in 30 bpepple will end the meeting in 15 well there are some need to do items for koji still -- MARK -- Meeting End see http://fedoraproject.org/wiki/Infrastructure/KojiBuildSystem basically some questions around rollout. nirik, the plan is still to change it f13, what's the runroot thing? warren: cool. is there going to be any koji/packagedb interaction? or do they have seperate db's for the info that overlaps? f13, can the fakeroot package help ? nirik: Separate db's for F7. c4chris: runroot is the ability to go like "koji runroot --packages="pungi" dist-fc7 "/usr/bin/pungi -c /etc/pungi.conf" We want to merge things by F8 but there's not enough time to get them both running and get them integrated between now and F7. c4chris: it would take the packages, toss them into the mock chroot along with the buildsys-build group, and run the given command. c4chris: basically a way to get to mock -r chroot "command" c4chris: it would run the command on all the arches that exists for dist-fc7 c4chris: but this is a low priority, usually the only thing that needs this is the compose tool and I can do manual chroots for now. I think we'll be able to merge the databases relatively easily at that time. What we do with the UI is a little more open in my mind. f13, k Maybe we'll split the UI to have a developer section which allows editing of packagedb information and interacting with the buildsystem and an enduser site that focuses on read-only views of the packages. abadger1999: not a bad idea. Maybe it'll all be integrated. Not really sure yet. even end-user doesn't have to be read-only... could add ratings, comments, quick file bugs against package, etc. ;) love it / hate it would be pretty nice nirik: Good ideas. Add them to http://fedoraproject.org/wiki/Infrastructure/PackageDatabase  ;-) nice chatting with you :-) Later folks abadger1999: ok. c4chris: later. f13: I need to get a hosted account for the packagedb sometime soon -- I'm still using bazaar but I have a feeling I'm going to start tracking bugs :-) c4chris: see ya.
 * cweyl takes a rabble seat
 * dgilmore is here
 * mmcgrath notes poelcat may be willing to do that. He's expressed interest in project management.
 * c4chris will be here in a few minutes...
 * c4chris is here now
 * spot is here, a little late
 * rdieter nods.
 * notting doesn't see a problem, as long as the rebuilds get done soon
 * jwb obviously missed last week's meeting
 * c4chris doesn' like it too much. I like my mess to stay where I left it...
 * c4chris needs to kick something
 * bpepple will end the meeting in 60