From Fedora Project Wiki

< Extras‎ | SteeringCommittee

Revision as of 16:35, 24 May 2008 by Admin (talk | contribs) (1 revision(s))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

2006 July, 27 FESCo Meeting

Meeting Summaries are posted on the wiki at:


  • thl
  • c4chris
  • dgilmore
  • bpepple
  • scop
  • rdieter
  • warren
  • tibbs
  • abadger1999
  • jeremy


  • Mass Rebuild is waiting to reinstall the builders with FC5 and the minimal buildroot this weekend (Infrastructure will have someone at the colo in case of problems next week.)
  • Still on schedule to rebuild for FC5T3.
  • Control-C problem still occuring.
  • Let infrastructure have another go at finding a solution
  • Otherwise try an async notification method to make it work
  • Co-maintainership: thl will send an email this week to start discussion.
  • Packaging Committee Report:
  • PHP Guidelines at were approved with the caveat that the macros mentioned in the draft don't exist in FC5 or less (so they can only apply to FC6).
  • was ratified.
  • mjk- was accepted as a sponsor.
  • comps update:
  • Pushing comps automatically is good. Core does this right now.
  • The script that generates the comps needs to validate the xml and check that the packages are already in the repository.
  • Mailing list discussion of comps files:

  • Elections:
  • An email soliciting comments went out but didn't gather many comments.
  • Toshio will take the few comments and make a solid proposal that people can decide what they like about it.
  • Stalled reviews: tibbs is going to write up a proposal and send to the list regarding how long a review should wait for more input from either submitter or reviewer before someone else can take over/bug closed.
  • Bugzilla enhancements
  • Branching: warren proposes either using blocker bugs or bugzilla flags to indicate a package that has been reviewed should be branched for other releases. This would be better than the CVSSync needed that currently exists. Consensus built up that blocker bugs had several features that made them better than flags.
  • warren will get a mail alias that can be used for unassigned package reviews and tasks that no one is working on.
  • tibbs requested having an UNASSIGNED bugzilla state that we could move review bugs to once they were already in another state (right now our unassigned state is NEW which cannot be assigned to.)


