Extras/SteeringCommittee/Meeting-20070301

= 2007 March 01 FESCo Meeting =

Present

 * Brian Pepple 	(bpepple)
 * Jason Tibbitts	(tibbs)
 * Christian Iseli	(ch4chris)
 * Josh Boyer		(jwb)
 * Rex Dieter  	(rdieter)
 * Toshio Kuratomi	(abadger1999)
 * Kevin Fenzi 		(nirik)
 * Dennis Gilmore	(dgilmore)
 * Bill Nottingham	(notting)
 * Jesse Keating	(f13)
 * Jeremy Katz		(jeremy)

Absent

 * Tom Callaway		(spot)
 * Warren Togami	(warren)

repo-creation using new createrepo

 * f13 is currently working on using the new createrepo in the development branch.
 * There is no plan to use the new createrepo in FC6.

Sponsor Nominations

 * Fernando Nasser was nominated and accepted as new sponsors.

Extras 7 preparation

 * the plan is not to do a mass rebuild.
 * nirik is going to setup a page on the wiki to track other preparation issues that we need to track for F7.

Packaging Committee Report

 * FESCo approved the Packaging Committee's guidelines regarding:
 * Initscripts proposal: http://fedoraproject.org/wiki/PackagingDrafts/InitScripts
 * Buildroot proposal: http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot

