Extras/SteeringCommittee/Meeting-20070405

2007 April 5 FESCo Meeting

Members

Present

• Brian Pepple (bpepple)
• Jason Tibbitts (tibbs)
• Christian Iseli (c4chris)
• Rex Dieter (rdieter)
• Toshio Kuratomi (abadger1999)
• Kevin Fenzi (nirik)
• Dennis Gilmore (dgilmore)
• Warren Togami (warren)
• Josh Boyer (jwb)
• Jeremy Katz (jeremy)
• Jesse Keating (f13)

Absent

• Tom Callaway (spot)
• Bill Nottingham (notting)

Summary

Packaging Committee Report

• Packaging Committee didn't have any guidelines that needed FESCo approval this week.

cvs-import changes

• Jens Petersen's patch has been applied, and c4chris will send a message to the mailing list informing them of the changes.

Package Database

• abadger1999 is looking for help in writing some small scripts for the package database, mainly adaptations of things currently using owners.list. If you intested, please contact Toshio.

Package Conflicts

• bpepple will contact Michael Schwent to see if he has a tool to help identify packages with conflicts, and if he is also interested in helping to fix them.

F7 Preparation

• It was discussed what deadlines we should have for EVR and broken deps. It was suggested that they should be fixed a week before F7t4, otherwise they would be removed. nirik will send a message to the mailing-lists informing the maintainers of this.
• Discusses the problem with Zope/plone since it is unable to work w/ Python-2.5. It was decided that pull Zope/plone for F7, rather than push a compat python package. For details on the lengthy discussion of this, please refer to the IRC log.

Log