(09:59:55) thl: k, my clock says it's time for the meeting
(10:00:05) ***c4chris is here
(10:00:08) thl has changed the topic to: FESCo meeting in progress
(10:00:13) ***dgilmore is here
(10:00:14) thl: who's around?
(10:00:17) ***bpepple is here.
(10:00:17) nirik: jcollie[work] : any chance for asterisk 1.2.10 and zaptel 1.2.7 updates? I guess you might wait and see if the kmod gets approved first tho
(10:00:21) thl: packaging comitee finished?
(10:00:24) ***scop is here
(10:00:25) ***rdieter is here
(10:00:30) ***cweyl is here (rabble)
(10:00:38) ***nirik goes and sits in the rabble seats.
(10:00:39) ***warren here
(10:00:54) jcollie[work] : nirik, yeah i have asterisk 1.2.10 packaged already and on my web site, i just haven't updated bugzilla
(10:00:55) tibbs: Packaging committee is done at this point.
(10:01:39) c4chris: abadger1999, you around?
(10:01:43) thl has changed the topic to: FESCo meeting in progress -- M[ae] ss-Rebuild
(10:01:48) thl: dgilmore, status?
(10:01:50) abadger1999: Yep.  I'm here.
(10:02:02) c4chris: cool
(10:02:18) dgilmore: thl: we need to rebuild the builders
(10:02:32) c4chris: huh?
(10:02:34) dgilmore: the hammers we dont have acces to the bios via serial cable
(10:03:02) che [n=che]  entered the room.
(10:03:10) dgilmore: i think im going to attempt upgrades using grup to boot installer  this weekend
(10:03:13) thl: dgilmore, who do we need to ask to make that happen?
(10:03:21) thl: ahh, okay
(10:03:30) dgilmore: if it messes up some how  there will be someone onsite  next week to fix them
(10:03:46) warren: dgilmore, I'll assist
(10:03:47) dgilmore: we need to setup netboot for the ppc builders
(10:03:49) thl: dgilmore, just out of interest: does that mean that we update the builders to mock one at a time?
(10:04:05) thl: dgilmore, e.g. some pacakges get build with the reduced set of default packages
(10:04:11) thl: and some others with the old set?
(10:04:14) dgilmore: thl: it means ill upgrade the os from fc3 to fc5  one at a time for the hammers
(10:04:24) ***nirik wonders if it was decided to go with RHEL or CentOS or fc5 on the builders?
(10:04:26) dgilmore: thl: yeah
(10:04:35) warren: dgilmore, RHEL4 is unsuitable for builders?
(10:04:39) tibbs: It's all fun and games until someone has to drive to the colo at 3AM.
(10:04:49) jima: tibbs: ugh, don't remind me.
(10:04:55) warren: tibbs, there is a scheduled visit next week
(10:04:56) dgilmore: warren: we can use a slightly newer yum with fc5
(10:05:01) warren: dgilmore, ah
(10:05:08) scop: RHEL4's rpm is too old -- affects "make srpm"
(10:05:12) dgilmore: no one spoke up to my postings saying i was going to install fc5  on the builders
(10:05:18) warren: FC5 is fine
(10:05:34) warren: upgrading that into RHEL5 should also be safe later
(10:05:35) rdieter: then at least, we're eating our own dog food. (:
(10:05:49) f13: scop: erm.
(10:05:54) dgilmore: scop: rhel's  rpm needs patched so that we can build more than one chroot at a time also
(10:05:54) f13: scop: whats too old about it?
(10:06:19) scop: f13, breaks for example with new valid constructs like %bcond_with
(10:06:27) f13: hrm.
(10:06:34) f13: Red Hat's buildsystems are RHEL4 based.
(10:06:43) scop: but that's really not RHEL's fault
(10:06:50) f13: so COre packages are getting srpm built w/ a slightly updated RHEL4 rpm
(10:06:58) scop: it's a fundamental problem in the buildsys
(10:07:18) nirik: plague vs brew diffrences to?
(10:07:20) scop: make srpm should be run in the target distro config
(10:07:28) f13: %bcond_with makes a difference when building the intial srpm ?
(10:07:45) scop: f13, yes, rhel4's rpmbuild chokes on it
(10:08:03) scop: while parsing the specfile
(10:08:08) f13: in Brew land, if passed a CVS url we make an srpm outside the buildroot, pass that srpm into the buildroot and remake the srpm
(10:08:19) f13: perhaps we shouldn't allow that construct for now.
(10:08:30) dgilmore: so  all 6 builders will get upgraded  to fc5  and will have mock 0.6 and plague 0.4
(10:08:40) dgilmore: they will be done one at a time
(10:08:53) warren:
(10:08:57) warren: is this error message known?
(10:09:03) dgilmore: if one of the hammers gets messed up  it will be out of commision  until next week
(10:09:10) slack_ [n=slack]  entered the room.
(10:09:23) rdieter: warren: it's been reported already (this morning) at least.
(10:09:27) scop: f13, no need to specifically rule it out IMO; if it doesn't work, the packages just won't build
(10:09:28) dgilmore: warren: the cert for the web client  must have expired
(10:09:56) jima: yeah, someone needs to download a new client certificate for the web front-end
(10:10:00) jima: (i think)
(10:10:11) warren: hmmm
(10:10:28) thl: warren, somebody should file a ticket it the otrs system
(10:10:31) f13: scop: this could be an ongoing problem though.  mock doesn't take CVS urls, it takes an srpm, so the srpm has to be generated via CVS somewhere before being handed to mock.
(10:10:41) rdieter: thl: tickets' been filed already.
(10:10:46) thl: rdieter, k
(10:10:51) thl: then let's move on
(10:10:52) scop: f13, yep
(10:11:06) thl: anything else we need to discuss now regarding mass rebuild?
(10:11:15) warren: If you're interested in the details of buildsys reinstalls, attend the infrastructure meeting later today.
(10:11:16) thl: shall we start earlier then FC6T3?
(10:11:19) scop: schedule?
(10:11:41) thl: f13, current state of libtool/binutils/gcc stuff?
(10:11:47) dgilmore: thl: I really hope  that everything is in place for start of next week
(10:11:50) f13: toolset is looking good
(10:12:02) f13: there was a large backport to gcc for java stuff.
(10:12:12) warren:
(10:12:14) f13: and a lot of java packages were rebuilt (again)
(10:12:17) thl: k, then let's see how FC6T2 works out when released
(10:12:19) warren: schedule hasn't been updated for our latest delays
(10:12:26) thl: and start soon when everything looks fine
(10:12:29) f13: warren: because we don't knwo what to update it too
(10:12:31) thl: that okay for everybody?
(10:12:37) warren: f13, nod
(10:12:57) c4chris: thl, k
(10:12:58) scop: thl, why not stick with the T3 plan?
(10:13:10) thl: scop, more time for maintainers to rebuild stuff?
(10:13:10) warren: I think T3 is a good plan
(10:13:20) dgilmore: i do have one  thing  the macros  scop wanted  added to check the buildroot if we pull  rpmdevtools  we add 2 deps  wget and rpm-python  does anyone object?
(10:13:22) thl: scop, more time to find orphans and AWOL maintainers?
(10:13:46) thl: scop, but let's wait for FC6T2
(10:13:57) thl: we can decide then when and how to proceed
(10:13:57) scop: thl, larger window for "something" to happen which requires another mass rebuild? ;)
(10:14:08) thl: scop, yeah, possible ;)
(10:14:16) warren: dgilmore, I think those two are fine.
(10:14:24) thl: well, let's move on now
(10:14:37) dgilmore: warren: i do too.
(10:14:39) thl has changed the topic to: FESCo meeting in progress -- CTRL-C problem
(10:14:47) thl: scop, ?
(10:15:00) scop: regarding Ctrl-C?  no news
(10:15:39) tibbs: I think this is going to end up unfixed until we get a new SCM.
(10:15:50) warren: *or* mail sending should be handled async
(10:16:04) abadger1999: warren: I think async is the way to go.
(10:16:05) thl: tibbs, we should at least try once more to get it fixed
(10:16:25) thl: warren, abadger1999, can you poke the infrastructure guys again?
(10:16:30) warren: thl, yup
(10:16:33) drpixel [n=drpixel]  entered the room.
(10:16:36) thl: warren, k, thx
(10:16:43) tibbs: thl: You're right, of course, but I think it's a lack of time among those with access.
(10:16:50) thl has changed the topic to: FESCo meeting in progress -- Co-maintainership
(10:17:03) thl: I hope to send a mail to the list this weekend
(10:17:09) abadger1999: Sopwith is going on an extended vacation though, we'll have to get someone new to pick up where he left off.
(10:17:11) thl: so I'll moving on now
(10:17:21) thl has changed the topic to: FESCo meeting in progress -- IPv6 Support in Extras
(10:17:30) thl: skipping as well -- jwb still on vacation
(10:17:39) thl has changed the topic to: FESCo meeting in progress -- Packaging Committee Report
(10:17:48) thl: scop ?
(10:17:55) tibbs: spot is away at the moment.
(10:18:11) scop: not very productive packaging meeting today
(10:18:11) tibbs: We took up two issues:
(10:18:20) scop: tibbs, go ahead ;)
(10:18:31) tibbs: sorry, I get spot and scop mixed up for some reason.
(10:18:59) tibbs: We voted on PHP guidelines and agreed on the current draft.
(10:19:15) tibbs:
(10:19:43) tibbs: So it's passed to FESCo and FAB for ratification.
(10:20:20) scop: open issue: macros specified in the draft do not exist yet in FC5
(10:20:38) warren: I don't know much about PHP, but I trust the judgement of the package committee members, so +1.
(10:21:02) c4chris: Is the %build section required ?
(10:21:12) ***thl didn't ready the PHP stuff yet, but trusts the package committee members, too, so +1 as well
(10:21:15) tibbs: Yes, the macros are currently in updates-testing.  The draft will get some info about targeting releases that don't have the necessary macros so that FC4 and RHEL don't get left out.
(10:21:30) dgilmore: +1 also
(10:22:10) thl: tibbs, scop, anything else?
(10:22:11) tibbs: c4chris: The guidelines don't cover the necessity of a %build section.  (Nor did they ever.)
(10:22:14) c4chris: Is the "php >= current" resolved ?
(10:22:19) abadger1999: c4chris: %build is not mentioned yay or nay in the Draft
(10:22:35) tibbs: We also took up the issue of the ScriptletSnippets page.
(10:22:51) thl: tibbs, scop, btw I think we don't need to vote here on things the package committee decided
(10:22:55) scop: %build is not at all specific to PHP
(10:22:56) c4chris: tibbs, abadger1999: k, no biggie, just curious
(10:23:11) thl: I think you guys should announce here what happened
(10:23:16) c4chris: scop, right
(10:23:19) tibbs: Which was accepted as a guideline; the TODO bits have been removed and the guideline will be further revised to flesh it out a bit.
(10:23:30) thl: and as long as no one yells in the next 7 days they are approved by fesco
(10:23:34) thl: that okay for everybody?
(10:23:38) bpepple: thl: +1
(10:23:38) scop: right
(10:23:48) c4chris: thl, +1
(10:24:01) abadger1999: thl: +1
(10:24:04) cweyl: thl: and if someone yells, then ratification is formally taken up at the next fesco meeting?
(10:24:24) scop: there's no process for that ;)
(10:24:32) thl: cweyl, yes, that how it should work IMHO
(10:24:38) warren: who is "someone"?
(10:24:40) cweyl: scop: now there is ;)
(10:24:42) warren: *anybody* out there?
(10:24:47) warren: or a cvsextras member?
(10:24:47) thl: warren, someone from FESCo
(10:24:48) warren: oh
(10:24:49) scop: cweyl, but it doesn't work :)
(10:24:57) cweyl: scop: why not?
(10:25:02) thl: warren, eyerbody can yell on fedora-packaging in any case
(10:25:05) scop: because fesco is not the only interest group
(10:25:07) thl: if he wants to
(10:25:32) cweyl: scop: right.  but just because others have interest too doesn't diminish fesco's interest
(10:26:08) c4chris: what was the second issue?
(10:26:09) thl: scop, so what do you suggest?
(10:26:14) scop: cweyl, right, but if someone from fedora advisory board or rh(el) engineering yells, there's no point even trying to take that up in fesco
(10:26:36) rdieter: c4chris: ScriptletSnippets
(10:26:43) tibbs: The second issue was the ratification of ScriptletSnippets as a guideline.
(10:27:03) cweyl: scop: right, but that's not what I was suggesting :)  if someone on fesco sees a reason to discuss it, then fesco should...  right?  other people have other orgs to yell at :)
(10:27:04) c4chris: oh right
(10:27:10) ***thl will be afk for some minutes in round about 5-10 minutes from now
(10:27:55) dgilmore: tibbs: some of the current scriptlets  are wrong
(10:28:07) scop: well, shrug
(10:28:17) dgilmore: namely  they are ok for gnopme gtk  apps but wrong for kde ones
(10:28:27) tibbs: dgilmore: Please do provide details.
(10:28:49) scop: I think resolving the results of potential yelling is the job of the fedora board
(10:29:05) thl: dgilmore, please bring that to fedora-packaging-list
(10:29:11) rdieter: dgilmore: they're not wrong, just useless extra work.  (:
(10:29:14) thl: otherwise we'll run out of time here
(10:29:21) dgilmore: rdieter: yeah
(10:29:32) scop: (plus a dependency on gtk2?)
(10:29:34) thl: scop, only where there are realy problems that can't get solved by a normal discussion
(10:29:39) abadger1999: c4chris, tibbs: Hmm... versioned php was not resolved.  (Left open in the guideline.  Probably need to resolve that in the next packaging meeting.)
(10:29:47) thl: I don#t think such "real problems" will show up to often
(10:29:48) rdieter: scop: yep. (:
(10:30:31) tibbs: That is pretty much it for the packaging committee.
(10:30:53) thl: Do we want to discuss this further now or simply move on for today and discuss and find a solution on the lists (or in the next meeting)?
(10:31:04) rdieter: scop: I take that back (no deps are added now)
(10:31:13) dgilmore: thl: move on
(10:31:19) rdieter: thl: move on, lists...
(10:31:23) dgilmore: tibbs: ill ping you about it latter
(10:31:33) thl has changed the topic to: FESCo meeting in progress -- Weekly sponsorship nomination
(10:31:43) thl: mjk- was nominated
(10:31:46) warren: +1
(10:31:48) bpepple: +1
(10:31:51) tibbs: +1
(10:31:52) c4chris: +1
(10:31:52) scop: +1
(10:31:52) thl: sevewral sponsors voted +1
(10:31:53) rdieter: +1
(10:32:03) abadger1999: abadger1999: Already voted +1 on cvsextras
(10:32:03) thl: there are a lot of +1 here, too :)
(10:32:10) warren: OK, so done.
(10:32:15) thl: so mjk- is accepted
(10:32:29) thl: any other nominations we want to discuss now?
(10:32:34) jima: man, progress here is _slow_. ;)
(10:32:55) c4chris: I think Nodoid is also candidate
(10:33:17) c4chris: (if I got the IRC nick right)
(10:33:29) thl: well, I agree with what was discussed on the lists
(10:33:36) warren: I think Nodoid's intentions are in the right place, but his first review was not too long ago, and this is a little premature.
(10:33:44) thl: we'd like to see some more work for him before we make him a sponsor
(10:33:46) bpepple: warren: +1
(10:34:01) ***thl afk now
(10:34:07) abadger1999: warren: +1
(10:34:19) thl: can you guys please at least discuss comps and elections?
(10:34:23) warren: ok
(10:34:31) dgilmore: +1
(10:34:31) thl: warren, can you take care of the meeting from now on?
(10:34:42) thl: I'll skim in now and then
(10:34:44) warren: Let's re-evaluate this candidate again in a few weeks after more review examples.
(10:34:53) c4chris: warren, k
(10:35:12) bpepple: sounds good.
(10:35:25) warren: what did he mean by comps?
(10:35:40) warren:  unclear based on our agenda
(10:35:53) c4chris: we need some guidelines what to put in comps.xml
(10:36:02) c4chris: all packages ?
(10:36:10) warren: scop, would it be appropriate to discuss kmod approval now, or we don't have enough people?
(10:36:11) tibbs has changed the topic to: FESCo meeting in progress -- Comps
(10:36:12) _wart_: ...and automate the pushing of the comps files
(10:36:15) c4chris: all sub-packages ?
(10:36:41) bpepple: c4chris: Is there anything on the wiki about the comps.xml?
(10:36:43) scop: warren, I'm not quite up to date what's queued and ready for discussion
(10:36:48) warren: why is comps not listed here?  I don't know the full context of this problem.
(10:36:52) warren: scop, ok, next week then?
(10:36:57) scop: warren, works4me
(10:37:00) c4chris: bpepple, well, that's the problem: I don't think so...
(10:37:03) dgilmore: warren: currenlt its manually updated
(10:37:18) abadger1999: _wart_: Did you get any work done with comps this week?
(10:37:19) tibbs: Can we agree that it should be automated if possible?
(10:37:21) dgilmore: we want to set something up so that it gets  pushed automatially when its updated
(10:37:25) warren: dgilmore, that's how Core comps is done too.
(10:37:32) warren: oh
(10:37:33) warren: hm
(10:37:55) _wart_: abadger1999:  I talked with jkatz about the process of generating the comps file.
(10:38:14) warren: Core comps is updated manually, then put through the script to expand with all translations, and that is used to build trees and put in repodata.
(10:38:23) _wart_: It's  pretty straightforward, but I still need to figure out the best way to tie it into the push script
(10:38:43) warren: We also need to be sure that the automated process validates it, so it does'nt break stuff.
(10:38:48) dgilmore: we were thinking either a cron job  that checks daily or hourly  and updates if need be  or  add it to the push process if needed  but would rather do it seperate  so as to not extend the time taken to do a push
(10:39:02) scop: _wart_, ping me if you need opinions or help, I know the scripts pretty well
(10:39:04) _wart_: warren:  Right.  we can use xmlwf to validate it.
(10:39:21) _wart_: scop: Will do, probably in the next couple of days.
(10:39:24) spot [n=spot]  entered the room.
(10:39:25) warren: Does it need to be in the push script?
(10:39:37) dgilmore: warren: i think its better not
(10:39:41) warren: can it be async, and send out e-mail if validation fails?
(10:39:46) warren: better async, I think.
(10:39:50) dgilmore: just so that it doesnt extend  push window
(10:39:52) scop: well, personally I would love it if repoview and comps and stuff like that would be run completely outside of the scripts
(10:40:19) warren: If possible we should keep things outside of the push script that would slow it down, especially if it can be done async.
(10:40:31) scop: but I suppose comps is a matter of seconds so that's a non-issue
(10:40:33) _wart_: The comps file generation takes seconds to finish.
(10:40:35) tibbs: Do we know what should go into comps?  SRPM name or list out all of the subpackages?
(10:40:35) dgilmore: scop: we could quite easily do that  have a  say 6 hourly  cron job  that does a check for update  if there is it runs if not its done
(10:40:50) abadger1999: bpepple, c4chris: comps discussion from mailing lists (Put this on the wiki?):
(10:40:50) abadger1999:
(10:40:50) abadger1999:
(10:40:55) scop: dgilmore, yes, and we're already doing that in other projects
(10:41:15) tibbs: Is there a possibility that comps would be updated before the packages have been pushed?  If so, what breaks when that happens?
(10:41:16) scop: (that == repoview there)
(10:41:16) _wart_: Or we could try to tie it into a cvs commit script to validate and generate the comps files.
(10:41:35) dgilmore: it just might mean that packages are not in repodata for a few hours after a package push
(10:41:51) scop: dgilmore, s/repodata/repoview/
(10:42:05) dgilmore: scop: yah
(10:42:25) c4chris: abadger1999, yes, that'd be a start...
(10:42:26) scop: but it could be cron'd every 10 minutes
(10:42:31) tibbs: Won't that break installations, if you select a group where a package is not available?  I recall a time when that was the case.
(10:42:42) scop: it takes seconds to determine if rebuilding it is needed or not
(10:43:58) dgilmore: tibbs: a package will always be available
(10:44:48) dgilmore: tibbs: my bad  maybe not always
(10:45:31) tibbs: dgilmore: I build a new package and add it to comps.  Comps gets updated by cron but the package push doesn't happen for another 12 hours.  What does the installer do?
(10:45:58) devrimgunduz left the room (quit: "Leaving").
(10:45:59) dgilmore: but we could put a check in the scipt  that checks the time of the comps  compared to the repodata  if comps is newer then  we dont rebuild
(10:46:27) tibbs: At that point we might as well just do it as part of the push.
(10:46:46) _wart_: tibbs:  +1, especially since it's a pretty quick process anyway
(10:47:15) _wart_: The push script could avoid generating the comps file if any validation tests fail on it.
(10:47:22) abadger1999: tibbs: Won't we still have possible race conditions?
(10:47:25) _wart_: and email a notice to <some list>
(10:47:35) abadger1999: I submit the build and update comps at the same time.
(10:48:07) abadger1999: Build fails or push is made before the job completes?
(10:48:32) ***Sopwith returns.
(10:48:36) xris [n=xris]  entered the room.
(10:49:07) tibbs: abadger1999: In that case, I could just typo something in comps.
(10:49:19) tibbs: So the real question is, what breaks when this happens?
(10:49:37) dgilmore: so the scipt  should check the additions  and see if its in the tree
(10:49:39) tibbs: I think we need to talk to the installer people.  And the yum devs.
(10:49:44) scop: how about just generating comps.xml from the Group tags of packages being pushed? ;)
(10:49:44) dgilmore: if not  no comps  built
(10:49:56) abadger1999: dgilmore: Yep.
(10:49:57) c4chris: scop, argh :)
(10:50:12) skvidal: tibbs: talk to us about what?
(10:50:15) abadger1999: scop: Been proposed before! :-)
(10:50:24) dgilmore: scop: cause a package could be in more than one group in comps
(10:50:41) dgilmore: but only has one group in spec
(10:50:45) scop: (in case everyone didn't notice, the smiley was there for a reason)
(10:51:15) dgilmore: bbs  need lunch
(10:51:39) tibbs: skvidal: Does yum care if comps lists packages that don't exist?
(10:51:54) skvidal: no, it doesn't
(10:52:31) tibbs: So that leaves the installer.
(10:52:39) _wart_: tibbs:  In fact, for a while there were several packages in comps that didn't exist.
(10:52:59) scop: hm
(10:53:13) scop: "the installer"?
(10:53:21) scop: anaconda handles FE too?
(10:53:31) tibbs: In FC6 it does.
(10:53:37) scop: woo
(10:53:41) c4chris: Jeremy Katz said: "the primary use is with a GUI, selecting a lot of text-mode things make little sense."
(10:53:55) c4chris: is this still true?
(10:54:07) ***thl back for some minutes
(10:54:14) c4chris: or is comps.xml used for more things now?
(10:54:39) thl: warren, sorry, comps was not really on the schedule yet but I knew at least someone (tibbs?) wanted to talk abouti t
(10:54:48) thl: and it should be on the schedule
(10:54:55) jeremy: yes, it's still true (I'm halfway here, see!)
(10:54:59) thl: or was it c4chris? well, not important
(10:55:03) tibbs: thl: 't wasn't me.
(10:55:12) c4chris: 'was me :)
(10:55:27) tibbs: The games SIG for one tries to keep comps updated.
(10:55:40) thl: a lot of people ignore it
(10:55:51) thl: I for example never touched it
(10:55:53) ***thl hides
(10:55:55) tibbs: We want people to be able to install the Games group and have loads of games pop in.
(10:56:22) c4chris: ok, but what's the plan for the future?
(10:56:24) ***nirik has used it for 'groupinstall XFCE'
(10:56:34) thl: c4chris, someone should probably work out a plan
(10:56:37) cweyl: yeah, the groupinstall bit is nice
(10:56:46) thl: c4chris, can you handle that?
(10:56:54) thl: c4chris, dgilmore probably will help with the scripts
(10:57:02) c4chris: my understanding was that the Group tag should be deprecated
(10:57:19) skvidal: s/deprecated/obliterated/
(10:57:24) c4chris: and that we put all bits that people *want* to install in comps somewhere
(10:57:39) tibbs: No argument here.
(10:57:44) thl: c4chris, I though all packages must be in comps for anaconda/pirut?
(10:57:45) c4chris: preferably in well thought out groups
(10:58:11) c4chris: thl, that's teh part I don't know and am trying to find info about...
(10:58:27) thl: jeremy, f13 ?
(10:58:39) thl: do all packages need to be in comps now?
(10:58:39) tibbs: Yes, I recall hearing that you couldn't install something from anaconda unless the package shows up in comps or you're using a kickstart file.
(10:58:53) Seg: The media production SIG is going to have to take on comps eventually. I'm waiting until we get more applications in personally.
(10:58:55) jeremy: thl: not all packages... if it's a package that's "interesting" to be visible, then you want it in comps, yes
(10:59:55) thl: jeremy, well, then probably nearly all extras packages need to be in comps
(11:00:01) c4chris: jeremy, so in short: what people *want* must be in comps, all the deps need not
(11:01:21) c4chris: tis going to be interesting to script a definition of "interesting" ... :)
(11:01:40) thl: well, can sombody work out a rough plan until the next meeting?
(11:01:42) thl: c4chris ?
(11:01:54) c4chris: thl, k I'll work out something
(11:02:08) thl: c4chris, tia
(11:02:17) dgilmore: c4chris: ill give you a hand if you need it
(11:02:19) thl: do we want to talk about the election?
(11:02:24) thl: got late...
(11:02:26) c4chris: dgilmore, k, thanks
(11:02:29) jeremy: c4chris: right.  and I don't think that comps can be scripts
(11:02:31) thl: abadger1999, do you need further input?
(11:02:33) jeremy: scripted
(11:02:44) jeremy: thl: libraries don't need to be.  -devel subpackages don't generally need to be
(11:02:54) thl: jeremy, ahh, okay
(11:02:56) abadger1999: Well, the mail went out.  Not many comments.
(11:03:25) abadger1999: Sopwith's comments about not over democracising things I think have merit.
(11:03:43) c4chris: jeremy, I kinda agree, but I think some rough checks can be automated
(11:03:46) abadger1999: But are balanced against needing to bring in new blood.
(11:04:02) drpixel left the room (quit: Read error: 104 (Connection reset by peer)).
(11:04:19) drpixel [n=drpixel]  entered the room.
(11:04:25) thl has changed the topic to: FESCo meeting in progress -- elections
(11:04:41) abadger1999: Since there weren't many comments, I tend to think people aren't too concerned with the current direction.
(11:04:46) c4chris: new blood is good, when it's found...
(11:04:58) thl: abadger1999, you probably should work out a proposal and send it to the list
(11:05:03) thl: if no one yells
(11:05:10) thl: and if is seems okay for FESCo
(11:05:13) thl: we'll go for it
(11:05:29) thl: abadger1999, decide things just how you thing they should work
(11:05:35) abadger1999: Yep.  I'll take my questions from the email and just pretend I have answers :-)
(11:05:41) thl: if there are things you don't want to decide mention them in the proposal
(11:05:52) thl: abadger1999, great :-)
(11:05:57) thl: k, moving on
(11:06:03) warren: abadger1999, which email was this?
(11:06:04) thl has changed the topic to: FESCo meeting in progress -- free discussions
(11:06:15) thl: anything else that needs to be discussed?
(11:06:15) tibbs: Did we want to talk about kernel modules?
(11:06:18) abadger1999: Sent to fedora extras on Monday.  Let me scan the archives.
(11:06:37) thl: tibbs, no, I didn#t get any request for modules...
(11:06:37) warren: tibbs, scop wanted to defer that for next week, he's behind on study.
(11:06:40) abadger1999: warren:
(11:06:43) tibbs: There was an update on the zaptel module.
(11:07:09) thl: tibbs, k, I'll look at it and forward it to fesco list for discussions
(11:07:19) tibbs: OK, then I'd like to discuss a policy for dealing with stalled reviews.
(11:07:25) scop: I didn't *want* to defer it, but I don't have much to contribute to that right now
(11:07:54) thl has changed the topic to: FESCo meeting in progress -- stalled reviews (tibbs)
(11:08:03) tibbs: Note that I wasn't talking about packaging standards, just the usual voting on acceptability of particular kernel modules.
(11:08:07) tibbs: About reviews.
(11:08:27) tibbs: I was just thinking of a quick policy for how long to wait on stalled things.
(11:08:47) tibbs: If the reviewer doesn't respond for N weeks, ping and after a week someone else can take over.
(11:08:59) tibbs: If the submitter doesn't respond for N weeks, ping and after a week the bug gets closed.
(11:09:03) tibbs: That kind of thing.
(11:09:04) ***scop needs to go now, ttyl
(11:09:14) c4chris: N=8 should be plenty
(11:09:14) bpepple: Doesn't sound like a bad idea.
(11:09:17) thl: tibbs, just work out a proposal and post to the list for discussion
(11:09:27) thl: N=6 would be okay for me, too
(11:09:35) tibbs: thl: that's the plan but I figured I'd get a soinding.
(11:09:40) tibbs: sounding.
(11:09:43) scop left the room ("Leaving").
(11:09:52) c4chris: good vibrations here :)
(11:09:55) tibbs: I was thinking about N=4, personally.
(11:10:04) thl: N=4 would be okay for me, too
(11:10:14) c4chris: sure
(11:10:19) tibbs: Honestly if I don't see a comment from a package submitter for a month, I'm not sure I want them maintaining packages.
(11:10:27) tibbs: Unless they're on vacation, of course; that's reasonable.
(11:10:49) abadger1999: Vacation of 1 month plus catching up on email afterwards...
(11:10:56) thl: tibbs, sounds okay
(11:10:59) tibbs: But it would still be nice if they indicated that they're going away.  It's good practise for actually being a maintainer.
(11:11:08) c4chris: abadger1999, wow I'd like that :)
(11:11:12) tibbs: Anyway, I'll write something up and send it to extras-list for discussion.
(11:11:17) thl: tibbs, tia
(11:11:20) bpepple: abadger1999: Yeah, I agree since I just got back from a 3 week vacation.
(11:11:35) abadger1999: c4chris: I'd like that too except for the email part ;-)
(11:11:39) thl has changed the topic to: FESCo meeting in progress -- free discussion around extras
(11:11:55) c4chris: precisely :)
(11:11:58) thl: k, anything else?
(11:11:59) warren: heh
(11:12:18) warren: oh!
(11:12:24) warren: I had an idea about CVS branching
(11:12:28) warren: to streamline the system
(11:12:41) dgilmore: bpepple: I had 3 weeks earlier this year
(11:13:12) bpepple: dgilmore: Yeah, it's real hard to get caught up on all the activities that went on in FE while your gone.
(11:13:27) warren: Basically, I think Bugzilla flags would be a better way of doing it.
(11:13:44) thl: warren, yeah, sounds like a good idea
(11:14:17) warren: It would be a field to change in the bugzilla form of the review itself
(11:14:24) warren: and a query can show all branches that need doing
(11:14:31) c4chris: warren, you mean: tick a few checkboxes when you close the accepted review request ?
(11:14:40) tibbs: warren, FE-BRANCH-FC5 ?
(11:14:45) warren: no, bugzilla flags
(11:14:50) warren: oh
(11:14:57) warren: I hadn't considered a blocker bug, that would work too
(11:15:00) warren: hmm
(11:15:04) warren: blocker bug might be better actually
(11:15:27) cweyl: warren: everything else being equal, it's how we track just about everything else in BZ...
(11:15:35) warren: anyway I'll analyze both options and post to extras list soon about it.
(11:15:36) thl: FE-ACCEPT-BRANCHPLEASE ;-)
(11:15:40) tibbs: It does have the bonus of not needing any changes to any infrastructure.
(11:15:47) _wart_: Will the bugzilla-branch-request allow a developer to add these requests after the bug has been closed?
(11:15:49) thl: warren, k, thx
(11:16:00) _wart_: ie:  Sometimes I don't want to request a new branch until after it's imported and built on devel.
(11:16:02) warren: _wart_, good point
(11:16:12) tibbs: But if we have the power to get new things into bugzilla, it would be nice to consider an UNASSIGNED state.
(11:16:16) warren: blocker bug would allow that, flags would make it ambigous
(11:16:18) warren: ambiguous
(11:16:30) warren: Oh, another thought.
(11:16:36) tibbs: You can add blockers to closed bugs no problems.  And you get email notification for free.
(11:16:42) warren: Mozilla Bugzilla has a
(11:16:56) warren: if something is clearly orphaned and nobody is working on a problem, it is assigned there.
(11:17:05) warren: I think that would be useful for us.
(11:17:11) warren: for both Core and Extras
(11:17:17) warren: hmm... probably best for FAB?
(11:17:26) thl: reviews could be assigned to that users initially, too
(11:17:36) thl: s/users/user/
(11:17:39) tibbs: I don't see why it doesn't just happen.
(11:17:44) warren: more appropriate than the Thorsten blackhole =)
(11:17:57) thl: warren, yes, really :-)
(11:18:12) tibbs: The thl blackhole has done like 13 reviews.
(11:18:18) warren: OK, should we just create a account?
(11:18:22) thl: warren, +1
(11:18:26) warren: +1
(11:18:27) bpepple: warren: +1
(11:18:31) c4chris: warren, +1
(11:18:40) tibbs: +1 Please just do it.
(11:18:47) abadger1999: +1
(11:18:51) warren: Who runs the MTA of
(11:19:04) thl: don't know -- skvidal ?
(11:19:11) warren: I'll follow up on this
(11:19:12) warren: k
(11:19:15) warren: that's all
(11:19:26) thl: k, then let's clode the meeting for today
(11:19:31) thl: if no one objects
(11:19:38) ***thl will close the meeting in 20
(11:19:46) drpixel left the room (quit: Read error: 104 (Connection reset by peer)).
(11:19:48) ***thl will close the meeting in 10
(11:19:59) thl: -- MARK -- Meeting end
(11:20:04) thl: thx everyone!