FESCo Meeting Logs 2006-12-21

Toshio Kuratomi a.badger at gmail.com
Wed Dec 27 19:06:54 UTC 2006


= 2006 December 21 FESCo Meeting =

== Members ==

=== Present ===
 * thl
 * bpepple
 * tibbs
 * warren
 * ch4chris
 * abadger1999 
 * dgilmore
 * spot
 * awjb
 * rdieter (late)
 
=== Absent ===
 * jwb
 * jeremy
 * scop
  
== Summary ==
 
=== EPEL ===
 * warren: We internally talked about providing the entire RHEL5 and
various levels of stack products on top of it to the EPEL buildsys.
And multiple trees and channels of EPEL can be built into repos
automatically based upon which dependencies they pulled in during build,
or comps.
  * CentOS should have access to the additional stack products as well
so Fedora conributers should still be able to test and develop against
CentOS.
 * Still waiting for mirror space before pushing packages live.
 * disttag again.  RH support currently works from rpm -qa lists of
packages.  So .el5 would confuse support.
  * Work needs to happen on tools to show NEVR.arch VendorName and
GPGStatus.  That will allow support to stop depending on disttag.
  * f13 has no problems with this now.
  * spot still considers it an abuse of the disttag: disttag is supposed
to identify which distribution the package is built for.  he thinks
other repositories may start using disttag similarly if we start to do
this.
  * Can we have .epel5 and .el6 (so tools have a chance to get better).
   * Only if NEVR bumps properly between RHEL5 and RHEL6.
   * This could be confusing to users of the repositories.
  * Vote: Use .epelX as disttag
   * +1: warren
   * -1: spot
   * 0: thl, c4chris, awjb, tibbs, abadger1999
 *  warren: Another issue, we also discussed opportunities for RH
engineers to participate in EPEL in formal ways.  For example, there
were some cool tools for Xen or Selinux management that were too late to
make it into RHEL5.  They would be great in EPEL5.

=== FESCo Workflow ===
 * thl starts discussion by noting that EPEL progress has been slow and
in some ways is not well communicated.  Is this a general issue for
FESCo?
 * Things get discussed and forgotten and have to be discussed again.
 * Communication and drivers:
  * EPEL decision to open branching for sponsors and people with 5+
packages was not announced.
  * Do we need to enumerate the responsibilities of a driver for an
issue?
   * Make sure progres is being made on an issue.
   * Recruit people to do work for the issue.
   * Working on it yourself.
 * tibbs: I never saw FESCo's job as being one that would produce any
huge changes.  Perhaps I'm just aiming too low, but I think the current
level of progress is amazing.
 * cweyl: FESCo is in certain respects glue, not gasoline :)
  * FESCo provides guidance and helps to facilite people who have the
time and energy to drive a project.
 * Accomplishments:
  * Extras methodology has subsumed Core.
 * Some of FESCo projects interface with Infrastructure.  Perhaps we
need better coordination there.
 
=== Opening Core ===
 * This is official and will happen.  However, Red Hat people who are
working on things from the Core end are on vacation due to the holidays.
 * FESCo's role in the new Core will be clearer as we close in on
FUDCon/Fedora Hackfest.
 * warren is working on an announcement for Core packagers to start
getting their packages into the review queue.
 
=== Comaintainers ===
 * initialcc is working.
 * If you have ideas, add them on
http://www.fedoraproject.org/wiki/Extras/Schedule/EncourageComaintainership
 * Discussion should go to fedora-extras-list.
 
=== Rebuilds ===
 * tibbs pushed a bunch of python packages.
  * tibbs: Most of the stuff that's left needs actual work due to API
differences.
 * New updates system from lmacken may make it easier to catch changes
to major components sooner.
 * nirik will send a list of EVR problems in Core package to jeremy.
 
=== Packaging Committee Report ===
 * Report went to the list.
  * iconcache has been vetoed by Core and is withdrawn for further
revisions.
  
=== Maintainer Responsibility ===
 * bpepple will solicit feedback on fedora-extras-list for what's on the
wiki.
 * Builders for FC <= 4 are still set to be closed on Jan 1.
 
=== Free Discussion ===
 * clement issue: Package has not been updated yet.  We'll step in and
fix it after the meeting.
  * rdieter to take a "No yum repo files in packages" rule to the
Packaging Committee.
 * Possibly create a make clone-branch command that can safely replace
cvs-import for updating branches.
 * nirik: FYI, I see extras has 980 bugs open. Of those 611 are in the
NEW state. Thats 62% where no one has stepped up and assigned the bug to
themselves.
 