--- bpepple has changed the topic to: FESCo meeting -- Meeting rules at http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
* tibbs here
<bpepple> FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren
Hi everybody; who's around?
* jeremy is here
<rdieter> here
* nirik is here.
<abadger1999> here
<bpepple> We'll start slow, and see who else shows up.
--- bpepple has changed the topic to: FESCo meeting -- Packaging Committee Report -- spot, abadger1999, rdieter, tibbs, scop
<tibbs> We had an abbreviated meeting this week
<bpepple> tibbs: there's nothing to vote on correct?
<tibbs> as the drivers for the scheduled items were away.
Nothing to vote on, no.
The only issue that was really discussed was noarch packages.
Specifically, those that are "noarch" but aren't meaningfull on all arches.
A draft is being cooked up; folks are welcome to participate.
That's pretty much it.
<bpepple> cool. should we move on then?
<f13> I'm here, but on another call.
<rdieter> move_on++
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- cvs-import changes - has Jens patch been applied?
<bpepple> does anyone know the status of this?
<nirik> yes, the patch was applied...
<nirik> there were some issues, but f13 fixed them. ;)
<bpepple> nirik: cool.  was anything sent to the mailing list telling folks about it?
<nirik> someone might want to drop a note to maintainers about it and ask everyone to check out the new one.
not that I know of. ;(
<bpepple> nirik: ok.  I see if c4chris wants to send out a message.
we can probably move on then.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Package Database - abadger1999
<bpepple> abadger1999: anything you want to discuss regarding this?
<abadger1999> Not this week.
<bpepple> abadger1999: ok, we'll move on.
<abadger1999> Well  actually,
<bpepple> whoops.
<warren> sorry, here now
<abadger1999> If anyone is interested in this, we're at a stage where there are a bunch of little scripts that need to be written.
So feel free to contact me if you have some time to donate :-)
<warren> abadger1999, is there a list of these scripts?
<abadger1999> Mostly syncing data into the packagedb or back out.
<bpepple> abadger1999: I'll add your request to meeting summary also.
<abadger1999> https://admin.fedoraproject.org/pkgdb/
In the "Before Go Live" section.
Five scripts that we need to complete.
Most of them are adaptations of things currently using owners.list.
So if you know python you can build on what's already been implemented.
Okay.  I'm really done now :-)
<bpepple> abadger1999: thanks.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- renaming cvsextras group -- warren
<bpepple> warren: you wanted to discuss this.
<warren> I think we should do it along with the merge changes.
In order to reduce confusion
but jeremy fears that this is too much change at once
He might be right.
<jeremy> and I'd rather wait because we have enough things moving right now
and there _are_ dependencies on, eg, the cvs server on the group name
<bpepple> yeah, there is a lot of changes being done.
<warren> How difficult is it to 1) identify all places that need it changed 2) turn off everything 3) change it 4) turn it back on?
<jeremy> warren: I do not feel comfortable at all that I can get everything identified while at the same time trying to get the rest of the migration done.
warren: and two people touching the same place on the cvs server at once is a recipe for disaster
<rdieter> 1 may well be change it, and see what breaks. :(
<warren> OK,  let's go back to this topic sometime later.
<rdieter> wait++ (it's a cosmetic change afterall)
<bpepple> sounds good to me.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Package Conflicts - https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00017.html
<bpepple> Rahoul and thl brought this up on the list.
* thl wakes up
<thl> we first should know if the COnflicts draft was approved by FPC or not
<nirik> so http://fedoraproject.org/wiki/PackagingDrafts/Conflicts was approved?
<tibbs> I need to ping spot to see why that draft hasn't been written into guidelines.
I posted links to -maintainers; the discussion is there.
<bpepple> should we wait till next week then?
<thl> bpepple, I'd say all those conflicts are a problem; but I think we have bigger problems to solve atm
<tibbs> Outside of the draft, we will need someone to actually find bad packages.
<thl> tibbs, exactly
<tibbs> Does someone have a tool for that?
<rdieter> no, the packageing draft and ml discussion are two separate, but related, topics.
<thl> that's a lot of work, and that needs some volunteers that want to do that work
<tibbs> I thought I saw some automated conflict detection output.
<thl> I'd say do it now if we find volunteers, but wait until after F7 if there are no volunteers
<rdieter> mschw... has a tool.
<thl> rdieter, yes, he has
<nirik> mshwent has filed bugs for the core+extras ones.
<tibbs> If so then it's just a matter of fixing them.
I wonder if there's a search term that would find all of those bugs.
* rdieter is shamed to admit being one of the conflicting offenders.
<nirik> They are blocking on the F7tracker I think.
FE7Target I guess
<bpepple> Does anyone want to volunteer to head this?
<thl> yes, I think they do
but he iirc only filed the really bad ones
<tibbs> It's not an easy problem in any case; it would be nice if there were a tool that would tell if a package under review would conflict with the existing repo.
<thl> there are probably much more
<tibbs> I unfortunately can't drive this right now; perhaps when I find more time.
<nirik> I think one thing that might be helpfull for this, and broken deps and evr problems is: a deadline. If you don't fix your package by XYZ, we remove it from the repo.
<rdieter> maybe FESCo needs a ToDo list/page, where others can see where help is needed?
<tibbs> Well, perhaps we should pick a deadline for some things.
<thl> nirik, +1, but we can't do this in stable repos; so doing this after F7 is out would be best
<rdieter> nirik: when 2 packages conflict, threated to remove *both*?
<nirik> no, I think it must be done _before_ f7 is out.
<tibbs> EVR has been well understood for ages; I think packages with F7 EVR problems should go by test 4.
<nirik> only in devel, yeah...
* c4chris pops in late
<bpepple> tibbs: +1
<rdieter> tibbs: +1
<tibbs> Conflicts are tougher since that draft didn't get written in.
<fabian_a>  /msg NickServ IDENTIFY speech1
<rdieter> the draft only covers explicit use of the Conflicts: tag anyway (afaik)
<thl> nirik, well, maybe ask mschwendt do drive this?
<wwoods> what's the tool that checks for conflicts and such?
<nirik> I suppose I can look and see how bad the conflicts problem is... if it's just those ones that mschwent has already filed, or if there are a bunch more.
<thl> wwoods, mschwendt has one afaik
<nirik> wwoods: not sure... 'smart' package manager apparently has some ability to do it too.
<tibbs> rdieter: I interpret the last section to require that all conflicts be explicit.
<bpepple> thl: I agree.  We should probably ask mschwent on this since he's done a bunch of work on it already.
<rdieter> tibbs: good point, forgot/missed that.
<thl> bpepple, we just need to make sure that he has a proper mandate
<tibbs> But indeed it's not clear.  Would anyone have issue with a rule requiring that all conflicts be explicit?
<thl> bpepple, and the FPC might need to add something about file conflicts if there isn't anything yet
* jwb is here now
<rdieter> either fix, or explict.
ie, no implicit conflicts allowed.
<rdieter> but that's FPC stuff to hammer out.
<bpepple> thl: agreed.
<abadger1999> rdieter: +1.
<c4chris> rdieter: +1
<bpepple> thl: do you want to contact mschwent or do you want me to?
<c4chris> bpepple: (I'll post something about the new cvs-import script)
<thl> bpepple, I don't have much interest in this topic ;-)
<bpepple> c4chris: thanks.
thl: Ok, I'll contact him.
<thl> I just jumped in as this whole thing is something that floating around for ages
<thl> thx bpepple
<bpepple> Ok, anything else on this? Or should we move on?
<nirik> so the plan is to see how bad it is for now?
<c4chris> do we have a script somewhere that checks conflicts?
<bpepple> yes.  I'm going to contact mschwent and see if he want to head the this.
<nirik> ok, sounds good. move-on++
<bpepple> c4chris: I believe mschwent has a tool for this.
<c4chris> cool. move-on++ then
--- bpepple has changed the topic to: FESCO-Meeting -- EPEL
<dgilmore> sorry im late guys
<tibbs> Looks to me like you're right on time.
<bpepple> Is there anything need to be discussed the the EPEL group.
<thl> I don't think so
<bpepple> ok, let's move on then.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Extras 7 preparation
<bpepple> any outstanding items we need to work on for this?
<nirik> as I was saying, I think we should make a deadline for EVR and broken deps packages.
<dgilmore> bpepple: im waiting for nasrat to fix a rpm bug i hit on ppc64
<dgilmore> i need it fixed today
<rdieter> nirik: +1
<c4chris> nirik: yes
<bpepple> nirik: I agree.  what do you have in mind for a deadline?
<jeremy> dgilmore: I thought there was a test package which fixed things
<tibbs> dgilmore: Otherwise we  can't build?
<nirik> a week before test4?
<dgilmore> jeremy: there is  but nasrat is MIA in regards to getting it built and pushed into the repo
<nirik> 12 broken dep packages in the last report...
<c4chris> nirik: sounds fine to me
<bpepple> nirik: That sounds fine to me.  What does everyone think about that?
<dgilmore> tibbs: yes we wont be able to build
<jeremy> dgilmore: we can just deploy it to them for now
<tibbs> We
<dgilmore> jeremy: it needs to be inside the chroot
<tibbs> Sorry, we also need to consider the zope/plone problem.
<nirik> tibbs: yeah, thats a nasty one. ;(
<jeremy> dgilmore: let's talk about that one after this
<dgilmore> jeremy: ok
<tibbs> For those that don't know, zome/plone absolutely need python 2.4.
So we drop them or we add compat packages.
<bpepple> does anyone have a problem with a week before test4 for a deadline for EVR & broken deps?
<nirik> I guess I am leaning toward just dropping them.
<tibbs> I think they're rather important packages for us to have.
<rdieter> I'd say leave it up to the maintainer(s), but I'd lean toward dropping (until fixed) myself
<tibbs> bpepple: no complaints from me.
<abadger1999> IIRC zope3 can use python2.4 but plone is left in the lurch.
<rdieter> bpepple: no problem here.
<abadger1999> s/2.4/2.5/
<tibbs> I don't see daMaestro around; he's the maintainer and has all the details.
<jeremy> as the maintainer of python, the idea of adding a compat python2.4 package strikes me as an incredibly bad one.  and a route to lots and lots of pain
<bpepple> jeremy: +1
<jeremy> (and also, having had to maintain such a monstrosity in the past for keeping Old Internal Buildsystems working)
<nirik> from what damaestro was saying, zope can't use python2.5 either...
<c4chris> jeremy: agreed
I'd lean on drop
<tibbs> Leaves two alternatives: putting a python executable into the zope package, or dumping zope.  And the latter is bad for Fedora.
<rdieter> then it's simple, dump 'em until they're python25 compatible.
<tibbs> Well, I guess there's the mythical third alternative of fixing them.
<abadger1999> nirik: There's a zope 2.5.x series and a zope3 series.
<bpepple> rdieter: +1
<jeremy> tibbs: I think it's probably worse for zope than for us.
<nirik> http://wiki.zope.org/zope3/Zope3UsingPython25
I think shipping a python in the Zope package is also really nasty.
<bpepple> ok, so it sounds like the consensus is to dump zone until it works with python2.5.
<rdieter> hella nasty.
<abadger1999> nirik: Interesting interesting.  I stand corrected.
<bpepple> s/zone/zope/
<tibbs> Well, I think this is truly unfortunate.  One route just places burden on the zope maintainer; the other locks zope out of Fedora for some unknown amount of time.
<nirik> zope and plone.
<abadger1999> tibbs: ++
<jeremy> tibbs: if we don't do it, though, we lock ourselves into having to ship and support outdated versions of an entire framework for an unknown period of time
<rdieter> Of course it sucks, but it sucks less than any alternative we have.
<tibbs> I mean, certainly if someone is asking the python maintainer to provide compat packages, then it's up to the python maintainer.
<nirik> I suppose we could ask damaestro if he would be willing to spin up a package with a python in it for looking at?
<jeremy> it's not like python2.5 came out yesterday... it's been out now for > 6 months
<tibbs> But I don't see that anyone is asking anyone else to do the work.
<jeremy> tibbs: but it's not just that.  if you provide python2.4, you also then need a whole slew of modules now.
tibbs: and how do you decide which set of modules?
<tibbs> jeremy: Actually not.
<jeremy> tibbs: we basically put ourselves in a place where our _users_ lose
<tibbs> It needs no external modules currently.
<abadger1999> Does daMaestro have an idea of what python packages are needed to get basic zope + plone running?
<jeremy> tibbs: if there is /usr/bin/python24 on the system, I can all but guarantee people will start trying to use it for other things
<abadger1999> Ah.
<nirik> yeah, we will get people installing zope to use the python24 for other junk. ;(
<tibbs> I'm just parroting what I've heard on IRC, though.  I(t) could be completely wrong.
<abadger1999> Do real-life zope installations need other python packages?
<c4chris> and we are supposed to be bleeding edge
<tibbs> abadger1999: Some supposedly want an ldap interface.
<nirik> I am pretty sure the zope package just needs python24
<abadger1999> ie: real life sites need to build extra components in zope and they consume 3rd party python modules?
<tibbs> BTTW, isn't some of our infrastructure zope based?
<jeremy> abadger1999: if not, I would be quite surprised
<nirik> there is a optional python-ldap, but it's currently not used.
* c4chris has family coming in and needs to go afk...  Sorry and TTYL
<nirik> I guess I am for dropping them for now, perhaps have a wiki page to point at that says: "hey, bug the zope people to support python2.5"
<abadger1999> From a rules standpoint, I'm opposed to excluding zope and python24 compat packages if someone wants to maintain them.  From a pragmatic standpoint I'm very much with Jeremy...
<nirik> perhaps we could also ask damaestro to mail the zope lists and say: "hey, we have to drop... can you guys think of any alternatives?"
<abadger1999> So my thinking is we have to know if daMaestro is able to commit to actually maintaining a python2.4 stack.
<bpepple> nirik: +1
<abadger1999> Or if he's biting off more than he can really chew trying to go that route.
<tibbs> Well, that's really the deciding factor for me.
If he's willing _and_ able to do it, then fine with me, but that's asking a lot.
* jeremy thinks that adding compat packages against the wishes of the maintainer of the primary package is asking for trouble
<jeremy> because the primary package maintainer _will_ get bugs about it
<bpepple> jeremy: I agree.
<tibbs> BTW, it probably shouldn't be called /usr/bin/python24 in any case.  More like /usr/bin/runzope.
<abadger1999> tibbs: Regarding infrastructure.  We're trying to move some things to zope but we haven't gotten there yet.
<rdieter> I think python, being such a core component of fedora is a special-case, and well within FESCo's domain to prohibit a compat pkg, jeremy: +1
<bpepple> rdieter: +1
<tibbs> abadger1999: Well, we certainly aren't going to get any time soon at this rate.
<warren> rdieter, +1
<abadger1999> rdieter: As said, I'm against that kind of thing... -1
<tibbs> I dislike the idea that the package maintainer can dictate this kind of thing.  There should at least be a dialogue first.
<rdieter> you're welcome to ask daMaestro what he thinks, and if he's against it, then it's moot point.
<rdieter> tibbs: would you feel different if the package in question was: compat-glibc ? or compat-kernel?
* dgilmore is with jeremy on this
<bpepple> tibbs: normally I'd agree, but Python is such a special case in my opinion.
<f13> tibbs: there has been dialog.
<tibbs> I would still feel that there should at least be a dialogue.
<dgilmore> abadger1999: they will be running on RHEL5  so will be unaffected
<tibbs> If there was one between jeremy and daMaestro, I apologize for not seeing it.
<f13> tibbs: this has already been discussed between damiastro and a few other people.
tibbs: it just happened in #fedora-devel a few days ago, so not that visible.
<tibbs> I think I was part of that.
<jeremy> tibbs: we talked for a while on #fedora-devel a few days ago
<f13> if somebody _really_ wants zope/plone on a F7 box, well, chroot an older platform.
<dgilmore> f13: or use xen/kvm/kqemu etc
<tibbs> OK, well, if you discussed it then fine with me.
<bpepple> Alright, we should probably move on then.
<dgilmore> we have the virtualisation support that they could use FC-6 or something else
<bpepple> Anything else regarding F7 we need to discuss?
<tibbs> Of course, this "just use FC6" solution only works as long as we support FC6.  Hopefully zope will get fixed before F8.
<jeremy> bpepple: merge this weekend
<jeremy> excitement will abound!
<bpepple> jeremy: cool.
<rdieter> hee, if zope isn't fixed for f8, it has bigger problems.
<abadger1999> tibbs: I wouldn't hold my breath. :-(  zope moves slowly.
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
<nirik> whats the status on lmaken's update system thing?
<dgilmore> nirik: its very close now
we should be good to go for F7
<nirik> is that going in this weekend too? or ?
<dgilmore> possibly
<nirik> excellent. ;)
* rdieter marks this weekend as an important date in Fedora history, imo.
<wwoods> ooh, I need to see if I can get a list of pending updates out of that thing
<bpepple> rdieter: agreed.
<nirik> so should we mail the broken deps / evr maintainers and tell them to fix their stuff before test4?
<rdieter> nirik: +1
<bpepple> +1
I'll also add it to the meeting summary.
<nirik> there should be bugs filed on all of those...
<rdieter> broken deps at least, evr is less harmful, imo.
<bpepple> nirik: Do you want to send the e-mail?
<nirik> I see csound probibly got fixed in the last push. hurray!
* jeremy has to disappear to go try to track some stuff down
<nirik> bpepple: I can....
<bpepple> nirik: great, thanks.
<nirik> xmldiff is another weird one. Perhaps koji will build it where plague didn't tho.
<bpepple> anything else folks want to discuss? or should we wrap up for this week?
<abadger1999> jeremy: Looking for a cluebat for zope?
<bpepple> ok, let's wrap it up.
* bpepple will end the meeting in 60
bpepple will end the meeting in 30
bpepple will end the meeting in 15
<bpepple> -- MARK -- Meeting End