Extras/SteeringCommittee/Meeting-20070503

2007 May 03 FESCo Meeting

Members

Present

• Brian Pepple (bpepple)
• Jason Tibbitts (tibbs)
• Rex Dieter (rdieter)
• Jesse Keating (f13)
• Christian Iseli (c4chris)
• Toshio Kuratomi (abadger1999)
• Jeremy Katz (jeremy)
• Bill Nottingham (notting)
• Warren Togami (warren)
• Kevin Fenzi (nirik)
• Tom Callaway (spot)

Absent

• Josh Boyer (jwb)
• Dennis Gilmore (dgilmore)

Summary

CVS Branching

• CVS will be branched next week (2007-05-10).
• After F7 is released, FESCo will address when future branchings should occur.

Test release after merge?

• FESCo discussed whether to have a test release after the merge is finished. It was decided that the daily spins being currently generated is sufficent.

Bugzilla changes due to merge

• Plan is to add all Extras components to Fedora Core, and then rename that component 'Fedora'. Then all Extras bugs will be moved to 'Fedora' in the database.

Meeting Minutes IRC bot

• Since this is a fairly low priority item, we'll look into this after F7 has been released.

Log

<bpepple> FESCo meeting ping -- abadger1999, bpepple, c4chris, dgilmore, f13, jeremy, jwb, notting, rdieter, spot, nirik, tibbs, warren
* tibbs here
<bpepple> hi everyone.  who's around?
* nirik is here.
<notting> yes?
* rdieter here
<f13> here
* knurd is one the rabble seats
alleycat lurking
rdieter hands the popcorn to knurd
<bpepple> Ok, we can start off slow as others show up.
--- bpepple has changed the topic to: FESCo meeting -- Any objection to this week's report from FPC at https://www.redhat.com/archives/fedora-maintainers/2007-April/msg00507.html
alleycat is now known as wolfy
* wwoods seeks lunch units and lurks
cweyl lurks
<bpepple> Any objects to this week's FPC summary?
* c4chris is here now...
<nirik> no objections here.
<bpepple> Otherwise we can move on.
<notting> bpepple: as someone who has never packaged php or ruby, i don't have anything to add :)
<c4chris> same here
<bpepple> Yeah, I had no issues either, so we can probably move on...
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Schedule for branching of CVS -- notting
<bpepple> notting: you wanted to discuss this.
<notting> so, the proposal from f13 was (iirc) to do the mass branch for F-7 in CVS when we go gold? i a) wanted to make sure that's reasonable from a fesco point of view b) want to determine if we want set dates in the schedule for this in the future
<f13> not when we go gold.
<nirik> when is "gold" ? shipping to mirrors/dist?
<f13> when we freeze deeply
which should be a week or so before we go "gold"
<notting> f13: so, next thursday, theoretically?
<f13> correct.
<bpepple> I'm fine with it being next week.
<c4chris> does that mean devel unfreezes 1 week before gold too?
<nirik> sounds fine to me. We should document when that happens in a normal release tho...
<jeremy> note that the branch process took a few hours last time, probably similar time will be required this time
<tibbs> I really wish we could branch earlier.
<f13> as jeremy has stated, a long term goal is to allow developers to branch when they want to, with a default deadline of what we mentoined above.
<warren> back now, had to get food.
<notting> f13: well, tehcnically, a cvs admin *could* do that earlier nwo
<f13> c4chris: devel does, but the builds won't necessarily go anywhere.  Rawhide will still compse from the freeze tag
<nirik> branching to early means people go work on the new fun stuff and ignore trying to make sure the old stuff is nice and bugfixed and stable.
<f13> until we have a successful RC spin to hand to mirrors.
<c4chris> tibbs: why earlier ?
<abadger1999> nirik: That's the theory... I don't know that it's necessarily been true in the case of extras, though.
<tibbs> I want to have devel mean "devel".
There are updates to my package I'd like to test, but I can't without them getting into F7.
<notting> tibbs: well, when we flip on koji for devel, that will be the case - they will not go directly into f7
<tibbs> Then there shouldn't be any reason not to branch F7 off at, say, test1.
<c4chris> notting: I thought the flip just happened?
<notting> c4chris: technically, the build system is not turned on :)
<knurd> notting, and where will they land? Just wondeing?
<notting> unless f13 *just( did it
knurd: depends on the koji config. /me defers to f13
<f13> test1 is way too early
tibbs: unless you like fixing things on multiple branches all the time.
* knurd now and then in the past also wondered if we should fork of a Release when releasing the latest test version
<jeremy> knurd: the problem is that, fundamentally, "it depends"
<f13> knurd: there could be a bleeding repo url, or browseable url to the package stores.  packages/<package>/<version>/<release/<arch>/
<knurd> jeremy, that why I keept quiet with that ;-)
<c4chris> for starters, I'd prefer we branch at the last test rather than at the first...
<bpepple> c4chris: that's what I was thinking also.
<jeremy> knurd: for most of the packages I work on (for example), I don't want to have to double commit for the last n weeks of the release... I'd rather just have my f7 builds inherited into f8 (and thus, cvs has to stay synced)
<f13> we're typically not ready to move on to wild development work for our packages, but some are
this is why having developers be able to do it themselves is important.
<nirik> would the ability for scratch builds help this? you could then run a scratch build for your bleeding test and have only people you tell test it?
<f13> but I'm not keen on making a new rawhide for the new builds.
<knurd> jeremy, I know, I know;
<cweyl> nirik: I'm a fan of that.
* jeremy thinks this is a bit of a rathole for this point, though...  bringing it up as we get the f8 schedule up and running is a more sensible time probably
<f13> nod
We have a plan for F7, thats enough for today
* bpepple agrees with jeremy.
c4chris nods
<bpepple> should we move on then?
<f13> please
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Fedora 7 preparation -- Test release after merge?
<bpepple> mether brought this up on the list.  what do others think?
<f13> I'm not real keen on the idea of a test54
er test5
I'm willing to upload spins as we make them for public consumption
<nirik> yeah...
<f13> and really, the tools should be useable for people to do this on their own too
<knurd> we had some RCs in the FC2 or FC3 days iirc
<nirik> wwoods: any thoughts from qa about another test? needed?
<knurd> sopwith did them; it worked quite well iirc
didn't you guys release internal RC in the past? maybe we should to that in (semi-)public now?
<f13> knurd: at some points yet
<warren> torrent-only
<c4chris> I'd say advertise the uploaded spins on devel and test should be enough
<wwoods> test5 is a last resort, holy-shit-we-are-completely-boned situation
<f13> knurd: I plan to start 'spinning' before the freeze anyway
<knurd> warren, or rsync; that's what sopwith did iirc
<wwoods> unless I hear "holy shit we are completely boned" I am still hopeful that we can get by without it
<bpepple> wwoods: agreed.
<rdieter> making semi-regular/daily test spins seems like a good idea...
<wwoods> some RC trees would be good, and the weekly liveCDs (jeremy?) will help
<jeremy> and weekly rawhide live images will continue
<wwoods> rdieter: pungi is available for you to make all the daily test spins you want
f13: can you make your config files public for that?
<jeremy> since I knew that today wasn't going to have rawhide, I actually created them yesterday; just about to test them out and then try to get them up this afternoon
<wwoods> c4chris: don't forget fedora-qa-list
<f13> wwoods: yeah.
<c4chris> wwoods: right
<nirik> ok, so sounds like no test5, but lots of other ways to test before release. ;)
<bpepple> ok, I think we can move on then. since it sounds like everyone agrees that the spins should be sufficient.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Handling Bugzilla after merge -- warren, notting
<bpepple> notting, warren?
<tibbs> Is there something that actually needs to change, besides merging the component lists?
<f13> and wwoods on that topic.
tibbs: Fedora Core -> Fedora
<notting> warren's suggestion was thus:
<f13> tibbs: I think we need a clean break for Fedora 7
* nirik would like to see cleanup of the old devel bugs, ping to move to release, needinfo, close, etc...
<notting> - add all Extras components to Fedora Core
<f13> Core/Extras can sit there for 6/5/
<notting> - rename 'Fedora Core' to <something>
<warren> A "clean break" sounds nice in theory but it doesn't actually gain us anything.
<notting> - move all Extras bugs to that new <something> in the db
- delete Fedora Extras as a separate product
<warren> Having all bugs in a "Fedora" product allows it to be easily queryable
mkaing it disjoint will make it more difficult and inconvenient to query and move bugs around.
<f13> warren: at the very lest, we need to kill the generic 'test1/2/3' versions.
<warren> f13, agreed, but that is independent of this
<f13> nod
<spot> i think having everything one Fedora product makes it less likely that old bugs will fall on the floor unfixed
<wwoods> the plan of record from QA is to put together a better bugzilla frontend on fp.o that will hide all the versions except the 4 relevant ones
<spot> we're still finding things that are unfixed, assigned to sopwith
<bpepple> notting: warren's plan sounds good to me.
<warren> wwoods, that is only a convenience front-end, the backend structure matters
<c4chris> notting: plan sounds fine
<notting> so, the question is, what do we name the 'something'. warren suggested 'Fedora Package Collection'. i like just 'Fedora'
<wwoods> warren: yeah, but "too many versions clutters up bugzilla" is a frequent objection
<c4chris> quick question: will the owners.list file continue to be updated ?
(in the forseeable future that is)
<spot> either Fedora or Fedora Packages
<notting> c4chris: until packagedb, yes
<bpepple> notting: I prefer just 'Fedora' also.
<c4chris> k
<f13> I like Fedora
* nirik likes Fedora too
knurd votes for  Fedora Packages
<c4chris> just Fedora sounds fine, unless there will be a clash with our other projects that need a BZ component
<wwoods> the individual components are the packages. the product is 'fedora'
<knurd> we can't call each and evreything just "Fedora" -- that becomes confusing IMHO
<f13> c4chris: other projects can be ina  different category.
c4chris: or a different bugzilla/bug tracking system.  Like Trac
<c4chris> fine with me
<notting> right now we have 'Fedora (Core|Extras|Documentation|EPEL)'...
<f13> The problem with "Fedora Packages" is that we get bugs that aren't about any packages.
* cweyl would like to see those all collapsed into just "Fedora", personally
<f13> they're compose issues, or grouping issues, or Distribution RFEs
<warren> notting, you suggested Fedora Package Collection, I just copied your original name
notting, I don't care what it is called.
wwoods, you're just talking about an alternative frontend, which is fine.
<notting> warren: i did? oops.
<c4chris> looks like we all like just Fedora :-)
<warren> wwoods, I'm concerned about the underlying structure, having separate products will cause us more problems and not gain us anything.
<knurd> Fedora Package Collection is a old term I and max suppoerted on fedora-devel weeks ago
<spot> I think Fedora is a sufficient identifier.
<knurd> that wasn't for bugzizlla; it was just in the discussion which term to use for the Package repo as a whole
<wwoods> warren: I'm not suggesting we have separate products..?
<warren> wwoods, one of your earlier posts did, I just wanted to be sure you weren't pushing for that now.
<bpepple> ok, so where are we on this?
<wwoods> warren: nope. I'm happy with one big "Fedora" product
<warren> OK
<nirik> so there would be other than just package components under "Fedora" , right?
<warren> who is responsible for making the changes within Bugzilla?  We need some script action perhaps by dkl.
<notting> nirik: distribution, comps. maybe one or two other meta-things if people ask for them
<nirik> right, so calling it Fedora makes sense... it's not really just Fedora Package Collection or Fedora Packages
<jeremy> LiveCD
<wwoods> notting: LiveCD, and I've been toying with the idea of having further sub-components for kernel stuff (kernel/wireless, kernel/networking, etc)
* cweyl can't wait for all the BZ email :)
<notting> cweyl: if we're going to move all the extras bugs, we're going to do it in the db :)
<f13> we should be able to do it mailless.
<notting> (not in the web ui)
<f13> god I hope so.
<cweyl> notting: whew :)
<c4chris> sounds all peachy to me.  Now we need to tag someone :-)
<spot> aww, i wanted to collect the tears of whoever had to do it in the web ui
<jeremy> cweyl: we'll make sure you get plenty of mail from it though if you want :-)
<spot> their delicious tears
<cweyl> jeremy: I can't wait :)  now where'd I put my doc on procmail rules?  hmm
<f13> cweyl: I mailed it to you
<bpepple> Since no one objects to warren's proposal should we move on?
<jeremy> yes
<f13> sure
<notting> warren: want to work through it with dkl and post when you have an action date?
<warren> notting, yes, I guess I can do that.
--- bpepple has changed the topic to: FESCO-Meeting -- MISC -- Meeting Minutes IRC bot -- warren
<bpepple> warren: you get a chance to look into this at all?
<warren> bpepple, no, it is totally not a priority compared to this merge stuff.
<bpepple> warren: agreed.
we can get back to this after the F7 is released IMO.
<c4chris> yea, no rush here
--- bpepple has changed the topic to: FESCo meeting -- Free discussion around Fedora
<notting> so, current merge status
- cvs is on
- file uploading via /cvs/extras works, via /cvs/pkgs is broken (mmcgrath and i are poking at it)
f13: build status?
<f13> notting: waiting on you and mmcgrath to fix the cvs upload issue
<spot> is the merged Fedora entity frozen?
<f13> spot: yes, that's a side effect.
<notting> spot: well, you can't build.
<f13> from now on, rel-eng@fp.o if you want your build tagged.
<nirik> you guys might want to mention in any emails that things are back on and ready to go that we are still freezy for release, and they shouldn't go updating just to play with the new setup. :)
<notting> re: upload - anyone with deep ssl/apache knowledge is welcome to help :)
<nirik> will commits still go to fedora-extras-commits? or will that go away and only use the fedora-devel-commits or whatever the core list was?
<notting> right now, it all goes to extras-commits
<c4chris> anyone looked at the remaining /Extras wiki pages and the policies ones ?
<notting> do we want to rename/repurpose thel ist?
<rdieter> rename make sense.
<nirik> there is a fedora-cvs-list for core... or was.
<notting> can you rename in mailman w/o resubscribing people?
<bpepple> c4chris: haven't had a chance yet this week, but I should have some time tomorrow to start on it.
<f13> I don't think so
<rdieter> or make a new list (or recycle fedora-cvs-list), whichever is easier. :)
<c4chris> bpepple: k  I started a bit, but didn't go very far...
<nirik> I think fedora-cvs-list and fedora-extras-commits should collapse into one list, but not sure how to get all the subscribers on it.
<notting> what goes to fedora-cvs-list atm?
<c4chris> nirik: same here
<nirik> oh, it's fedora-cvs-commits.
https://www.redhat.com/archives/fedora-cvs-commits/2007-May/thread.html
<jeremy> I know... let's cross-post!
* jeremy hides
<abadger1999> It can be done on the server.
<notting> jeremy: we can start by crossposting and decomission a list later?
<nirik> I suppose we could just wait until the list reorg to worrry about it?
<abadger1999> But since it's not under Fedora Infrastructure control....
<bpepple> nirik: who's working on the list reorg?
<notting> i think the issue is 'the list reorg' is tied on the issue of 'move lists to different server'
<nirik> bpepple: it was waiting on hardware last I heard... middle of this month?
<notting> (well, one of the issues)
<nirik> not sure who was leading that... mmcgrath ? knurd ?
<c4chris> k, let's wait a bit then
<knurd> mail-reorg?
that's my topic
and mmcgrath on the server side
<c4chris> any eta?
<knurd> we needed more hardware for that
not sure if that's around in between
<bpepple> nirik: I hadn't heard much about it in a while, and didn't know the status.  thanks.
<knurd> I thought we get F7 out first before moving on with the mail-reord again
<c4chris> fair enough
<knurd> that sounded like the best for me
<bpepple> knurd: that fine.  just was wondering the status.
<knurd> as we have more pressing issues
<warren> We really need to be focusing on merge issues now.
<notting> warren: yeah, it's just whether -commitspam is a merge issue
<nirik> is there any status update on packagedb and/or bodhi?
<warren> packagedb I think is an important step after merge
<c4chris> what is bodhi again (/me gets a bit lost between koji, brew, plague, and all this...)
<abadger1999> A package update tool.
<c4chris> the one that sends announces ?
<f13> c4chris: the tool we'll be using to issue package updates to released FEdoras
<nirik> c4chris: updates system. ;)
<abadger1999> Allows the packager to request that a package be pushed to a repository with metainformation about why.
<c4chris> oh, a self-service push thing ?
<abadger1999> And things like having to go through a testing cycle before hitting production, etc.
<wwoods> hooray, a -testing repo for Extras
<bpepple> It's coming up on the hour. Anything else before we wrap up for this week?
<knurd> wwoods, +1
<f13> it's 1 part self service, 1 part rel-eng.
you request what gets pushed, rel-eng does the signing/pushing
<notting> do we have a FAQ for building (your builds go to XXX. send mail to YYY for them to be added to ZZZ)
<nirik> abadger1999: whats the status on the packagedb? also will that allow us to let sponsors have auto acl access to their sponsorees?
<c4chris> f13: k, thanks
<f13> notting: not yet, bodhi isn't quite there yet
<wwoods> I thought it was also 1 part QA - you put in your request, the package goes to -testing for QA, and then rel-eng does signing/pushing?
<abadger1999> nirik: It's been stalled for a few weeks.
<f13> wwoods: somebody has to push it to -testing
<notting> f13: talking short term. also a rel-eng side (the default tag is XXX, when tagging for F7 use YYY, to move to F8/devel use ZZZ) :)
<f13> wwoods: and things in -testing get signed with a test key
<wwoods> oh, okay
that makes more sense then
<abadger1999> I need to talk to notting about acls... Something he said last night got me thinking of ways to enable sponsor-auto-acls and such.
<f13> notting: oh that...
<nirik> abadger1999: that would be good. Sponsors should be able to fix sponsorees packages if need be
<abadger1999> I was planning on just having a cron job that wrote out a permissions file from the packagedb instead of reading owners.list & pkg.acl files.
Where this falls down is the current cvs acls script doesn't have a concept of groups.
<f13> abadger1999: patches?  (:
<abadger1999> so we'd have to precalculate all the people in various groups and add those to the file.... Which I'm sure would be bad for performance.
<jeremy> abadger1999: support for groups isn't hard to add at all
<abadger1999> f13: in perl.  I die, I die. :-)
<f13> heh
* c4chris does perl
<c4chris> where's the script?
<abadger1999> Anyhow -- notting mentioned having the aclsystem ask the packagedb if the user was permitted to access the package.
c4chris: on cvs-int.  I'll get you a copy.
<c4chris> abadger1999: k
<nirik> that would be nice in that changes would take effect right as soon as changed in the packagedb.
anyhow, any other items for meeting?
<abadger1999> So an alternative is to replace the script that checks acls from reading the "avail" file to querying the packagedb (through an API).
<notting> assuming the db is fast, this could speed things up
<jeremy> the downside is that it means if the packagedb goes down, so do commits
<abadger1999> Yep.  I was thinking both of those things.
<notting> jeremy: well, it shouldn't do that, then
<c4chris> could have a toggle somewhere
<nirik> oh, I have one more item: are we expecting all @redhat.com people to request sponsorship? Is someone just approving them? should we ignore all the sponsors emails?
<notting> yes, maybe, no?
(in that order)
<f13> notting: yes they need to get sponsored.  We aren't "just approving" them, I'm making sure they know whats going on when I approve them.  Anybody else can do the same.
<c4chris> if (pkgdb_is_up) {query_db} else {query_db_dump_files}
<nirik> f13: ok, how do we do that? mail them? or should we expect you are taking care of it? it's going to be a big flood...
<f13> nirik: you can mail them if you like.
<nirik> there was talk at some point of dividing them up so that each sponsor had a bunch they could help... but then I think we decided that they would get sponsored via merge reviews, and since we haven't done many of those...
<f13> many are already sponsored.
warren should have some stats on how many are missing.
<nirik> ok.
<bpepple> ok, I think we can wrap up the meeting now, unless anyone objects?
<c4chris> wrap++
<f13> I'm good
* bpepple will end the meeting in 60
--- rdieter is now known as rdieter_away
* bpepple will end the meeting in 30
bpepple will end the meeting in 15
<bpepple> -- MARK -- Meeting End