Extras/SteeringCommittee/Meeting-20070322

= 2007 March 22 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)
 * Jeremy Katz		(jeremy)

Absent

 * Bill Nottingham	(notting)

Core Review Process

 * Discussed making the Core Review a blocker for F8.

Package Database

 * abadger1999 is close to finishing the PackageDB.

Broken Upgrade Paths

 * Solutions for dealing with broken upgrade paths was discussed. One solution might be to have the QA team monitor this.

Packaging Committee Report

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

Misc

 * Will move the Packaging Committee report to the beginning of FESCo meetings, so that people interested in this don't need to sit through the whole meeting to get to this item.
 * Discussed whether Ruby Gems should be allowed in Fedora. More information is needed before a decision can be made.

Log
--- bpepple has changed the topic to: /topic FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process /topic /topic? making my head hurt... ;) I'm here FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren i'm here here I'm here. hey, jeremy. welcome back. here bpepple: thanks here --- bpepple has changed the topic to: FESCO-Meeting -- Core Package Review Process -- warren warren: anything we need to discuss this week? crickets ? I think we settled on this It isn't a blocker reviews are encouraged as part of the ongoing cleanup sweep but we have higher priorities elsewhere (like fedora infrastructure, personally) warren: ok. you mentioned that you wanted it kept on the agenda last week. we can move on... I guess remove it from the schedule Is there a chance that this can be a blocker for F8? I have a quick question: is F7 completely feature-frozen (including Extras) now - i.e. no way to get new packages into Fedora at all until F7 releases? wwoods: No. Extras is still open. wwoods, extras isn't frozen is there a scheduled time for that? does there need to be? tibbs: i would hope its a blocker for F8 depends if Extras packages end up on a spin I guess c4chris, repositories are remotely installable wwoods: I thought we were freezing extras around test4? c4chris, extras is essentially within every spin though I could be wrong on that. bpepple, wwoods: i recall the same jwb, I meant extras rpm ending up on the spinned CD/DVD but I think f13 takes snapshots or something... +1 to F8 blocker btw c4chris: agreed. jwb blames wwoods I'd like to see a review+ as a blocker for f8, but we can revisit it then I suppose. new packages can go in. new packages _won't_ end up on the "main" spins  why cant the "freeze" process become more of a "branch" process? i hope you're not talking about a cvs branch I think you need things frozen to do the branches  no just branch devel to F8 or whatever, then f8 becomes the frozen bit and then you can bring in updates from devel, no need to stop all submissions just because you want to make a spin XulChris: in some ways, the "freeze" process at test releases kind of _is_ a branch process  jeremy: a branch process that takes like 2 months... XulChris: you don't want to branch off f7 and f8 being devel too early because everyone just goes to working on the new devel branch XulChris: yeah, but you also would like to see people fixing bugs and cleaning things up rather than working on new devel with all their energy nirik: exactly additions to devel doesn't effect the spin ok, sounds like new packages are allowed anytime? shall we move along to the next topic? or is there some question still here? nirik: +1 to moving on. So, core package review process: blocker for F8, not a blocker for F7. Is that where we're at? tibbs, s/core// at that point, they're just packages tibbs: thats how i see it tibbs|h tibbs not a blocker for F7, Re: F8 maybe/prolly, but that's a decision we can make later. tibbs, but yes in general +1 tibbs: +1 from me, revisit if there is an issue down the road? we're talking about two different issues here warren, hm? rdieter: might be better to say we plan on it now, and if its not practical revisit it later? might make some folks more likely to deal with reviews? Extras is not frozen. We will have to freeze it sometime before F7 in order to stabilize the tree. The freeze wont be very long. warren, we're done with that last two freezes we "froze" Extras somewhat durin gthe core freeze pushes were limited and targetted. we've moved on from this topic next time around, I want to enforce teh freeze collection wide. I think there is a confusion.... two different types of freezes. sorry, but I am catching up, and have prudent input. Jesse is talking about freeze so the spin stabilizes. --- jwb has changed the topic to: FESCO-Meeting -- Freezes -- f13, warren Other people are confused about "feature freeze" right, they're related. but not exactly yes, we need a better plan for the F8 cycle I'm not keen on adding new packages after a certain point to the tree we're trying to prep for release. I have created the very rough draft of a roadmap for devel cycles: http://fedoraproject.org/wiki/KevinFenzi/RelaseRoadMap-DRAFT (which I just realized I misspelled. ; any and all input welcome.  f13: but what does it matter if the package is not part of a spin? jeremy, you mentioned there was a decision made regarding the extras freeze for F7? Would be nice to have this on the wiki where everyone knows what things mean and when things happen. so the test3 feature freeze only applies to core (small-c) features, and does not imply the refusal of all new packages XulChris: because you can enable the network durin ginstall and EVERY package is part of the spin. XulChris: also, the commuinty has asked for an Everything spin that has everything. wwoods, according to jeremy yesterday, the test3 feature freeze applies only to features in the spin.  oh man f13, why did we agree to an everything spin? =(  f13: what is it called? "Fedora Bloat"? f13: but people are going to want to be able to add new packages after the release -- so trying to limit them for a short period doesn't necessarily do much and the everything spin is still a little up in the air -- there are some logistical issues around it (ie, it takes a bloody ton of space) jeremy: unless we say no new packages for releases jeremy: nope it doesn't. I don't have a good answer here. why not say no new packages after test3 or whatever...? though i like and i think most people like that things get added jeremy: there will have to be an everything tree no matter what. nirik, because it's pointless dgilmore: that's a pretty unpopular position for a lot of people is there anything that strictly says we can't add new packages to 'updates'? I don't think "no new packages" is a good idea... jeremy: whether or not there will be isos associated with it is what is up in the air. abadger1999: I don't necessarily either. abadger1999: but new packages should be issued as updates. well, if we add after the * spin is made, and the package isn't on the * spin, won't that confuse people? jeremy: i agree. so we really cant do a everything release because a day after release its no longer everthing because a new contributor wants to submit a package that will work on the system that they're running which will often be the last stable release, not rawhide. nirik, we can't go ahead with "no new packages" for a ~2 month period. That would be horrible demoralizing to the project, especially since there was no warning and we don't have tools to support a freeze. we have to have a full tree somewhere. nirik: i think people will just have to live with that. warren: agreed. 2 months? yeah, that would be way too long... I was thinking much less time before a release. warren: don't think about this time, think about next time. the Everything iso is pain because there is no stable definition of Everything f13: i say the everything spin is net installable only and is the rpm tree f13, I don't think that is a valid argument. jwb: every package in fedora? everything-2007-03-22-11:20:00 jima, which changes on a daily basis (as of a particular date) jwb: regardless of whether or not there are isos, there has to be an everything tree of packages that each spin can 'enable' to gain access to packages not on that spin. nirik: sure. f13, we need a realistic way to deal with the CURRENT transitory state that wont piss off all of our contributors. just like there is a full "core" tree inthe release directory f13, yes the updates directory at times gains new packages. f13, the F8 cycle with new infrastructure will be different, we can deal with it differently. We shouldn't treat the current project as how we think it should be in the next cycle. warren: I'm not saying we should. warren: but our new tools aren't going to magically solve this without any thought or plan around it. or we're going to wind up here again in a few months putting it off a another release because we didn't plan for it. The plans will evolve along with the tools ok, so where are we for F7 then? we're also not going to solve it by going around in circles on irc, fwiw. jeremy: +1 jeremy: +1 we need both a short term plan for now, and a longer range better plan for f8 cycle... IMHO The longer range plan will evolve over time "time" with boundaries the way to resolution is someone working up a draft plan that can be discussed via mail (and potentially some here as well) and then ratified. trying to make plans during an hour long irc meeting means that we have far longer irc meetings and still don't have plans ;-) jeremy: +1 of course yes, which is why we moved on from this topic in the first place jeremy: agreed. yes "Everything" spin even without media is still up in the air warren: I think not. warren, no it's not it isn't? so, who wants to take ownership of drafting up a proposal? warren: we _have_ to have an everything tree for the spins to gain access to more packages than what is on the media I wrote up a draft for longer term... I can make something for short term too if people want warren: just like previously you could enable "extras" at install time. I nominate nirik. nirik: that'd be great thanks for volunteering :-) nirik, great nirik, thx nirik: sounds good. thanks. let's move on... --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Package Database - abadger1999 abadger1999: you wanted to talk about this. nirik: I'd love to read it. I think I have something else from you in my inbox, but -ETEST3 :/ the PackageDB is very close to finished. f13: yeah, thats the longer range "generic" cycle... it needs your feedback. I don't know how some of the things were handled in the past. The front end is done. nirik: I'll get that to you. I finished logging last night and half of notifications of changes. abadger1999: do you know what you will need from me backend wise? nirik: if you bounce it my way, I'll take a look too. dgilmore: An overview of scripts that cvsadmins use. And also any insight into the automated scripts that you have. jeremy / f13: ok. I will do a clean up cycle on it and add some things and then ping you guys again via email to look... abadger1999: :) ok they are eveolving but getting better  ill talk to you latter about the details dgilmore: Great :-)  how can a frontend be finished before a backend? XulChris: It's finished up to the database. XulChris: backend is making changes in cvs bugzilla etc But the info in the database isn't synced out to the cvs server or bugzilla. For poeple who'd like to play around easily, I created this page today: https://admin.fedoraproject.org/pkgdb-dev/test/orphans it's a listing of orphaned packages. You can choose one and go to town, making yourself the owner, assigning acls, etc. I'd people to try it out and tell me if they think we should go live with this soon. abadger1999: is there any chance of including license data in the db? (thl has already requested that it happens soon because it'll help with comaintainers and EPEL) spot: Sure -- what type? Just the rpm spec tag? spec tag initially  spot: id hope there is a chance of anything being added to the db i'd like to have it all link to a licenseDB that i need to build speaking of that... what license is the packagedb code under? requested is maybe a bit strong word -- I just asked for the status, as the PackageDB might make things a bit easier k abadger1999: GPL? abadger1999: thanks. abadger1999: anything else? jwb: Well, it's a contribution to Fedora so -- I license my work under GPL/LGPL but Fedora/Red Hat can release under another license if they want. abadger1999, cool. we need to login first I guess before making changes... bpepple: That's it. Play around and see what you think. abadger1999, hm, k abadger1999: greats. thanks. c4chris: Yep. Fedora Account System username/password should work. k moving on.... --- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb abadger1999: might add a "you are not logged in yet: Login" button? nirik: Will do. ok, so mschwendt brought up a good point recently in that we're being lax on fixing up some of the things we used to focus on like broken upgrade paths, etc I had notes about borken update paths in the roadmap draft: http://fedoraproject.org/wiki/KevinFenzi/RelaseRoadMap-DRAFT F6 -> F7 is going to explode for non-anaconda upgrades anyways orphans, broken dependencies, evr problems, and release target/blocker bugs should all be made clear/addressed. (not that we shouldn't clean up our messes, just pointing it out) spot, not necessarily but that isn't the point spot: why? pointy sticks? nirik: SATA changes nope. it works fine when I tried it with rawhide a while ago. spot, it depends on the hardware  damn, i sure hope anaconda works this time jwb: i know. but not the point if you have SATA on FC6 you had /dev/hd*. F7 will have /dev/sd* oh? some hardware still fails? :( I thought it was working for everything now. ;( bpepple, yes that's what i'm thinking as well spot: that should be handled pretty well on the migration jeremy: in anaconda or in yum? I upgraded my laptop with sata fc6_>rawhide a few weeks ago and it worked fine. (via yum) spot, either. i upgraded fc6 -> rawhide a week or so ago spot: for yum too. anaconda has _zero_ code for it, so .... :-) ok, awesome.  hmm wait i have dev/sd* on fc6 could we try to much off-topic? in any event we should get those items fixed. perhaps someone should be tasked to look into these items We should make hard deadlines. someone like a QA team? at least to make a "current broken items" summary page It got much better recently, and we know that at least a couple of the packages have real issues with other F7 packages. zope and plone, for instance. But at this point I don't understand why there are still core packages with broken upgrade paths. I poked all broken dependency maintainers a few weeks ago, that cleaned up a bunch of them. we need large hands in RH to fix the core packages boost, cups, dbus, systemtap who's going to be the big hair ape? s/hair/hairy jwb: eh, let me try. spot, k forward those to me, i'll give it a shot.http://fedoraproject.org/wiki/PackagingDrafts/cmake Oh, cups is an FC5 > FC6 problem. orphans we should remove from devel asap... they shouldn't be in the repo if they are orphaned. tibbs, still needs cleaning that was my other point this isn't just a "fix it for release" deal I'm thinking that any non-essential packages with broken upgrade paths need to go from the distro rather soon. some of the broken deps are really hard, and will probibly just need to remove those packages? I can clear orphans we need to actively work on getting them all fixed for all releases now and in the future nirik: document them? worst case, i can try to fix some of them. spot, they're all documented... jwb: where? :) spot, see the Package EVR problems email on -maintainers For zope and plone, for instance, they require python 2.4 and the maintainer would like to get authorization for a compat package. spot, it's a report that is generated on a regular basis jwb: no, i see that i'm thinking more "broken deps" csound blows up in a weird way. tibbs: I'm pretty against a python 2.4 compat package... because you're then going to need all sorts of modules for python 2.4 as well spot, ah, we have that too xmldiff blows up in a weird way only on the buildsys This might be related. I was asked yesterday, are there other top priority items that we need RH engineering to participate in that blocks Fedora 7? jwb: where is that? :) jeremy: Yes, but then we need zope and plone as well. So it's a rock><hard place issue. tibbs: has anyone tried to make zope/plone py2.5 happy? spot, "Summary- Broken dependencies in Fedora Extras" spot, missing core i suppose Yes, several people. It's not an easy problem. wwoods: Fixing broken deps and broken upgrade paths. broken deps: https://www.redhat.com/archives/fedora-devel-list/2007-March/msg01102.html ahh, ok -devel-list i'm a bit behind there. :/ evr: https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00694.html broken deps - I've been asking around about the automated mail stuff that goes out spot, you'd have to look at the rawhide reports for the core packages for now. should be fixed up to include everything after the merge same with the EVR problem mail wwoods, good to hear I'm trying to put together a dashboard page to merge all these things into one place wwoods, do you feel that's something that falls under your role as the QA lead to look after? The broken deps are much reduced... but some of them are not easy 'just rebuild' problems. along with automated installer results, recent packages in updates-testing / rawhide, etc jwb: definitely. I can't guarantee that I, personally, have time to track this stuff but it is my responsibility to find people and help make it happen I think it would be helpful to get the broken dep report daily, as well. Right now I think it's only generated if some new bustage appears. spot puts it near the top of his todo list wwoods, do we have a QA sig? jwb: we have an unofficial QA group k wwoods, don't be afraid to yell in various places if you need help with things like this not sure what a SIG would entail, but I'm all for it - especially if it gets me a group in the accounts system or somesuch mschwent also filed bugs for all the EVR ones recently. once the merger happens, we can use treediff and spamomatic to report on changes between rawhides and broken deps. f13, can we run that on releases too? I've been doing a lot of hand testing and discussing things internally, so I haven't been working on higher-level stuff like this jwb: yes, it'll be noisy but I gave it to mether last time to diff FC5 to FC6 f13, i meant inside of releases say package foo is updated in fc6 and it breaks deps bad example. f7 after it's release there is alot of focus on rawhide, but i want to see the same reports for released versions ok, we should probably move on before it gets to late. --- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop I can go thru the evr and broken deps again this weekend... but at some point we will need to decide to drop things, or go in and fix them ourselves. jwb: update tool from lmacken should help with that. jwb: depchecking before things are pushed as updates. tibbs: I believe we have the cmake proposal to vote on. jwb: did we mention, all "updates" to a released product must go through the tool? fyi, http://fedoraproject.org/wiki/PackagingDrafts/cmake Yes, sorry, doing too many things. tibbs|h tibbs It's just that one proposal today. tibbs: no worries. everyone get a chance to read it? Basically, we have packages now which build with cmake; this is a proposal for some macros and guidelines to standardize its use in specfiles. looks sane to me looks ok to me +1 +1 When/if it is ratified, I'll work with cmake maintainer to include /etc/rpm/macros.cmake there. +1 here also. +1 abstain. i don't know crap about cmake +1 +1 (same as FPC vote) rdieter: my only comment is that the chmod seems like a hack to work around a bug in cmake rdieter: is there any chance we could get a fix in cmake instead to install shlibs as executable? jeremy: it *is* a hack, and some serious poking needs to happen to fix it. Fortunately these macros live with cmake, so as cmake evolves the macros can evolve with it. rdieter: I'd almost rather we had %cmakeinstall so that the hack could just live in cmake rdieter: rather than littered across spec files where it will end up living long past when cmake is fixed jeremy: I'm ok with that. I'll look into it. also, what's with VERBOSE=1 ? that's just recommended usage (else the build is uber-quiet) f13, (great about the update tool thing) Running without verbose makes it a bit tough for the reviewer to make sure the compiler is getting called correctly, for one. so is the kernel build wouldn't it be nice if the only thing output during builds was actual problems instead of piles of noise? :-) Not really. It's not like the build output is displayed anywhere. but then you need to blindly trust the build process... c4chris: and the fact that stuff gets output makes you trust there's nothing else happening? jeremy, it's a tradeoff Let's not degrade into random existential arguments. hee tibbs: +1 yeah, definitely a side conversation :) sorry for derailing things folks Ok, anything else from the Packaging Committee. The point is that I, as a reviewer, would have to build with VERBOSE=1 anyway to check things. jeremy: I'm certainly open for more comments, suggestions outside of the meeting. Anyway, nothing else from FPC except for a plea for more eyes on the Ruby Gems thing. bpepple: that's it. ok, let's move on. --- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora bpepple: can I propose moving the FPC report to the start of the meeting? then we're less likely to have lost people for it jeremy: I'm fine with that. Folks are free to actually reply to the FPC meeting report instead of waiting for this meeting, of course. tibbs: yep, definitely. I just happened to have the thought as we started discussing it today Any thing else people want to discuss? Unfortunately there's not much time between meetings, and if I don't get the report ASAP then there's not a lot of time for discussion. That's just how it goes, I guess. quick Q: is koji landing still planned for soon? or after test3 or before test4 or ? Well, there was call in the FPC meeting for FESCo to decide on the Ruby Gems thing, but I don't think there's enough information to present for that yet. policy decision, to even allow ruby gems or not? (If I recall correctly) rdieter, tibbs: what's the issue with Ruby Gems? Unfortunately we're not the ones driving it, but basically: Ruby has its own internal packaging format, just like every other language seems to have (python eggs, for example). Gems keep everything (docs, libraries, etc.) under a single directory. There are claims that this violates the FHS. the crux of the problem is that there could be a package that provides a ruby gem for a library in one path, and then antoher package which provides the ruby library in a different path (not in gem format) Debian bans Gems for this reason. and ruby software can use one or the other (or even both!) nirik: hopefully shortly after Test3 so it's not like CPAN? f13: lutter thinks that can be worked around so that people only see one package. f13: cool. jwb: No, CPAN is far saner. tibbs: yes, but that means every package would have to come in both formats. and symlinks galore. tibbs: yes, that would be ideal, imo, if technically feasible and without too much evil hackery. Sounds like a can of worms I would be leery of opening. i'll read more on it though If we ban gems we dump a massive pile of content that many people want. Rails, for example. Some other distros have piles of ruby content. Rails only comes in gems packages? Yes. how about postponing, until lutter works on the gems integration a bit more? fine by me... yeah, lets give lutter a chance. :) rdieter: +1. yup But if anyone is actually interested, more help and additional eyes on the problem would be appreciated. rdieter: +1 tibbs: +1 lutter hides since the same discussion will end up being had about eggs at some point too probably jeremy: I thought we fixed that by having packages potentially drop in egg info files? jeremy: ruby doesn't seem to be sane enough about this and won't read info files, the gems have to exist somewhere or at least thats what I thought f13: At some point we need to rediscuss eggs. f13: that's where we are now. but it probably needs more thought and then there's the java stuff that fitzsim blogged about blarg The current packaging works but there's something to be said for putting packaged eggs into the system as well (ie: zipped up into the egg) basically, big discussion.  needs thought.  act not too quick we shall  for F8 It allows us to do versioned python libraries. f8 we will solve all our scripting language packaging problems! f13: or F9 or 10... jeremy: the java stuff looked messy jeremy: agreed. anything else people want to discuss, or should we wrap up for this week? wrap++ bpepple will end the meeting in 30 wait! just kidding
 * dgilmore is here
 * nirik is here.
 * warren here
 * spot is here, just a bit late
 * mspevack is lurking
 * jeremy is a little confused as to what the question right now is
 * XulChris would love to see changelogs move from spec files to DBs
 * bpepple thinks we really need a QA team to work on this.
 * spot would also like a pony. :)
 * jwb pounds head into desk
 * f13 looks at wwoods
 * wwoods tries to decode scrollback - a QA team for what now?
 * nirik has been trying, but hasn't had the time he would like to either.
 * warren is feeling extremely sick and needs to lie down for a while. bbl
 * bpepple Ruby knowledge is pretty limited.
 * c4chris knows zilch on ruby...
 * jwb is thinking Gems == bad
 * jeremy will try to find some time to sit down and talk with lutter
 * jeremy moves that we move on
 * bpepple listens to the crickets.
 * bpepple will end the meeting in 60

bpepple shakes his fist at jwb. sorry, always wanted to do that :) -- MARK -- Meeting End
 * bpepple will end the meeting in 15