Extras/SteeringCommittee/Meeting-20070322

2007 March 22 FESCo Meeting

Members

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)

Summary

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
<jima> /topic /topic? making my head hurt... ;)
<jeremy> I'm here
<bpepple> FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren
<jwb> i'm here
<rdieter> here
<tibbs> I'm here.
* dgilmore is here
<bpepple> hey, jeremy. welcome back.
<abadger1999> here
* nirik is here.
<jeremy> bpepple: thanks
<c4chris> here
* warren here
--- bpepple has changed the topic to: FESCO-Meeting -- Core Package Review Process -- warren
<bpepple> warren: anything we need to discuss this week?
<c4chris> crickets ?
<warren> 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)
<bpepple> warren: ok. you mentioned that you wanted it kept on the agenda last week.  we can move on...
<warren> I guess remove it from the schedule
<tibbs> Is there a chance that this can be a blocker for F8?
<wwoods> 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?
<abadger1999> wwoods: No.  Extras is still open.
<jwb> wwoods, extras isn't frozen
<wwoods> is there a scheduled time for that?
<jwb> does there need to be?
<dgilmore> tibbs: i would hope its a blocker for F8
* spot is here, just a bit late
<c4chris> depends if Extras packages end up on a spin I guess
<jwb> c4chris, repositories are remotely installable
<bpepple> wwoods: I thought we were freezing extras around test4?
<jwb> c4chris, extras is essentially within every spin
<bpepple> though I could be wrong on that.
<jwb> bpepple, wwoods: i recall the same
<c4chris> jwb, I meant extras rpm ending up on the spinned CD/DVD
but I think f13 takes snapshots or something...
* mspevack is lurking
<c4chris> +1 to F8 blocker btw
<bpepple> c4chris: agreed.
* jeremy is a little confused as to what the question right now is
jwb blames wwoods
<nirik> I'd like to see a review+ as a blocker for f8, but we can revisit it then I suppose.
<jeremy> new packages can go in.  new packages _won't_ end up on the "main" spins
<XulChris> why cant the "freeze" process become more of a "branch" process?
<jwb> i hope you're not talking about a cvs branch
<c4chris> I think you need things frozen to do the branches
<XulChris> 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
<jeremy> XulChris: in some ways, the "freeze" process at test releases kind of _is_ a branch process
<XulChris> jeremy: a branch process that takes like 2 months...
<jeremy> 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
<nirik> 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
<jeremy> nirik: exactly
<warren> additions to devel doesn't effect the spin
<nirik> ok, sounds like new packages are allowed anytime? shall we move along to the next topic? or is there some question still here?
<bpepple> nirik: +1 to moving on.
<tibbs> So, core package review process: blocker for F8, not a blocker for F7.  Is that where we're at?
<jwb> tibbs, s/core//
at that point, they're just packages
<dgilmore> tibbs: thats how i see it
tibbs|h tibbs
<rdieter> not a blocker for F7, Re: F8 maybe/prolly, but that's a decision we can make later.
<jwb> tibbs, but yes in general +1
<nirik> tibbs: +1 from me, revisit if there is an issue down the road?
<warren> we're talking about two different issues here
<jwb> warren, hm?
<nirik> 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?
<warren> 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.
<jwb> warren, we're done with that
<f13> last two freezes we "froze" Extras somewhat durin gthe core freeze
pushes were limited and targetted.
<jwb> we've moved on from this topic
<f13> next time around, I want to enforce teh freeze collection wide.
<warren> I think there is a confusion.... two different types of freezes.
<f13> sorry, but I am catching up, and have prudent input.
<warren> Jesse is talking about freeze so the spin stabilizes.
--- jwb has changed the topic to: FESCO-Meeting -- Freezes -- f13, warren
<warren> Other people are confused about "feature freeze"
<f13> right, they're related.
<warren> but not exactly
yes, we need a better plan for the F8 cycle
<f13> I'm not keen on adding new packages after a certain point to the tree we're trying to prep for release.
<nirik> 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.
<XulChris> f13: but what does it matter if the package is not part of a spin?
<warren> jeremy, you mentioned there was a decision made regarding the extras freeze for F7?
<nirik> Would be nice to have this on the wiki where everyone knows what things mean and when things happen.
<wwoods> so the test3 feature freeze only applies to core (small-c) features, and does not imply the refusal of all new packages
<f13> 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.
<warren> wwoods, according to jeremy yesterday, the test3 feature freeze applies only to features in the spin.
<XulChris> oh man
<warren> f13, why did we agree to an everything spin?
=(
<XulChris> f13: what is it called? "Fedora Bloat"?
<jeremy> 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)
<dgilmore> jeremy: unless we say no new packages for releases
<f13> jeremy: nope it doesn't.  I don't have a good answer here.
<nirik> why not say no new packages after test3 or whatever...?
<dgilmore> though i like and i think most people like that things get added
<f13> jeremy: there will have to be an everything tree no matter what.
<jwb> nirik, because it's pointless
<jeremy> dgilmore: that's a pretty unpopular position for a lot of people
<jima> is there anything that strictly says we can't add new packages to 'updates'?
<abadger1999> I don't think "no new packages" is a good idea...
<f13> 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.
<nirik> well, if we add after the * spin is made, and the package isn't on the * spin, won't that confuse people?
<dgilmore> jeremy: i agree.   so we really cant do a everything release because a day after release its no longer everthing
<abadger1999> 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.
<warren> 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.
<f13> we have to have a full tree somewhere.
<jima> nirik: i think people will just have to live with that.
<bpepple> warren: agreed.
<nirik> 2 months? yeah, that would be way too long... I was thinking much less time before a release.
<f13> warren: don't think about this time, think about next time.
<jwb> the Everything iso is pain because there is no stable definition of Everything
<dgilmore> f13: i say the everything spin is net installable only  and is the rpm tree
<warren> f13, I don't think that is a valid argument.
<jima> jwb: every package in fedora?
<nirik> everything-2007-03-22-11:20:00
<jwb> jima, which changes on a daily basis
<jima> (as of a particular date)
<f13> 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.
<jima> nirik: sure.
<warren> f13, we need a realistic way to deal with the CURRENT transitory state that wont piss off all of our contributors.
<f13> just like there is a full "core" tree inthe release directory
<jwb> f13, yes
<f13> the updates directory at times gains new packages.
<warren> 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.
<f13> 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.
<warren> The plans will evolve
along with the tools
<bpepple> ok, so where are we for F7 then?
<jeremy> we're also not going to solve it by going around in circles on irc, fwiw.
<bpepple> jeremy: +1
<abadger1999> jeremy: +1
<nirik> we need both a short term plan for now, and a longer range better plan for f8 cycle... IMHO
<warren> The longer range plan will evolve over time
<jwb> "time" with boundaries
<jeremy> 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 ;-)
<nirik> jeremy: +1
<f13> of course
<jwb> yes, which is why we moved on from this topic in the first place
<bpepple> jeremy: agreed.
<c4chris> yes
<warren> "Everything" spin even without media is still up in the air
<f13> warren: I think not.
<jwb> warren, no it's not
<warren> it isn't?
<jeremy> so, who wants to take ownership of drafting up a proposal?
<f13> warren: we _have_ to have an everything tree for the spins to gain access to more packages than what is on the media
<nirik> I wrote up a draft for longer term... I can make something for short term too if people want
<f13> warren: just like previously you could enable "extras" at install time.
<rdieter> I nominate nirik.
<jeremy> nirik: that'd be great
thanks for volunteering :-)
<jwb> nirik, great
<c4chris> nirik, thx
<bpepple> nirik: sounds good. thanks.
let's move on...
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Package Database - abadger1999
<bpepple> abadger1999: you wanted to talk about this.
<f13> nirik: I'd love to read it.  I think I have something else from you in my inbox, but -ETEST3 :/
<abadger1999> the PackageDB is very close to finished.
<nirik> 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.
<abadger1999> The front end is done.
<f13> nirik: I'll get that to you.
<abadger1999> I finished logging last night and half of notifications of changes.
<dgilmore> abadger1999: do you know what you will need from me backend wise?
<jeremy> nirik: if you bounce it my way, I'll take a look too.
<abadger1999> dgilmore: An overview of scripts that cvsadmins use.
And also any insight into the automated scripts that you have.
<nirik> 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...
<dgilmore> abadger1999: :)  ok they are eveolving but getting better  ill talk to you latter about the details
<abadger1999> dgilmore: Great :-)
<XulChris> how can a frontend be finished before a backend?
<abadger1999> XulChris: It's finished up to the database.
<dgilmore> XulChris:  backend is making changes in cvs bugzilla etc
<abadger1999> 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.
<spot> abadger1999: is there any chance of including license data in the db?
<abadger1999> (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?
<spot> spec tag initially
<XulChris> spot: id hope there is a chance of anything being added to the db
<spot> i'd like to have it all link to a licenseDB that i need to build
<jwb> speaking of that...
what license is the packagedb code under?
<thl> requested is maybe a bit strong word -- I just asked for the status, as the PackageDB might make things a bit easier
<abadger1999> k
<dgilmore> abadger1999: GPL?
<spot> abadger1999: thanks.
<bpepple> abadger1999: anything else?
* XulChris would love to see changelogs move from spec files to DBs
<abadger1999> 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.
<c4chris> abadger1999, cool.  we need to login first I guess before making changes...
<abadger1999> bpepple: That's it.  Play around and see what you think.
<jwb> abadger1999, hm, k
<bpepple> abadger1999: greats.  thanks.
<abadger1999> c4chris: Yep.  Fedora Account System username/password should work.
<c4chris> k
<bpepple> moving on....
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Broken Upgrades paths - jwb
<nirik> abadger1999: might add a "you are not logged in yet: Login" button?
<abadger1999> nirik: Will do.
<jwb> 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
<nirik> I had notes about borken update paths in the roadmap draft: http://fedoraproject.org/wiki/KevinFenzi/RelaseRoadMap-DRAFT
<spot> F6 -> F7 is going to explode for non-anaconda upgrades anyways
<nirik> orphans, broken dependencies, evr problems, and release target/blocker bugs should all be made clear/addressed.
<spot> (not that we shouldn't clean up our messes, just pointing it out)
<jwb> spot, not necessarily but that isn't the point
<nirik> spot: why?
<rdieter> pointy sticks?
<spot> nirik: SATA changes
<nirik> nope.
it works fine when I tried it with rawhide a while ago.
<jwb> spot, it depends on the hardware
<XulChris> damn, i sure hope anaconda works this time
<spot> jwb: i know.
<jwb> but not the point
<spot> if you have SATA on FC6 you had /dev/hd*. F7 will have /dev/sd*
* bpepple thinks we really need a QA team to work on this.
<nirik> oh? some hardware still fails? :( I thought it was working for everything now. ;(
<jwb> bpepple, yes that's what i'm thinking as well
<jeremy> spot: that should be handled pretty well on the migration
* spot would also like a pony. :)
<spot> jeremy: in anaconda or in yum?
<nirik> I upgraded my laptop with sata fc6_>rawhide a few weeks ago and it worked fine.
(via yum)
<jwb> spot, either.  i upgraded fc6 -> rawhide a week or so ago
<jeremy> spot: for yum too.  anaconda has _zero_ code for it, so .... :-)
<spot> ok, awesome.
<XulChris> hmm wait i have dev/sd* on fc6
* jwb pounds head into desk
<bpepple> could we try to much off-topic?
<nirik> in any event we should get those items fixed.
<spot> perhaps someone should be tasked to look into these items
<nirik> We should make hard deadlines.
<f13> someone like a QA team?
<spot> at least to make a "current broken items" summary page
* f13 looks at wwoods
<tibbs> 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.
<nirik> I poked all broken dependency maintainers a few weeks ago, that cleaned up a bunch of them.
<jwb> we need large hands in RH to fix the core packages
<tibbs> boost, cups, dbus, systemtap
<jwb> who's going to be the big hair ape?
s/hair/hairy
<spot> jwb: eh, let me try.
<jwb> spot, k
<spot> forward those to me, i'll give it a shot.http://fedoraproject.org/wiki/PackagingDrafts/cmake
<tibbs> Oh, cups is an FC5 > FC6 problem.
<nirik> orphans we should remove from devel asap... they shouldn't be in the repo if they are orphaned.
<jwb> tibbs, still needs cleaning
that was my other point
this isn't just a "fix it for release" deal
<tibbs> I'm thinking that any non-essential packages with broken upgrade paths need to go from the distro rather soon.
<nirik> some of the broken deps are really hard, and will probibly just need to remove those packages?
<c4chris> I can clear orphans
<jwb> we need to actively work on getting them all fixed for all releases now and in the future
<spot> nirik: document them? worst case, i can try to fix some of them.
<jwb> spot, they're all documented...
<spot> jwb: where? :)
* wwoods tries to decode scrollback - a QA team for what now?
<jwb> spot, see the Package EVR problems email on -maintainers
<tibbs> For zope and plone, for instance, they require python 2.4 and the maintainer would like to get authorization for a compat package.
<jwb> spot, it's a report that is generated on a regular basis
<spot> jwb: no, i see that
i'm thinking more "broken deps"
<nirik> csound blows up in a weird way.
<jeremy> 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
<jwb> spot, ah, we have that too
<nirik> xmldiff blows up in a weird way only on the buildsys
<warren> 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?
<spot> jwb: where is that? :)
<tibbs> jeremy: Yes, but then we need zope and plone as well.  So it's a rock><hard place issue.
<spot> tibbs: has anyone tried to make zope/plone py2.5 happy?
<jwb> spot, "Summary- Broken dependencies in Fedora Extras"
spot, missing core i suppose
<tibbs> Yes, several people.  It's not an easy problem.
<abadger1999> wwoods: Fixing broken deps and broken upgrade paths.
<nirik> broken deps: https://www.redhat.com/archives/fedora-devel-list/2007-March/msg01102.html
<spot> ahh, ok -devel-list
i'm a bit behind there. :/
<nirik> evr: https://www.redhat.com/archives/fedora-maintainers/2007-March/msg00694.html
<wwoods> broken deps - I've been asking around about the automated mail stuff that goes out
<jwb> 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
<wwoods> same with the EVR problem mail
<jwb> wwoods, good to hear
<wwoods> I'm trying to put together a dashboard page to merge all these things into one place
<jwb> wwoods, do you feel that's something that falls under your role as the QA lead to look after?
<nirik> The broken deps are much reduced... but some of them are not easy 'just rebuild' problems.
<wwoods> 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
<tibbs> 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.
* nirik has been trying, but hasn't had the time he would like to either.
spot puts it near the top of his todo list
<jwb> wwoods, do we have a QA sig?
<wwoods> jwb: we have an unofficial QA group
<jwb> k
wwoods, don't be afraid to yell in various places if you need help with things like this
<wwoods> 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
<nirik> mschwent also filed bugs for all the EVR ones recently.
<f13> once the merger happens, we can use treediff and spamomatic to report on changes between rawhides and broken deps.
<jwb> f13, can we run that on releases too?
<wwoods> 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
<f13> jwb: yes, it'll be noisy but I gave it to mether last time to diff FC5 to FC6
<jwb> 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
<bpepple> 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
<nirik> 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.
<f13> jwb: update tool from lmacken should help with that.
jwb: depchecking before things are pushed as updates.
<bpepple> tibbs: I believe we have the cmake proposal to vote on.
<f13> jwb: did we mention, all "updates" to a released product must go through the tool?
<rdieter> fyi, http://fedoraproject.org/wiki/PackagingDrafts/cmake
<tibbs> Yes, sorry, doing too many things.
tibbs|h tibbs
It's just that one proposal today.
<bpepple> tibbs: no worries.
everyone get a chance to read it?
<tibbs> Basically, we have packages now which build with cmake; this is a proposal for some macros and guidelines to standardize its use in specfiles.
<c4chris> looks sane to me
<dgilmore> looks ok to me
+1
<c4chris> +1
<rdieter> When/if it is ratified, I'll work with cmake maintainer to include /etc/rpm/macros.cmake there.
<bpepple> +1 here also.
<nirik> +1
<jwb> abstain.  i don't know crap about cmake
<abadger1999> +1
<tibbs> +1 (same as FPC vote)
<jeremy> 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?
<rdieter> jeremy: it *is* a hack, and some serious poking needs to happen to fix it.
<tibbs> Fortunately these macros live with cmake, so as cmake evolves the macros can evolve with it.
<jeremy> 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
<rdieter> jeremy: I'm ok with that.  I'll look into it.
<jeremy> also, what's with VERBOSE=1 ?
<rdieter> that's just recommended usage (else the build is uber-quiet)
<jwb> f13, (great about the update tool thing)
<tibbs> Running without verbose makes it a bit tough for the reviewer to make sure the compiler is getting called correctly, for one.
<jeremy> 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? :-)
<tibbs> Not really.  It's not like the build output is displayed anywhere.
* warren is feeling extremely sick and needs to lie down for a while.  bbl
<c4chris> but then you need to blindly trust the build process...
<jeremy> c4chris: and the fact that stuff gets output makes you trust there's nothing else happening?
<c4chris> jeremy, it's a tradeoff
<tibbs> Let's not degrade into random existential arguments.
<rdieter> hee
<bpepple> tibbs: +1
<jeremy> yeah, definitely a side conversation :)
sorry for derailing things folks
<bpepple> Ok, anything else from the Packaging Committee.
<tibbs> The point is that I, as a reviewer, would have to build with VERBOSE=1 anyway to check things.
<rdieter> jeremy: I'm certainly open for more comments, suggestions outside of the meeting.
<tibbs> Anyway, nothing else from FPC except for a plea for more eyes on the Ruby Gems thing.
<rdieter> bpepple: that's it.
<bpepple> ok, let's move on.
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
<jeremy> 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
<bpepple> jeremy: I'm fine with that.
<tibbs> Folks are free to actually reply to the FPC meeting report instead of waiting for this meeting, of course.
<jeremy> tibbs: yep, definitely.  I just happened to have the thought as we started discussing it today
<bpepple> Any thing else people want to discuss?
<tibbs> 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.
<nirik> quick Q: is koji landing still planned for soon? or after test3 or before test4 or ?
<tibbs> 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.
<rdieter> policy decision, to even allow ruby gems or not? (If I recall correctly)
* bpepple Ruby knowledge is pretty limited.
<jwb> rdieter, tibbs: what's the issue with Ruby Gems?
* c4chris knows zilch on ruby...
<tibbs> 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.
<f13> 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)
<tibbs> Debian bans Gems for this reason.
<f13> and ruby software can use one or the other (or even both!)
nirik: hopefully shortly after Test3
<jwb> so it's not like CPAN?
<tibbs> f13: lutter thinks that can be worked around so that people only see one package.
<nirik> f13: cool.
<tibbs> jwb: No, CPAN is far saner.
<f13> tibbs: yes, but that means every package would have to come in both formats.
and symlinks galore.
* jwb is thinking Gems == bad
<rdieter> tibbs: yes, that would be ideal, imo, if technically feasible and without too much evil hackery.
<bpepple> Sounds like a can of worms I would be leery of opening.
<jwb> i'll read more on it though
<tibbs> 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.
<jwb> Rails only comes in gems packages?
<tibbs> Yes.
<rdieter> how about postponing, until lutter works on the gems integration a bit more?
<jwb> fine by me...
<spot> yeah, lets give lutter a chance. :)
<bpepple> rdieter: +1.
<c4chris> yup
<tibbs> But if anyone is actually interested, more help and additional eyes on the problem would be appreciated.
<jeremy> rdieter: +1
<abadger1999> tibbs: +1
* jeremy will try to find some time to sit down and talk with lutter
lutter hides
<jeremy> since the same discussion will end up being had about eggs at some point too probably
<f13> 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
<f13> or at least thats what I thought
<abadger1999> f13: At some point we need to rediscuss eggs.
<jeremy> f13: that's where we are now.  but it probably needs more thought
and then there's the java stuff that fitzsim blogged about
<f13> blarg
<abadger1999> 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)
<jeremy> basically, big discussion.  needs thought.  act not too quick we shall
<f13> <punt> for F8
<abadger1999> It allows us to do versioned python libraries.
<f13> f8 we will solve all our scripting language packaging problems!
<abadger1999> f13: or F9 or 10...
* jeremy moves that we move on
<dgilmore> jeremy: the java stuff looked messy
<bpepple> jeremy: agreed.
anything else people want to discuss, or should we wrap up for this week?
* bpepple listens to the crickets.
<c4chris> wrap++
* bpepple will end the meeting in 60
bpepple will end the meeting in 30
<jwb> wait!
just kidding
:)
* bpepple will end the meeting in 15
bpepple shakes his fist at jwb.
<jwb> sorry, always wanted to do that :)
<bpepple> -- MARK -- Meeting End