Log
--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process FESCo meeting ping -- abadger1999, awjb, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren urp Hi everybody; who's around? Just finishing lunch. here tibbs: same here. here c4chris is here thl is on the rabble seats nirik goes to grab some more coffee. XulChris hands thl his nachos and coke Ok, we'll start slowly as more people show up. I'm here, just running to the kitchen to get my lunch --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- extras repo-creation using new createrepo - skvidal I believe f13 said that they are planning to use this in the devel repo. Am I correct on this? bpepple: we tried, ran into a failure that is perhaps due to RHEL4 NFS code and creating the sqlite blob over NFS bpepple: but that is a very narrow case, we weren't able to dupe in many other scenarios, so it should be safe for Extras to do this ... depending on how the extras push is done, of course. f13: That's fine. I belive Seth was just looking to see if we planning on doing this. notting: I'm pretty sure it is done on local file system then rsynced around. it is I guess we can go to the sponsor nomination since warren isn't currently here. --- bpepple has changed the topic to: FESCO-Meeting -- sponsor nominations -- Fernando Nasser so is this going to happen for extras/devel? or extras/fc6 too? nirik: createrepo? yeah. nirik: should only be devel nirik: devel only, afaik nirik: devel yum is the only thing that benefits currently ok, just making sure. im here and we're not really planning on backporting to yum 3.0.x afaik So, I've no issues with fnasser. Ok, we should probably vote on making Fernando Nasser a sponsor. +1. +1 +1 +1 I don't know much about his work, but will go with warren's reccomendation, so +1 +1 fnasser has been doing a great job taking our guidelines and applying them to jpackage.org too +1 with f13's recommendation. Ok, Fernando is a sponsor. moving on.... --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- cvs-import changes Does anyone want to own this task? bpepple, remind me what the changes are? sorry, i missed the last two meetings and i'm trying to catch up I think we decided to modify cvs-import.sh to do several things... show a diff w/ conformation before committing, prompt for a commit message jwb: To provide a warning, a diff, and to add a comment. that's a simplified list btw. Anyone else interested? c4chris: consider it yours. thanks. k
 * jeremy is here
 * nirik is here.
 * bpepple doesn't see warren around.
 * rdieter shows up tardy, took too long getting the 2-year-old to take a nap.
 * jwb throws a +1 there too
 * rdieter notes fnasser is a real trooper, for trying to discuss rpm with jbj on rpm-devel ml too. (:
 * c4chris is on vacations 'til next week... if noone steps in 'til then, I'll take it.

ok, we can move on. --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Extras 7 preparation nirik: did you talk to mschwendt about this a bit this week on the mailing list? yeah, let me find the thread. what sorts of preparation are we talking about? I believe he had some concerns. notting: things like roadmap, broken deps, key packages (wxGTK2 issues solved?), rebuilds, FE7Target bug, mail to all package owners. so there should be no need for a mass rebuild. https://www.redhat.com/archives/fedora-devel-list/2007-February/msg01369.html f13: that I'd like broken deps resolved by Test4 starting around there. d'oh! stupid keyboard. I think that we should consider dropping packages with lonstanding broken deps from the distro. I worked on bugging maintainers for packages with broken deps this weekend. tibbs: I'm thinking the same thing. what about the issue with the freezes? unilaterally orphan packages with broken deps? A lot of them are fixed now. And we need to come up with a plan for dealing with the broken upgrade paths as well. jwb: the Freeze for test2 worked fairly well. tibbs: "fix them by Test4" (: Aren't there still core packages with bad update paths? csound, and paraview I know are still broken. I think almost all the others are fixed, but I haven't run repoclosure. f13, i meant the fact that rawhide and extras progress, but could be divergent once released... f13, since there's no "needsign" repo for rawhide jwb: that will be 'fixed' once we merge Also, we should consider asking mschwendt to turn the mandatory daily report back on. tibbs: +1 tibbs: if there are, they should be fixed. notting, yes. but it could cause more of these other things to happen so if we are not doing mass rebuild, we will ship some packages that are .fc6 in f7? like broken deps nirik: sure I'd like to have less and less different treatement for core/extras.  Rules about things to be fixed should just be unilateral. nirik: yep, happens all the time. nirik: i'm unconvinced that 'make everyone rebuild' is the proper way to find inactive maintainers agreed. packagedb, save us! is there an ETA on the packagedb? bpepple: "soon" (: bpepple: somewhat dependent upon koji as the two will interact re 'inactivemembers': We'll be doing password rotation with the new account system.  People will expire. f13: that makes sense. Do we have any of this written in the wiki? ie, all deps must be fixed by test4, all broken upgrade paths must be fixed by test4, etc? nirik: nope, care to add it to somewhere? nirik: I don't think so.  Where on the wiki should we put it? sure, if someone could tell me where... I have no idea. ;) Somewhere under Policy, I'd suppose. We probably need a page that chronologs what each stage of a release needs f13: +1 Policy/DevelopmentProcess or something like that. yeah, part of the roadmap for f7? nirik: more a generic roadmap ok, another issue is orphans... when do we cull them? and do we cull from devel only, or all branches? nirik: Do you want to start on setting up that page? nirik: I would think devel only. Sure, shall I try and write up one under my space, we can review it next week and move it in somewhere offical? nirik, sounds good. if you want someone to review it, ping me nirik: that sounds fine. nirik: packages once shipped should not be removed. ok. will do. they can be removed from the next release yea, remove from devel only ok, the downside is then that fedora-orphan or whatever gets the bug reports which never get an answer. you can watch extras-orphan in bz yeah yeah, but does anyone do that? who's doing that? We should gate extras-orphan to some real people. but that probably needs gating through the account system as well, for cvs commits, etc. jwb: I think mschwendt does a bit. jwb: i get it, i don't really pay attention to it it would be nice to have some way to tell end users "hey, not supported anymore, would you like to come and maintain it?" jwb: mschwendt does most of the answering mschwent said he stopped, it was too much. i'll watch it for a while at least I thought he said that somewhere. nirik: I think your right. nirik, i think he said he's going to stop doing the orphan report Surely bugzilla could be hacked to just present a message, or some automated process could come by and drop a comment in each ticket. tibbs: yeah, thats what I was getting at... if possible that would be better than making humans have to deal with it. it looks bad to have stuff in maintained releases that are 'sorry, no one is dealing with that', though bad pr, etc. nod somebody should be watching especially for security stuff. notting: agreed. maybe this is something for the QA team? we're diverging a bit from the topic maybe "This package is no longer actively mantained. Security updates will still be issued, but no other updates.  If you wish to take over this package, see blah..." notting: yeah, but it also looks bad when their report is in NEW for ages with no response we do that for maintained stuff! nirik: +1. IMHO, looks worse to be unresponded to than to hae a definite answer. sadly true. ;( notting: *shrug* Ok, we should probably move on. I don't see warren, so we should skip talking about Tracker Bugs this week. --- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop Anything to report from the Packaging commitee? I don't see that spot is here. I can give some update although I don't have good notes in front of me :/ f13: that's fine/ We approved the init sript draft spot was in ohio yesterday http://fedoraproject.org/wiki/PackagingDrafts/InitScripts f13: a big +1 from me for the init script proposal This has caused some discussion on the lists, but it doesn't seem to be going anywhere. +1 from me. +1 here also. +1, if we're voting +1 from me, but I'm on the PC. +1 one sec +1 the only thing I'm not sure if I'm comfortable with is the "migrate by this date" THere was a buildroot change too again, let me find it. but that's far enough away that it could change again before then :-) jeremy: I wasn't too comfortable with that either. I think that belongs more in a Release Feature rather than in guidelines. f13, right http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot otherwise +1 from me on the initscript deal http://fedoraproject.org/wiki/PackagingDrafts/BuildRoot f13: exactly ah, tibbs beat me too it. +a lot from me on buildroot. The new buildroot guideline is significantly easier to comply with than the old one. wait hang on so there are bacically 3 acceptable buildroots? big +1 to the new buildroot guideline -1 on the buildroot. wait.... +1 there are 3 preferred ones... bpepple: there are any number of acceptable buildroots, there are 3 suggested ones. nirik: ah, ok. bpepple: Those are examples.  I was unhappy with the wording there. -1 from me jwb: what did you ant us to wait on? i'm trying to figure out if we just approved the initscripts thing or not oh sorry. jwb: we approved it or if the changes that were suggested by you and jeremy would get rolled in jwb: no changes just yet. jwb: I'll try to work with lutter (who wanted me to add that text) to get it cleaned up. do we have to go back and ratify those changes? that seems like a pain in the ass jwb: mostl ikely not jwb: I don't think so. It's a pretty minor point. k i'll trust you f13 ;) So where do you want to put that text? ok, proceed. sorry, just wanted to clarify ok, back to buildroot.... tibbs, the suggestion was in a release schedule nirik: basiclly i see it as axel being pushy.  his one objection i see as valid is building 2 arches on one box at once.   i say to resolve that add %{arch} in the build root we already approved and use that Do we actually have a release schedule? tibbs: It would be a Release/Feature tibbs: for whichever release we want to target that cleanup for dgilmore: +1.  Either that or use the mktemp format. dgilmore: it was more than just axel... (unfortunately). rdieter: well he was loudest I'm tired of otherwise good packages getting blocked by this... does it really matter? why? look, the buildroot is so incredibly silly.  The buildsystem will override it anyway so we don't really care local folks can override it with an rpm macro right Things can break for local packagers so it's a regression. I _really_ don't want to spend time on this. If it follows a few simple guidelines, GOOD ENOUGH. f13++ The primary issue is that it's there for folks building locally, but they can override it easily. f13: +1 The thing that racor is right about is that leaving off the %(%{__id_u} -n) allows you to break other peoples local builds. abadger1999: I really don't care. should we really care about people building locally? don't they have other issues like not having our min build set of packages, etc? Whereas leaving off anything else (even name-ver-rel) can be cleaned up by the person doing the packaging. there are any number of ways you can shoot yourself in teh foot with local building. abadger1999: I can _STILL_ break your build if I want to f13: fine right. and "joe user" probably needs to learn the hard way if he's really going to do local building and really, we suggest people use mock, where this isn't an issue. jeremy: Can you do it through negligence or do you have to work at it? :-) abadger1999: you can't remove another users buildroot notting: Exactly. abadger1999: all I have to do is change the buildroot line in something I want to build That's the point. abadger1999: it's absolutely trivial abadger1999: so, you can override it with the macro on the commandline Or in .rpmmacros, I think. yep But it is something that just works with "id" whereas now you have to work around the brokenness. Which means that you can and should set it to what you prefer and never care about what the package itself specifies. its just waaaay to silly to spend any more time on this trivial thing which has NO bearing on how we build our packages for the distribution. so, if we reject this again, it's just going to result in many more weeks of wasted rangling? so fine let them have there three lets move on But I was in the minority in the PC. And I can be the minority here as well. nirik: !! Ok, before we drag this on forever, where are we on the packaging committee's draft? Like everyone else, I'm truly tired of this :-) +1 abadger1999: agreed. +1 +1 +1 0 +1 approve. 0 (as I was on the PC vote) -1 :-) +1 +1 -1 still but looks approved to me maybe it'll motivate axel to not break things with his repo ok, I count 7 +1's, one 0, and two -1. I consider this approved. ok, can we never bring this up again? Please? f13: I'm all for that. seconded. f13: board action item! :) f13: sure aye can we move on to something more meaningfull? :) Ok, anything else from the packaging committee? nirik: ok. tabs vs. spaces in spec files. bpepple: that's it (I think). I can't recall anything else. rdieter: great, let's move on/ --- bpepple has changed the topic to: FESCO-Meeting -- EPEL anything to report on from the EPEL sig? bpepple, not much afaics bpepple: we have bugzill aand owners.epel.list sync up bpepple, we had a meeting and talked a bit looks like some good discussion on the list, and we had a meeting and will have another this weekend. and I didn#t finish the summary yet sounds good. bpepple: i want to push out whats currently built this weekend as a testing repo an epel question notting: ill need your help on that dgilmore: yay! notting: sure if we want to build a package for epel that depends on a package in core that's not in RHEL, do we need to wait on the core merge review? :) notting, I'd say yes notting: no but we will need to move it to our cvs all packages in the repo should be reviewed I'd like to see all epel packages come from reviewed packages. ok. note to self: bribe reviewer nirik, +1 notting: that's the spirit! notting: add me to the cc list I'd be happy to look too. notting: i need to setup a sync for epel same as for extras anything else, otherwise we can move on. --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora dgilmore: later. I have an item... per discussions with mschewnt on the list, I made a sponsor responsabilities shell... I just posted to the fedora-extras-list asking for comments to shut that list down now http://www.fedoraproject.org/wiki/Extras/Schedule/SponsorResponsibilityPolicy what is the FESCo opinion regarding closing the list now? I would appreciate comments/changes before it's ready to really vote on or the like. thl: I'm fine with closing it. I see no reason to keep the list around. kill it dead die die die. my only concern is what to do with extras users for fc5/fc6 -> fedora-list? nirik: I'll give it a look this weekend. notting, yes gah. really? notting, fedora-extras-list was never for really users iirc thanks bpepple, perhaps we could push the maintainer responsabilities at the same time. f13, me either nirik: yeah, I've been dragging my feet long enough on that. did the mailing list reorg get stalled? fedora-list is already filled with extras questions. And livna and atrpms questions too. nirik, waiting for hardware if we are shutting down extras, perhaps we could wait and do it at the same time as all the other changes? so for now it is stalled nirik, well, I would have prefered that, twoo is there an eta? too nirik, for the hardware: mid april afaik and then it will take some more time to sort the details out so I'd say that takes to long kill f-e-li now ah, bummer. I'd be ok with shutting down fedora-extras now... should have a last post that points user questions at fedora-users and devel to fedora-devel? mmcgrath: thl: you have a plan/rfresources/etc for this list thing on the wiki somewhere? While doing merge reviews, we've seen some packages that Red Hat is essentially forking. tibbs: details? notting, only what got discusses months ago Is this a cause for any real concern. thl: ah, ok. afaik, mmcgrath was doing all the internal followup on that notting, nothing about concrete plans; I'll chat with mmcgrath about it another time; maybe we can put something into the wiki then rdieter: for example, the nc package carries 17 patches that are twice as large as the upstream source. tibbs: ipv6? It doesn't support ipc6. notting, I know that mmcgrath is doing the work, but yes, I should poke mmcgrath more often to get a status update ;-) tibbs: also sysklogd is a redhat version... sysklogd-rh... upstream is dead tho, so...  also mc was "attacked" from the upstream for modifying default behaviour tibbs: isn't upstream nc very very dead? Not that I know of. in cases of dead upstream, perhaps maintainer could ressurect at hosted.fedoraproject.org The point is, there are instances of this around and we should decide what needs to happen. If we're going to keep with the core value of keeping close to upstream whenever possible, there will be conflicts. rdieter: i think that's overkill. not every maintainer wants to become the upstream just because they're packaging it tibbs: it only looks like the nc package applies 9 patches. none of which are large imo, maintainer should work with upstream, and if not, give *very* convincing arguments to justify. thl: I agree. I didn't see any '-1'. though we should probably have a vote for clarification. jeremy: nc itself isn't large. bpepple, we should also wait for the discussion on the list before we move on is upstream for nc openbsd? And there are 17 patches in CVS; I guess some need to be nuked. notting: I said 'perhaps', it would be nice to give back to oss community, if possible. thl: agreed. bpepple, I just wanted a ACK from FESCo for the direction, and I got that; that's enough (for now) notting: Current guidelines are that if upstream is dead you have to be prepared to act out the role of upstream. cu I mean, if nobody has any problems with just keeping forks of packages in an SRPM then OK, but it sure sounds like that's against the goals of the project. tibbs: it is against project goals, and be strongly discouraged (I won't say forbidden). Last commit to upstream nc was nine days ago, BTW. Doesn't seem dead to me. so upstream doesn't want any of those patches? of course, depends on your definition of "fork". nirik: it's openbsd. i expect them to be hostile. ;) nirik: Well, that's the question. I can't tell from the srpm whether anyone ever tried to send them. I mean, see fedora/rh's libtool, for example. (: technically anything with a patch applied is a "fork" yeah, at least an effort should be made.... notting: From http://www.fedoraproject.org/wiki/Extras/OrphanedPackages   "Several reasons can also led to a package being retired: package has no upstream maintenance and has release critical bugs package's [or]  upstream no longer exists" In the case of nc, it would probably be smarter to switch to one of the other variants. But this isn't the only package that is just accumulating patches that nobody wants to rebase. I know spot was pushing the perl patches we were carrying upstream... which is great. "If you really want to maintain a retired package, then the process is much the same as claiming an orphaned package. However, you need to be aware that fixing release critical bugs etc becomes your responsibility." abadger1999: *that's* fine. i just considering 'becoming upstream' to be announcing a project, hosting SCM, etc.... tibbs: right, like sysklogd... hopefully it will get replaced by syslog-ng... but we need to keep carrying it until it does I fear. I think that trying to get too caught up on this is kind of a doomed discussion notting: k. jeremy: +1 tibbs: i'd suggest asking the maintainer if they've considered moving to the more active upstream yeah... perhaps more suited to mailing list? or will that generate too much flame? tibbs: oddly, in the nc case, most of the patches are user-contributed via bugzilla  looks like my other connection went boink... buildroot! (that should do it) (... having maintained a package that's got substantial amounts of changes from upstream) The point is that since we do have project goals, we should at least document the places where we deviate from them by necessity and indicate what we intend to do about those deviations. tibbs: +1. Some of these packages are simply ancient. Things were different back then. tibbs: indeed abadger1999: along those lines, time to WORKSFORME some bugs on packages of mine ;) buildroot, buildroot, buildroot! It's not working. Forking is valid but we should document why it is being done. have we talked about koji yet? jwb: No.  And dgilmore had to leave :-( damn f13 is also involved, though. yes, but i already know what f13 will say Does anyone know what's supposed to happen to new core packages that have passed review? jwb: do you want an item on next weeks schedule about koji? tibbs: bug closed when rebuilt into rawhide? cdrkit ended up getting imported into extras, and it was a core package. tibbs: new packages -> extras "it was supposed to be a core package" bpepple, couldn't hurt. i'd like to know where we stand on switching to it So now we have a package in extras that obsoletes packages in core. tibbs: That makes more sense to me. (Import into Extras) why does this matter? jwb: I'll add an item for next week on that. tibbs: and? bpepple, thanks tibbs: that's ok. if cdrkit is built, f13 needs to do brew-voodoo And, that was always completely against the rules and nobody's rewritten the rules yet. tibbs: the package it obsoletes should probably be bounced from Core, and it needs to obsolete the package from previous COres tibbs: there is a chicken/egg problem. tibbs: new package has to exist before old package can get nuked and nobody has sent me the mail to nuke the old package that cdrkit replaces. Ok, we should probably start to wrap-up the meeting. cdrkit is in the extras needsign queue; Harald built it eight hours ago. tibbs: we can probably have this pulled then. cdrkit is the cdrecord fork? Essentially, yes. k pulled? why pulled? f13: sorry, was it a different conversation and didn't follow this thread fully. ok. I think that's about it... so if no one objects lets call it quits for this week. thanks bpepple  bpepple, fine with me thanks everyone bpepple will end the meeting in 15 -- MARK -- Meeting End
 * notting sees abadger1999, rdieter, tibbs on the channel
 * bpepple shudders at the thought of talk of buildroot.
 * jwb sighs
 * nirik waits to hear why abadger1999 and dgilmore don't like it.
 * STOP *****
 * bpepple agrees with f13.
 * rdieter covers ears, wishing never to hear about buildroots ever... ever again. stop the madness.
 * dgilmore has to go in 3 minutes
 * jwb ducks
 * f13 stabs notting
 * thl hasn#t anything else regarding epel
 * dgilmore has to go. catch you all latter
 * f13 isn't going to read fedora-list
 * notting points thl and mmcgrath at each other :)
 * thl will wait for further comments regarding closing f-e-l on the list;
 * thl interprets this FESCo discussion as agreement to close the list soon
 * thl makes room on the rabble seats
 * jwb glares at rdieter
 * bpepple will end the meeting in 60
 * bpepple will end the meeting in 30
 * nirik wishes we were able to get to the removing blocker bugs thing... oh well.