FESCo Meeting Minutes 2006-07-27

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



2006 July, 27 FESCo Meeting
===========================

Meeting Summaries are posted on the wiki at:

  http://www.fedoraproject.org/wiki/Extras/SteeringCommittee/Meetings

Attending
---------
 * thl
 * c4chris
 * dgilmore
 * bpepple
 * scop
 * rdieter
 * warren
 * tibbs
 * abadger1999
 * jeremy

Summary
-------
 * 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::
     http://www.fedoraproject.org/wiki/PackagingDrafts/PHP
     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).
   - http://www.fedoraproject.org/wiki/PackagingDrafts/ScriptletSnippets
     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::

https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00956.html


https://www.redhat.com/archives/fedora-extras-list/2006-April/msg01029.html
 * 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 nobody@xxxxxxxxxxxxxxxxx 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.)

Log
---
::

(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:
http://buildsys.fedoraproject.org/build-status/index.psp
(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: http://fedoraproject.org/wiki/Core/Schedule
(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:39) f13: OUTLOOK HAZY, TRY AGAIN LATER
(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: http://fedoraproject.org/wiki/PackagingDrafts/PHP
(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: http://fedoraproject.org/wiki/Extras/Schedule
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:
https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00956.html
(10:40:50) abadger1999:
https://www.redhat.com/archives/fedora-extras-list/2006-April/msg01029.html
(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:
https://www.redhat.com/archives/fedora-extras-list/2006-July/msg00769.html
(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 nobody@xxxxxxxxxxx 
(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 nobody@xxxxxxxxxxxxxxxxx
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 fedoraproject.org?
(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!

Attachment: signature.asc
Description: This is a digitally signed message part

-- 
fedora-extras-list mailing list
fedora-extras-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-extras-list

[Index of Archives]     [Fedora General Discussion]     [Fedora Art]     [Fedora Docs]     [Fedora Package Review]     [Fedora Desktop]     [Big List of Linux Books]     [Yosemite Backpacking]     [KDE Users]

  Powered by Linux