== Log ==
{{{
(10:00:10 AM) thl has changed the topic to: FESCo meeting -- Meeting
rules at [WWW]
http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines --
Init process
(10:00:13 AM) thl: FESCo meeting ping -- abadger1999, awjb, bpepple,
c4chris, dgilmore, jeremy, jwb, rdieter, spot, scop, thl, tibbs, warren
(10:00:16 AM) thl: Hi everybody; who's around?
(10:00:17 AM) ***bpepple is here.
(10:00:22 AM) tibbs: I'm here.
(10:00:24 AM) warren: here
(10:00:25 AM) ***c4chris is here
(10:00:29 AM) ***abadger1999 here
(10:00:47 AM) ***dgilmore is kinda here
(10:00:49 AM) thl: jwb said he'll be afk
(10:00:50 AM) dgilmore: mostly not 
(10:00:56 AM) thl: mmcgrath ?
(10:01:25 AM) thl: seems not
(10:01:31 AM) thl has changed the topic to: FESCO-Meeting -- EPEL --
mmcgrath, dgilmore -- status update
(10:01:43 AM) thl: dgilmore, could you give a quick status update?
(10:01:44 AM) ***spot is here
(10:01:46 AM) ***awjb is here
(10:01:52 AM) thl: otherwise we'll simply skip epel
(10:02:10 AM) thl: (that would mean yet another week without real
progress for EPEL)
(10:02:11 AM) thl: :-(
(10:02:17 AM) ***c4chris got yum to run on my ia64 box
(10:02:33 AM) warren: I have EPEL news.
(10:02:38 AM) c4chris: next is mock, then plague...
(10:02:57 AM) thl: warren, shoot
(10:03:02 AM) c4chris: then see how to integrate it with the rest (if at
all possible...)
(10:03:14 AM) warren: We internally talked about providing the entire
RHEL5 and various levels of stack products on top of it to the EPEL
buildsys.
(10:03:39 AM) devrimgunduz [n=Devrim] entered the room.
(10:03:40 AM) ***mmcgrath is here
(10:03:43 AM) mmcgrath: sorry.
(10:03:44 AM) warren: And multiple trees and channels of EPEL can be
built into repos automatically based upon which dependencies they pulled
in during build, or comps.
(10:03:57 AM) mmcgrath: I think we're still waiting on notting and the
mirror space.
(10:04:07 AM) warren: Oh, there was another issue.
(10:04:33 AM) warren: Red Hat officially requests that .epelX be used as
a disttag.  The reasons for this have changed slightly.
(10:04:43 AM) warren: Jesse has changed his mind and supports this.
(10:04:52 AM) ixs: warren: sounds good. only problem I'm still seeing
there, the packagers might not have the whole stack available for
testing purposes, depending on how good the rebuilds are coming along.
Do you see a potential problem with that?
(10:05:10 AM) warren: ixs, not if CentOS does so.
(10:05:25 AM) warren: ixs, in any case, CentOS and users today are not
using most of that stack at all, will it really be missed?
(10:05:26 AM) mmcgrath: warren: is it fine with RH if we have no dist
tag at all on some packages?
(10:05:36 AM) ixs: warren: I'm no centos guy but last time I checked,
they were not even sure themselves how they are offering the stack.
(10:05:36 AM) c4chris: so we build against CentOS ?
(10:05:39 AM) warren: mmcgrath, good question.
(10:05:41 AM) mmcgrath: Namely the ones that don't specify a dist
tag :-)
(10:05:44 AM) warren: mmcgrath, it works like this:
(10:05:53 AM) warren: No disttag: fine in both RHEL5 and EPEL5.
(10:06:06 AM) warren: disttag: .el5 in RHEL5, .epel5 in EPEL5
(10:06:20 AM) thl: c4chris, the packages should be usable on centos;
without that the whole stuff IMHO does not make to much sense for us
(10:06:23 AM) ***spot is still against this
(10:06:27 AM) ixs: warren: but I always thoguth that the whole stack
(cluster, devel et al) is at least available for centos4
(10:06:44 AM) c4chris: thl, makes sense
(10:06:54 AM) warren: The legal, product and support guys were more
worried about claiming ".el5" and what that implies.
(10:07:10 AM) warren: because support especially works from rpm -qa
style lists, not deeper queries.
(10:07:34 AM) cgTobi_away [n=cgTobi] entered the room.
(10:07:34 AM) ixs: sounds sensible IMHO.
(10:07:40 AM) warren: We also talked about improving future tools to
mitigate this problem, some tool that outputs listings like:
(10:07:48 AM) ixs: no sense making work for support harder then it is.
(10:07:48 AM) warren: N-V-R VendorName GPGStatus
(10:07:57 AM) cgTobi left the room (quit: Nick collision from
services.).
(10:08:01 AM) c4chris: then I can set my ia64 builder to build using
CentOS I guess...
(10:08:05 AM) warren: foo-1.0-2.el5  Red Hat OK
(10:08:09 AM) thl: c4chris, nope
(10:08:13 AM) warren: bar-2.0-3.epel5  EPEL  OK
(10:08:30 AM) thl: c4chris, that will just confuise everything; we can't
build some archs on rhel and others on centos
(10:08:33 AM) warren: listing tools would do this, and GUI tools would
also do it
(10:08:33 AM) warren: oh
(10:08:37 AM) warren: N-V-R.arch
(10:08:54 AM) c4chris: thl, so th eother ones use RH ?
(10:09:01 AM) thl: c4chris, yes
(10:09:01 AM) warren: We suspect a combination of improving these tools
plus unique disttags will help in support differentiation.
(10:09:04 AM) c4chris: s/th e/the /
(10:09:11 AM) c4chris: hmm
(10:09:16 AM) abadger1999: warren: Re: "providing the entire RHEL5 and
various levels of stack products on top of it "  Will CentOS have access
to those additional stack products?
(10:09:27 AM) warren: Red Hat does not *require* that EPEL accepts this.
(10:09:39 AM) warren: abadger1999, I think so, I will need to ask.
(10:09:41 AM) spot: abadger1999: they're all available in SRPM format,
so they should be able to make their own bits
(10:09:45 AM) warren: abadger1999, it might be required for GPL
compliance
(10:09:54 AM) c4chris: so I still have the issue of making sure I have
the latest RH stuff online...
(10:10:22 AM) warren: Another issue is technical
(10:10:24 AM) spot: abadger1999: and if for some unknown reason, RedHat
doesn't make the source available, i will. ;)
(10:10:33 AM) warren: .epelX as a disttag has no actual drawback.
(10:11:10 AM) thl: we will replace z00dax packages as .epel is higher
than .el
(10:11:19 AM) warren: As long as it is understood....  no disttag is
fine.  or use a  unique differentiating disttag in order to aid support.
(10:11:33 AM) warren: thl, repository mixing, not supported anyway.
(10:12:03 AM) thl: spot, your opinion on .epel?
(10:12:11 AM) warren: I understand that people have reservations about
this.  But the vocal opponents in past discussions have changed their
mind.
(10:12:23 AM) warren: spot, what reasoning do you dislike about this?
(10:12:59 AM) ixs: spot: I might take you up on that source offer
soon...
(10:13:00 AM) spot: Honestly? I think we're misusing dist to cover up
the fact that Red Hat support has shitty tools.
(10:13:10 AM) mmcgrath: At this point I don't care what its called, so
if someone else does care (RH) then I say we accomidate.
(10:13:20 AM) spot: the dist tag was designed to identify the dist for
which a package is built for
(10:13:26 AM) thl: spot, +1
(10:13:29 AM) spot: that dist is EL5, not EPEL5
(10:13:44 AM) mmcgrath: though spot does have a point ;-)
(10:13:49 AM) spot: you're hacking the use case, and i don't like it.
not one bit.
(10:14:22 AM) mspevack left the room (quit: "Leaving").
(10:14:32 AM) ixs: ack. spot does definitly have a point. However, as
stated above, if we can compromise and it's not a problem but solves a
problem for others, we maybe should do that... however, I have no
opinion about it anyways... ;>
(10:14:37 AM) warren: spot, the folks in the RH EPEL meeting generally
agreed.
(10:14:51 AM) warren: spot, however, there is also no real technical
detriment to using .epel as a disttag.   
(10:15:01 AM) bpepple: ixs: agreed.
(10:15:08 AM) warren: There is today a *REAL* difference in support
perception and confusion though.
(10:15:22 AM) spot: warren: so rather than apply yet another bandaid,
perhaps building better support tools?
(10:15:24 AM) warren: Thus the people in the meeting agreed to do both.
(10:15:27 AM) thl: can I get some -1, 0, +1 for "use .epel as disttag"
please? Consider that not as voting, I just want to know what people
think about it currently
(10:15:38 AM) thl:  "use .epel as disttag" -- 0
(10:15:41 AM) c4chris: 0
(10:15:42 AM) spot: warren: we're trying to somehow embed formal
supportability in the name, and i think thats awful.
(10:15:44 AM) awjb: 0
(10:15:44 AM) spot: -1
(10:15:48 AM) warren: 1) Use a differentiating disttag because there is
no technical reason not to.
(10:15:51 AM) mmcgrath: 0.0000001 
(10:15:54 AM) warren: 2) Improve the support tools as we move forward.
(10:15:55 AM) tibbs: 0
(10:15:56 AM) warren: +1
(10:16:09 AM) c4chris: can we have epel5 but el6 ?
(10:16:09 AM) abadger1999: 0
(10:16:28 AM) warren: c4chris, does epel5 < el6 in rpmvercmp?  I don't
think so.
(10:16:31 AM) warren: whatever we pick now we have to stick with.
(10:16:32 AM) ixs: c4chris: -1. confusion ensues.
(10:16:32 AM) tibbs: I'm having trouble understanding both the pros and
cons.  Is there any technical reason for one choice over another?
(10:16:42 AM) c4chris: ack
(10:16:48 AM) tibbs: Or is this entirely political?
(10:16:50 AM) ixs: warren: how long would waiting for the better tools
delay epel?
(10:17:00 AM) abadger1999: warren: If we make sure we rebuild all
packages between releases we can change dist tag.
(10:17:03 AM) warren: tibbs, support today largely uses rpm -qa style
lists, which confuses the issue too much.  This is not support tools,
but rather what customers perceive.
(10:17:17 AM) warren: ixs, not one bit
(10:17:25 AM) thl: warren, but the packages from epel are not even in el
(10:17:38 AM) warren: ixs, either way, .el5 or .epel5 in EPEL, EPEL can
just move forward, and folks just have to deal with it.
(10:18:09 AM) spot: warren: RHAT support uses sysreport, it would be
rather trivial to improve sysreport to compare rpm -qa output against,
say, comps from RHEL 5
(10:18:21 AM) spot: i'd rather see the time spent there than abusing
dist tags.
(10:18:30 AM) warren: spot, why is that necessary?  just look at the
Vendor and GPG status instead.
(10:18:47 AM) cweyl: random thought: wouldn't the vendor tag be
different between rhel and epel packages?
(10:18:49 AM) tibbs: If this is about customer perception, we already
have a test case.
(10:19:00 AM) spot: warren: exactly. we're talking a few additional
lines of code to avoid having to misuse dist tag
(10:19:03 AM) thl: cweyl, yes, it should be different
(10:19:07 AM) ixs: warren: in that case I would probably agree with
spot. his point is solid and .epel would be a misuse of the dist-tag.
(10:19:15 AM) tibbs: Has anyone seen confusion over the fact that we use
"fc6" for Fedora Extras packages?
(10:19:29 AM) warren: Is it really misuse when there really is no
technical detriment to .epel5?
(10:19:40 AM) spot: warren: yes. 
(10:19:57 AM) spot: you can wear a barrel as a shirt, but that ain't
what it is for.
(10:20:00 AM) ixs: warren: the idea behind the dist was to identify the
distro it was built for. we have fc6 and el5 and not fe6.
tibbs tibbs|h 
(10:20:16 AM) warren: OK, if folks here are against changing, that's
fine.  Red Hat cannot mandate this.  Red Hat only requested it.
(10:20:18 AM) cweyl: thl: then why not use that for differentiation? :)
(10:20:38 AM) abadger1999: tibbs: Not sure if it's a fair comparison...
we (the community) support FC and FE equally.
(10:20:41 AM) spot: i think there are lots of ways to tell whether a
package came from Red Hat (tm) or not. :)
(10:20:44 AM) ixs: warren: identifying the source of the package by the
disttag was never planned as far as I understand it.
(10:20:54 AM) ixs: (even though thirdparty repos do that)
(10:21:01 AM) warren: ixs, folks were not concerned about .fc6 vs .fe6
because they have similar levels of support expectations.  RHEL5 and
EPEL5 are quite different in that regard.
(10:21:17 AM) spot: this opens a pandora's box for other repos to start
abusing dist tags 
(10:21:22 AM) warren: ixs, RH does desire EPEL to be seen as a 3rd party
repo.
(10:21:33 AM) tibbs: abadger1999: different mailing lists, different
people to blame.  "Red Hat sucks because I couldn't get help with
<random extras package>".
(10:21:39 AM) spot: "EPEL tags their name in their packages, why is it
bad for me to put DAG or yoMommA in mine?"
(10:21:50 AM) spot: or jpp
(10:21:54 AM) warren: Another issue, we also discussed opportunities for
RH engineers to participate in EPEL in formal ways.
(10:22:05 AM) ixs: warren: i was talking about fedora repos in general
(at, lvn etc.) from the technical point of view epel is just another
build target for the fedora-buildsys.
(10:22:13 AM) warren: For example, there were some cool tools for Xen or
Selinux management that were too late to make it into RHEL5.  They would
be great in EPEL5.
(10:22:36 AM) thl: warren, the usual extras rules should work to get  a
pacakge into EPEL
(10:22:41 AM) ixs: spot: that's actually being done by 3rdparty repos.
(10:22:42 AM) warren: thl, nod
(10:22:53 AM) spot: ixs: yes, but we're trying to set a standard
here. :)
(10:23:00 AM) ixs: I know.
(10:23:03 AM) thl: well, we run quite late already
(10:23:05 AM) warren: If folks here are against .epel disttag, that is
fine.
(10:23:14 AM) thl: I'd like to generally discuss how to proceed with
EPEL
(10:23:15 AM) warren: spot, please help to improve the support reporting
tools OK?
(10:23:21 AM) thl: it starts only slowly
(10:23:24 AM) spot: warren: sure.
(10:23:40 AM) thl: and is missing a real person that drives the whole
thing forward
(10:23:45 AM) thl: do we like that?
(10:24:10 AM) thl: for example the "open epel to sponsors and people
with 5 packages or more" thing
(10:24:15 AM) thl: it got decided last week
(10:24:22 AM) ixs: warren: I do see the problem with customer
expectations. That's one of the reasons the unsupported kernel modules
were dropped from el3 to el4 (shame!!!). But do you really think that el
tags from rh and epel tags from epel would change customer expectations?
if they do not understand unsupported in the rpm name, why should they
grok epel?
(10:24:26 AM) thl: but no one annouced it to the world properly
(10:24:36 AM) thl: it was just mentioned in the summary
(10:24:47 AM) warren: ixs, " unsupported kernel modules were dropped
from el3 to el4" means what?
(10:24:49 AM) thl: that's not enough for something like that
(10:25:04 AM) bpepple: thl: yeah, I'm guessing most of the extra
contributors missed that announcement.
(10:25:05 AM) spot: warren: there used to be a kernel-unsupported
(10:25:08 AM) ixs: warren: there was a kernel-modules-unsupported
package in el3. it was not included in el4 anymore.
(10:25:23 AM) spot: people blew right past it. :)
(10:25:26 AM) ixs: warren: there were lots of nice drivers for hardware,
not supported by rh. cyclades e.g.
(10:25:26 AM) c4chris: thl, right.  Call for a volunteer to step
forward?
(10:25:34 AM) cgTobi_ [n=cgTobi] entered the room.
(10:25:44 AM) Redhat71 [n=ChatZill] entered the room.
(10:25:52 AM) ixs: warren: I fear customers expecting support for 3rd
party from rh is a problem not being solved by a different dist-tag.
(10:25:57 AM) thl: c4chris, the thing it; that a general problem in
fesco imho
(10:26:03 AM) thl: we discuss a lot of things
(10:26:19 AM) thl: but there is often only slow progress; things get
forgotten again and discussed anew
(10:26:29 AM) thl: and I more and more think we suck
(10:26:36 AM) thl: and I'm wondering if that's my fault...
(10:26:41 AM) spot: ok, so epel needs someone to lead the charge
(10:26:42 AM) c4chris: thl, agreed.  So let's start to put a driver in
the seat...
(10:26:44 AM) warren: thl, you can only do so much.
(10:26:53 AM) bpepple: warren: agreed.
(10:27:00 AM) c4chris: thl, don't blame yourself
(10:27:01 AM) spot: dgilmore and mmcgrath seem to have been most
interested in it to date
(10:27:01 AM) thl: c4chris, well, dgilmore and mmcgrath are the drivers
normally
(10:27:16 AM) thl: they are listed as owners of the task
(10:27:20 AM) c4chris: thl, sure, but let's make it a bit more formal
(10:27:24 AM) mmcgrath: we've been pushing foward slowly, we're just
waiting on things like the mirror to get created.
(10:27:32 AM) thl: but, as I said, it's a general thing that applies to
other talsks as well
(10:27:38 AM) spot: ok, so now they're formally in charge of epel. if
you want more packages, harass the lists.
(10:27:42 AM) mmcgrath: c4chris: you mean like a wiki page?
http://fedoraproject.org/wiki/EnterpriseExtras
(10:27:43 AM) spot: make sure people know they can do it.
(10:27:50 AM) thl: that's btw the reason why I put
(10:27:52 AM) thl has changed the topic to: FESCo meeting -- Improve
FESCo's workflow
(10:27:56 AM) mmcgrath: people have been branching for weeks, creating
builds.
(10:28:02 AM) ***mmcgrath runs off to lunch and is hungry :-)
(10:28:02 AM) thl: on the schedule (but we have reached it already)
(10:28:05 AM) warren: I don't have control over mirror layout
(10:28:13 AM) c4chris: mmcgrath, I mean make a bit more noise on the ml
(10:28:13 AM) ***spot assumes that unless people are screaming, its
working ok. :)
(10:28:19 AM) abadger1999: Hmm.. so ideally tasks should have a driver
who is responsible for all the legwork.
(10:28:31 AM) thl: c4chris, what do you mean by "make it a bit more
formal"
(10:28:45 AM) thl: abadger1999, well, that's how it should work already
(10:28:51 AM) thl: that's how it was meant always
(10:28:54 AM) c4chris: thl, attach a name to each project that needs
driving forward
(10:29:05 AM) thl: c4chris, the names are there already
(10:29:11 AM) thl: just look at the shedule
(10:29:46 AM) thl: that why I'm always saying "please look at the
schedule and look out for your name" ;-)
(10:29:50 AM) abadger1999: Do we need to enumerate what "legwork" means?
(10:29:57 AM) abadger1999: Or is the bottleneck something else?
(10:30:32 AM) thl: well, the name IMHO means: driving the whole think
forward and taking care of it
(10:30:44 AM) thl: that can mean: get others to do the hard work
(10:30:55 AM) thl: just getting it sone somehow
(10:31:25 AM) thl: or does anyone have a better idea?
(10:31:28 AM) ixs: ahhh. a project manager? 
(10:31:36 AM) nirik: thl: so you are thinking that epel is moving too
slow? or ?
(10:31:52 AM) tibbs: When you put someone's name next to a task in the
schedule, make sure they know that they're expected to drive it forward.
(10:32:02 AM) thl: nirik, well, epel: yes, but it's a general thing
(10:32:14 AM) thl: nirik, what did FESCo achieve in the past six months?
(10:32:30 AM) c4chris: thl, I'm not sure what can reasonably be done
(10:32:32 AM) thl: was there anything big we can proud off?
(10:32:57 AM) tibbs: We can be proud of the entire project, I'd think.
(10:33:05 AM) thl: tibbs, I put those names there only after I asked
people if they take care of it
(10:33:27 AM) thl: tibbs, well, it's okay, biut there is still a lot to
improve IMHO...
(10:33:28 AM) tibbs: I never saw FESCo's job as being one that would
produce any huge changes.
(10:34:17 AM) cgTobi_away left the room (quit: Connection timed out).
(10:34:21 AM) thl: tibbs, well, it seems  some people expect it 
(10:34:31 AM) thl: they told me in private that they dislike FESCo
(10:34:45 AM) tibbs: Perhaps I'm just aiming too low, but I think the
current level of progress is amazing.
(10:34:46 AM) thl: and I partly agree; FESCo should driver the project
forward
(10:34:51 AM) c4chris: thl, that's not very productive
(10:34:55 AM) cweyl: from a rabble view, to me FESCo has always guided,
facilitated and enabled those with motivation/energy in their particular
quests
(10:35:05 AM) cweyl: FESCo is in certain respects glue, not gasoline :)
(10:35:07 AM) c4chris: thl, why don't they try to help drive things
forward?
(10:35:10 AM) thl: and currently we are only more maintaining than
improving it
(10:35:15 AM) tibbs: Lord, how much more forward can the project be
driven?
(10:35:51 AM) c4chris: thl, being grumpy is always easy
(10:35:57 AM) tibbs: I mean, the Extras methodology has subsumed Red
Hat.  Core is being dissolved.  It wouldn't have happened if Extras was
a festering pit.
(10:36:09 AM) c4chris: thl, doing something constructive about it is
much harder
(10:37:06 AM) thl: so in other words: most people like the way how
everything works currently?
(10:37:16 AM) c4chris: we are supposed to help and provide direction
(10:37:27 AM) c4chris: not necessarily do the whole work ourselves
(10:37:36 AM) jlayton left the room (quit: "leaving").
(10:37:42 AM) thl: c4chris, no, we really should not do all the work
ourselves
(10:37:52 AM) thl: definitely not
(10:37:55 AM) bpepple: thl: I agree we can do some things better, but we
can't do all the heavy lifting.
(10:38:32 AM) thl: we for example still have no stable webinterface for
packages with a URL that does not change
(10:38:41 AM) thl: co-maintainership is lingering around for a long time
(10:38:47 AM) Redhat71 left the room.
(10:38:53 AM) thl: most of the stuff that's on the schedule is there for
a long time already
(10:39:05 AM) thl: anyway, while I'm talking about hte schedule
(10:39:28 AM) thl: let's stop here and get back to it to get to some of
the other topics 
(10:39:30 AM) tibbs: Note that we have to interface with infrastructure
on the first two things you listed.
(10:39:37 AM) nirik: perhaps this is good discussion for the list?
people can bring up their concerns there? 
(10:39:44 AM) bpepple: thl: part of the problem why some of the items
have been there so long is that they are dependent of other issues (I'm
thinking of co-maintainership)
(10:39:51 AM) tibbs: Are you saying that we were lax in our interfacing
with the infrastructure team?
(10:40:28 AM) thl: nirik, yeah, maybe; let's see what people say when
they read the summarie of this meeting
(10:40:33 AM) ***rdieter arrives panting, late.  sorry folks.
(10:40:40 AM) thl: bpepple, well, that does not stop us from working out
rules
(10:40:52 AM) bpepple: thl: agreed.
(10:41:01 AM) thl: e.g. primary-maintainer and co-maintainers or are all
equal?
(10:41:13 AM) thl: or even a more wiki-style approach for packages
(10:41:15 AM) thl: ?
(10:41:32 AM) thl: anyway, it's getting late
(10:41:36 AM) thl: let's move on
(10:41:37 AM) thl has changed the topic to: FESCo meeting -- Opening
Core - (warren, jeremy, rdieter) -- status update
(10:41:44 AM) thl: warren, jeremy, rdieter ?
(10:42:07 AM) thl: is the "Core gets merged into Extras" now official?
(10:42:21 AM) rdieter: no news here (from me anyway)
(10:42:39 AM) warren: thl, it has been official as the plan since the
summit
(10:42:48 AM) warren: thl, it will happen, no questions asked
(10:42:53 AM) warren: thl,  just a question of when
(10:43:02 AM) warren: thl, company is pretty much shut down now
(10:43:08 AM) rdieter: jeremy said good things at the last Board
meeting, but I'll let him say so (if he wants). (:
(10:43:42 AM) warren: thl, today core maintainers have the option of
asking for reviews to prep for moving.
(10:43:43 AM) thl: warren, k; when do we and/or the board clarify the
FESCo future and it's position in the whole game?
(10:44:20 AM) rdieter: when?  now.  Who?  FESCo, imo.  Just do it.
(10:44:24 AM) warren: thl, that picture will become clearer as we
approach the fedora developer meeting in late january.
(10:44:44 AM) warren: thl, meanwhile... just do it
(10:44:57 AM) thl: okay :)
(10:45:00 AM) rdieter: warren: fed dev meeting?
(10:45:05 AM) thl: anything else regarding the merge?
(10:45:12 AM) warren: rdieter, all the fab list discussion?
(10:45:13 AM) bpepple: rdieter: FUCcon I assume.
(10:45:21 AM) rdieter: Ah, early Feb, then. (:
(10:45:40 AM) rdieter: FUDConBoston2007.
(10:45:42 AM) bpepple: s/FUCcon/FUDcon/
(10:45:43 AM) warren: current proposed is Jan 26th for FUDCON, 27-28th
for developer meeting
(10:45:56 AM) thl: ?
(10:45:57 AM) rdieter: hmm... changed dates on me?
(10:46:01 AM) c4chris: so should we post to maint telling core packagers
to submit their stuff for review?
(10:46:03 AM) thl: yet another week earlier?
(10:46:06 AM) ***warren looks again
(10:46:11 AM) bpepple: warren: wasn't it Feb 2-4
(10:46:18 AM) thl: bpepple, yeah, I think so
(10:46:30 AM) warren: i'm confused
(10:46:45 AM) rdieter: website still says Feb 2.,
http://barcamp.org/FudconBoston2007
(10:46:53 AM) thl: warren,
https://www.redhat.com/archives/fedora-announce-list/2006-December/msg00005.html
(10:47:05 AM) nman64 left the room (quit: Remote closed the connection).
(10:47:08 AM) warren: ok, same idea
(10:47:16 AM) warren: one day of talks with public invited
(10:47:28 AM) rdieter: and, btw, we need to get as many FESCo folks
there as possible, esp thl. (:
(10:47:29 AM) warren: the two following days are by-invite only
developer hackfest
(10:47:36 AM) warren: rdieter, yes, I'm working on that.
(10:47:45 AM) awjb: rdieter, so should I swim?
(10:48:06 AM) ***thl wonders if that's really worth flying across the
ocean...
(10:48:13 AM) rdieter: awjb: Do what ya gotta do man.  I bet we can find
some better way though.
(10:48:21 AM) thl: awjb, that will take some time, I suggest you start
soon ;)
(10:48:22 AM) warren: We can't afford to fly everyone, but we'll try.
(10:48:26 AM) bpepple: thl: yeah, pretty long trip.
(10:48:32 AM) awjb: thl, kk ;)
(10:48:56 AM) c4chris: so, do we need to make noise about reviewing core
packages ?
(10:49:05 AM) c4chris: or is the noise going already ?
(10:49:11 AM) thl: c4chris, yeah, why not
(10:49:23 AM) thl: c4chris, but I suggest a RH employee should post that
(10:49:26 AM) ***nirik thinks the sooner the better for reviewing. 
(10:49:33 AM) bpepple: nirik: +1
(10:49:43 AM) c4chris: please 1 step forward :-)
(10:49:57 AM) thl: nirik, +1
(10:50:17 AM) tibbs: Hmmm.
(10:50:21 AM) c4chris: so who is RH here ?
(10:50:52 AM) thl: warren, jeremy, could you do that?
(10:51:17 AM) tibbs: It doesn't really have to be done by a RH employee.
(10:51:30 AM) thl: tibbs, agreed, but it might be better...
(10:51:39 AM) warren: thl, that is already the plan.
(10:51:44 AM) thl: warren, k, thx
(10:51:47 AM) thl: let's move on
(10:51:49 AM) thl has changed the topic to: FESCO-Meeting -- Encourage
co-maintainership -- c4chris
(10:51:50 AM) warren: I'll make it clearer with announcements and
such...
(10:51:53 AM) thl: c4chris, any news?
(10:52:03 AM) c4chris: I saw a patch
(10:52:06 AM) warren: btw, is initialcc workinG?
(10:52:12 AM) nirik: warren: yes. ;) 
(10:52:14 AM) tibbs: That's the rumor.
(10:52:23 AM) c4chris: initialcc sholuld be working now
(10:52:42 AM) c4chris: anybody tested this?
(10:52:48 AM) nirik: I can confirm it worked on a package that has me as
maintainer and someone else in cc. 
(10:52:57 AM) rdieter: nice
(10:52:57 AM) thl: nice :)
(10:52:57 AM) c4chris: cool
(10:53:14 AM) thl: k, so now we need some rules around co-maintainership
(10:53:23 AM) thl: c4chris, do you have something prepared already?
(10:53:33 AM) c4chris: thl, no
(10:53:39 AM) thl: otherwise I can do that between christmas and new
year
(10:53:45 AM) thl: I should have a bit of free time then
(10:53:48 AM) ***warren must leave for chiropractor now.
(10:53:49 AM) c4chris: but I should have some time over new year
(10:54:02 AM) tibbs: We should probably brainstorm on-list or after the
meeting.  I have a few ideas.
(10:54:16 AM) rdieter: ok
(10:54:17 AM) c4chris: tibbs, sounds good
(10:54:20 AM) bpepple: tibbs: +1
(10:54:28 AM) thl: tibbs, can you add some ideas to the wiki?
(10:54:35 AM) tibbs: Sure.
(10:54:36 AM) thl: it'll simply try to work out spomething
(10:54:50 AM) thl: together with folks that are around on IRC
(10:54:51 AM) tibbs: Under EncourageComaintainership?
(10:55:06 AM) thl: and then I'll send it to the list for further
discussions
(10:55:13 AM) thl: tibbs, yes please
(10:55:33 AM) thl: k, so let's move on
(10:55:34 AM) thl has changed the topic to: FESCo meeting -- MISC --
lots of python stuff still needs rebuilding -- any better this week
(10:55:39 AM) thl: nirik, tibbs ?
(10:55:43 AM) tibbs: It should be much better.
(10:55:54 AM) nirik: I didn't get much chance to work on it... but tibbs
did push a bunch
(10:56:06 AM) tibbs: Most of the stuff that's left needs actual work due
to API differences.
(10:56:21 AM) nirik: there is a new broken dep in release repos...
rpy... R was rebuilt and rpy needs rebuilding. 
(10:56:28 AM) nirik: if jose doesn't do that soon I will do so. 
(10:56:32 AM) tibbs: xmldiff even passes when I run it in my local mock
but dies in the buildsys.
(10:56:48 AM) tibbs: And of course there's plenty of bustedness
unrelated to Python.
(10:56:57 AM) thl: well, I'm wondering if we should have a rule to
prevent stuff like that in the future
(10:57:04 AM) nirik: yeah, there is the wx stuff 
(10:57:07 AM) tibbs: The libwx_* stuff is really bloating the list.
(10:57:17 AM) thl: e.g. a "if you change something that breaks other
packages you have to queue rebuilds for them" ?
(10:57:33 AM) nirik: thl: with the new updates system I think it will
not let you push broken updates... lmacken ?
(10:57:37 AM) c4chris: thl, maybe a bit too tough
(10:57:40 AM) thl: (that's just a rough quick-and-dirty-rule)
(10:57:51 AM) thl: c4chris, I know ;-)
(10:57:53 AM) tibbs: I personally don't believe in queueing rebuilds
without at least testing in local mock first.
(10:58:07 AM) thl: tibbs, why? does it hurt anyone?
(10:58:16 AM) thl: builders are often idle in any case
(10:58:17 AM) nirik: for release I would say you should coordinate with
maintainers of packages that need rebuild and push all of them at once
when they are rebuilt. 
(10:58:27 AM) thl: nirik, sure, that was just meant for devel
(10:58:39 AM) tibbs: I don't want to commit something that's broken, so
I always test first.  It's just courtesy.
(10:58:55 AM) ***nirik also tests in local mock before committing. 
(10:59:01 AM) ***thl does not
(10:59:14 AM) ***rdieter does sometimes. (:
(10:59:28 AM) ***bpepple tests in mock normally first also.
(10:59:36 AM) ***awjb does test in mock
(10:59:46 AM) ***c4chris too <aol/> :-)
(10:59:47 AM) nirik: in any case, I can poke at some more python/wx
issues and that rpy problem... 
(11:00:01 AM) thl: nirik, that would be great
(11:00:07 AM) nirik: there are still some core packages with EVR
issues... I filed bugs, but no activity Ican see. 
(11:00:29 AM) rdieter: nirik: maybe they're stalling/waiting for merge?
(11:00:30 AM) thl: nirik, send a list with bug numbers to jeremy and ask
him to poke people
(11:00:40 AM) c4chris: nirik, ah, comaintainers :-)
(11:01:04 AM) thl: rdieter, well, the merge is only for devel, but stuff
often needs to be fixed in FC5 or FC6 afaics
(11:01:07 AM) nirik: I dunno. I can mail whoever can light a fire... if
it will help
(11:01:32 AM) thl: it afaics often helps if jeremy pokes people ;)
(11:01:39 AM) thl has changed the topic to: FESCo meeting -- Packaging
Committee Report
(11:01:42 AM) rdieter: nirik: be careful, someone might accuse you of
being rude.
(11:01:43 AM) rdieter: (:
(11:01:54 AM) nirik: device-mapper, lvm2, mozilla and xen all have EVR
issues in release versions. 
(11:01:55 AM) tibbs: I take it everyone received the summary.
(11:02:02 AM) bpepple: tibbs: yup.
(11:02:27 AM) ***thl is just searching for it again
(11:02:29 AM) nirik: rdieter: sure. I have a pretty good +5 flameproof
suit tho. ;) 
(11:02:29 AM) tibbs: The iconcache proposal has been withdrawn by Rex
pending more discussion.
(11:02:52 AM) rdieter: nirik: glad to hear it.
(11:02:54 AM) ***thl found it
(11:02:55 AM) bpepple: tibbs: yeah, that had quite a bit of
discussion. ;)
(11:03:18 AM) tibbs: Well, there's are a few fundamental disagreements,
but no matter.
(11:03:27 AM) thl: Looks all fine to me 
(11:03:39 AM) thl: or does anyone dislike something from the PCs report?
(11:03:43 AM) tibbs: Point by point:
(11:03:57 AM) tibbs: The Provides:/Obsoletes: draft.
(11:04:07 AM) tibbs: scop isn't here today.
(11:04:19 AM) tibbs:
http://fedoraproject.org/wiki/PackagingDrafts/ProvidesObsoletes
(11:04:32 AM) tibbs: Or will this take too much time?
(11:04:50 AM) thl: tibbs, probably
(11:05:00 AM) thl: tibbs, that what the report is for IMHO
(11:05:12 AM) thl: if people don#t look at it it's there fault
(11:05:16 AM) bpepple: thl: agreed.
(11:05:21 AM) tibbs: Indeed, but I wasn't sure if folks would want an up
or down vote on each change.
(11:05:22 AM) thl: their
(11:05:40 AM) rdieter: any screams of horror? no?  good. (:
(11:05:43 AM) thl: tibbs, no, people IMHO should just yell if they
dislike something
(11:06:00 AM) tibbs: Well, screams of horror over iconcache, but no
complaints otherwise.
(11:06:08 AM) c4chris: no yell here
(11:06:18 AM) thl has changed the topic to: FESCo meeting -- Maintainer
Responsibility Policy -- bpepple -- EOL plans
(11:06:23 AM) thl: bpepple, any news?
(11:07:13 AM) thl: seems bpepple is afk
(11:07:13 AM) bpepple: Just need to write-up something to post to f-e-l
to get community feedback on the suggestions on the wiki.
(11:07:23 AM) thl: bpepple, k
(11:07:29 AM) cgTobi_ is now known as cgTobi
(11:07:37 AM) bpepple: Hopefully, I can get to it before the new year.
(11:07:38 AM) thl: bpepple, but the plan remains to close the builders
on Jan 01 ?
(11:07:43 AM) bpepple: thl: yes.
(11:07:53 AM) thl: bpepple, k
(11:08:00 AM) thl has changed the topic to: FESCo meeting -- Free
discussion around Fedora Extras
(11:08:03 AM) thl: anything else?
(11:08:04 AM) bpepple: I didn't hear any screaming on the mailing list
about it.
(11:08:14 AM) thl: bpepple, that's a good sign :)
(11:08:51 AM) thl: what about the clement issue? the pacakge with the
repo file in it?
(11:09:00 AM) thl: did anybody watch that further?
(11:09:22 AM) thl: do we want to prevent that in the future? Do we need
a rule "no yum.repo files are allowed" ?
(11:09:24 AM) cgTobi: ixs: how was your class?
(11:09:24 AM) nirik: he replied back to the list, but I haven't seen
anything from him since then. 
(11:09:33 AM) tibbs: The package has not been updated.
(11:09:55 AM) thl: hans (his sponsor) in moving to another house and
thus a bit busy
(11:09:57 AM) bpepple: thl: Yeah, we should put something explicitly
forbidding it on the wiki.
(11:10:01 AM) c4chris: thl, I think we should have such a rule
(11:10:05 AM) rdieter: just checked cvs, reference to repo file is still
there.  grr..
(11:10:29 AM) thl: who will handle that? FESCo or PC?
(11:10:34 AM) tibbs: We can't just ban packages adding repositories;
that might be actually useful.
(11:10:37 AM) bpepple: someone needs to step-in and fix it if Hans isn't
around.
(11:10:43 AM) c4chris: at least, the package is not in the repo
(according to PackageStatus)
(11:11:01 AM) rdieter: tibbs: Oh, I think we can (or should)
(11:11:02 AM) thl: tibbs, for eample?
(11:11:07 AM) thl: rdieter, +1
(11:11:07 AM) graveyard [n=graveyar] entered the room.
(11:11:21 AM) bpepple: rdieter: agreed.
(11:11:29 AM) rdieter: I'll do the followup cluestick whacking after the
meeting.
(11:11:35 AM) tibbs: Well, you might have a package that adds, say,
dribble or whatever.
(11:11:50 AM) tibbs: It would be a big political issue over whether
that's allowed and wanted, etc.
(11:12:02 AM) thl: tibbs, yeah, but why should such a package be in
Extras?
(11:12:10 AM) rdieter: tibbs: stuff like that needs to have explicit
permission, if ever.
(11:12:22 AM) tibbs: Because it would be useful.
(11:12:38 AM) tibbs: It's tough to make up a hypothetical in 30 seconds
that you can't easily shoot down for some other reason.
(11:12:46 AM) thl: tibbs, if we can enable a repo that we could put it
contents into Extras...
(11:12:50 AM) c4chris: tibbs, I'd rather have a rule that says we don't
want them, and have a few exceptions granted where useful
(11:13:00 AM) rdieter: tibbs: let's just stick with simple "no way",
unless good reasons can be made for exceptions.
(11:13:04 AM) nirik: if a usefull case comes up, then the guidelines
could be changed?
(11:13:10 AM) thl: rdieter, +1
(11:13:18 AM) thl: nirik, sure
(11:13:32 AM) rdieter: and I'm pretty sure there won't ever be any
exceptions. (:
(11:13:44 AM) thl: rdieter, so will the PC handle it?
(11:13:54 AM) tibbs: It's FESCo's decision, IMHO.
(11:14:07 AM) rdieter: thl: I will wearing my PC/FESco/Board badge,
whatever. (:
(11:14:10 AM) bpepple: tibbs: actually I think PC would be a better
place.
(11:14:11 AM) c4chris: tibbs, I tend to agree
(11:14:12 AM) ChanServ left the room (quit: Shutting Down).
(11:14:20 AM) thl: argh
(11:14:44 AM) thl: we need a better scheme in the merged world to make
sure what's PCs job, and what FESCo job
(11:14:54 AM) c4chris: let's put it this way: FESCo asks the PC to make
a rule...
(11:14:57 AM) ChanServ [ChanServ] entered the room.
(11:14:57 AM) mode (+o ChanServ ) by irc.freenode.net
(11:15:05 AM) rdieter: right, I see PC more as legislative, FESCo more
executive branch.
(11:15:06 AM) thl: tibbs, the rule would need to exists under the
packaging namesapce afaics
(11:15:45 AM) rdieter: this one is case of common sense, and security
implications.
(11:15:48 AM) thl: rdieter, I see a shitload of work for FESCo oin the
future and we need a way to say "SIG/Foo/PC/Bar, you need to hanle that"
(11:16:01 AM) thl: handle
(11:16:11 AM) rdieter: thl, no disagreement there.  We certainly need
more delagation, and SIGs.
(11:16:12 AM) bpepple: thl: +1
(11:16:26 AM) c4chris: sounds fine to me
(11:16:34 AM) thl: anyway, regarding the issue at hand
(11:16:40 AM) tibbs: Whatever committee does this must be certain not to
ban fedora-release.
(11:16:47 AM) thl: the rule would need to live in the wiki below
Packaging/ afaics
(11:16:55 AM) thl: thus IMHO the PC need to accept it
(11:16:55 AM) rdieter: tibbs: you found the one exception! (:
(11:17:10 AM) abadger1999: This is a "what to package" rather than a
"how to package" question which usu. means FESCo.
(11:17:21 AM) blarney [n=blarney] entered the room.
(11:17:44 AM) thl: abadger1999, but there are no special "what to
package" rules anywhere
(11:17:54 AM) tibbs: Umm, we're just making one.
(11:18:00 AM) thl: and it needs to be checked in the review guidlines
and those are owned by the PC
(11:18:00 AM) blarney: spot: ping
(11:18:04 AM) c4chris: abadger1999, well, it's a bit like: don't
package .la and .a files...
(11:18:10 AM) abadger1999: kmods
(11:18:11 AM) thl: c4chris, +1 ;)
(11:18:35 AM) thl: well, it's late
(11:18:37 AM) tibbs: In any case, if FESCo wants to expand PC's mandate,
I won't object.
(11:18:49 AM) rdieter: I'll take it to PC too, this one should be easy
to pass without pissing off anyone else... (I haven't filled my quota
this week).
(11:18:56 AM) abadger1999: rdieter:  :-)
(11:18:59 AM) thl: rdieter, thx
(11:19:16 AM) thl: tibbs, we need to adjust that in any case for the new
merged worlds order afaics
(11:19:19 AM) spot: blarney: yes?
(11:19:29 AM) thl: k, so anythign else we should discuss?
(11:19:30 AM) tibbs: thl: I believe we do.
(11:19:49 AM) ***c4chris needs to attend to a few family things soon...
(11:19:52 AM) thl: what about the "don#t use cvs-import after the
initial import" ?
(11:20:09 AM) ***thl will end the meeting in 60
(11:20:11 AM) rdieter: some folks really like using that afterwards..
(11:20:15 AM) blarney: spot: any chance you could update rpy (no word
from jmatos):
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=220403 it's
blocking the R upgrade
(11:20:18 AM) blarney: ?
(11:20:19 AM) tibbs: I never use it myself.
(11:20:20 AM) bpepple: thl: Maybe we can modify the script not to even
allow that usage.
(11:20:25 AM) jcollie: rdieter, because ther don'
(11:20:31 AM) tibbs: Someone once proposed a "make clone-branch"
command,
(11:20:35 AM) jcollie: er because they don't want to learn cvs
(11:20:46 AM) nirik: blarney: I will if spot won't. Did you see that
there are newer versions available?
(11:20:50 AM) tibbs: which would copy, say, the files in "devel" into
"FC-6"
(11:20:56 AM) rdieter: tibbs: that would help (I'd like that)
(11:21:00 AM) blarney: nirik: yes, I saw that
(11:21:12 AM) spot: blarney: i'll rebuild the existing version.
(11:21:16 AM) tibbs: I would use it extensively, but I have no idea how
to implement it.
(11:21:19 AM) ***thl will end the meeting in 30
(11:21:32 AM) nirik: spot: thanks. Let me know if I can test build or
assist you...
(11:21:43 AM) c4chris: thl, we should provide some better alternative I
guess...
(11:21:57 AM) thl: let's discuss the cvs-import stuff in a later meeting
(11:22:01 AM) thl: one last thing
(11:22:02 AM) c4chris: right
(11:22:07 AM) thl: meeting next week?
(11:22:10 AM) thl: who will be there?
(11:22:17 AM) ***thl probably will
(11:22:18 AM) ***bpepple will be here.
(11:22:19 AM) tibbs: I will be around.
(11:22:22 AM) ***c4chris probably won't be around
(11:22:31 AM) nirik: FYI, I see extras has 980 bugs open. Of those 611
are in the NEW state. Thats 62% where no one has stepped up and assigned
the bug to themselves. Kinda sad. 
(11:22:32 AM) blarney: nirik: what about going to the latest 0.99 in
devel and then porting back to FC-6 if that's stable?
(11:22:57 AM) thl: so let's meet next week
(11:22:58 AM) nirik: blarney: that would be a job for the maintainer. I
wouldn't push a new version to fix this when the old one will work. 
(11:22:59 AM) tibbs: nirik: I guess that's one for the mythical QA team.
(11:23:11 AM) thl: and it there are lett then 5 FESCo members around
we'll cancel it
(11:23:13 AM) thl: that okay?
(11:23:19 AM) ***thl will end the meeting in 30
(11:23:20 AM) tibbs: Sure.
(11:23:24 AM) bpepple: thl: sounds fine.
(11:23:28 AM) spot: next week? maybe.
(11:23:32 AM) ***thl will end the meeting in 15
(11:23:39 AM) blarney: nirik: ok, unless it is orphaned, I guess we wait
to see if jmatos is on vacation or wants to give it up
(11:23:51 AM) thl: -- MARK -- Meeting End
}}}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20061227/39ba77aa/attachment.sig>


More information about the fedora-extras-list mailing list