FESCo meeting Logs 2006-12-14

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

 



= 2006 December 14 FESCo Meeting =

== Members ==

=== Present ===
 * thl
 * dgilmore
 * warren
 * tibbs
 * jwb
 * rdieter
 * bpepple
 * abadger1999
 * ch4chris
 * jeremy
 * scop

=== Absent ===
 * spot
 * awjb
  
== Summary ==
 
=== EPEL ===
 * c4chris asked if we could have ia64 builds and whether an ia64
builder could be hosted outside of Red Hat/Fedora.
  * dgilmore, c4chris, and mmcgrath will discuss this with
infrastructure.
 * Local EPEL mock builds can be done with CentOS but the configuration
is not yet shipped in our mock package.  Will coordinate with the mock
package maintainer to get that built.
 * Need to get bugzilla configured for epel.
 * dgilmore will maintain an open tasks list for EPEL.
 * Shipping packages for EL-Server that are part of EL-Client.
  * Make a decision later (when someone decides they want to ship such a
package).  Warren is having a meeting with some RHEL managers that may
add ideas as well.
 * Who can request EPEL branches?
  * We want to focus on community maintainership of EPEL rather than
strict one-maintainer ownership.
  * Prefer that Extras maintainers are the maintainer in EPEL but it is
not necessary.  For instance, in the case where the Extras maintainer is
not allowed to branch for EPEL or the Extras maintainer has no interest
in EPEL.
  * Ratified: Sponsors and people maintaining 5+ packages are allowed to
branch/own packages in EPEL.
  * Ratified: "Extras maintainers get first crack at maintaining the
EPEL Package.  If they don't want to, someone else can do it, but they
must communicate with the Extras Maintainer."
  * c4chris will make a quick table of sponsors/people with 5+ packages
to make enforcement of "who can own epel packages" easier.
 * At some point we need a policy for when to update and when to
backport in EPEL.
 * There was a proposal to rename EPEL to PEEL Packaged Extras for
Enterprise Linux -- people are tired of naming discussions and like epel
well enough.  No changes.

=== Opening Core ===
 * Policy decisions mostly internal Red Hat at this point.
 * dgilmore made the suggestion that we should start moving Core
packages that are on the fringes of the dependency tree into Extras now.
This helps us get started on the potential bottleneck of reviewing all
the Core Packages.
  * jeremy would like to put off harassing packagers with the move for a
little longer.
 * jeremy has a proposal related to this but needs to write it up.
 * Current Core maintainers should be encouraged very strongly to be
maintainer or co-maintainer on packages.  This is because they also
maintain the package for RHEL and should be aware of what is going on
with their package.

=== Co-Maintainers ===
 * Bugzilla auto-cc problem:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=198109
  * The script just needs debugging to find and fix the issue.
  * Script is located in cvs:
http://cvs.fedora.redhat.com/viewcvs/fedora-accounts/?root=fedora
  * The script is bz-make-components.py

=== Broken deps and EVR problems ===
 * Down to one non-devel broken dep (linphone) and two evr problems.
 * Devel has python packages in need of rebuilds.  tibbs and nirik will
start kicking off builds with others welcome to jump in.

=== Stop running repoview on debuginfo packages ===
 * Voted to stop running repoview on debuginfo
 * +1: thl, bpepple, rdieter, jwb, tibbs, abadger1999, jeremy
 * -1: [None]

=== Packaging Committee Report ===
 * iconcache changes made.  Close to approval.
 * Making the rpm Group tag optional from a few weeks ago is currently:
no changes to policy but have the rpm maintainer allow for it
technically.

=== Allowing libsparse (static) ===
 *
https://www.redhat.com/archives/fedora-packaging/2006-December/msg00034.html
 * libsparse.a is provided by mdomsch's sparse package.
 * Jeff Garzik wants it for a package of his and is willing to monitor
for static library issues.
 * +1: thl, rdieter, tibbs, bpepple, c4chris, dgilmore, tibbs,
abadger1999, jwb
 * -1: [None]

=== Kmod Approval ===
 * gspca https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209112
  * Voted to allow for a period of 1 year and then revisit if it's not
upstream:
  * +1: warren, thl, jwb, bpepple, c4chris, abadger1999, tibbs

=== Maintainer Responsibility ===
 * Looks like Legacy is going to drop FC4 and earlier.
 * Proposal to drop FE3 and FE4 on January 1
  * +1: thl, scop, bpepple, jwb, abadger1999, warren, rdieter
  * tibbs had some hesitation, dgilmore was +1 as long as legacy is
done.
 * In addition to closing the builders we'll also be removing all but
the latest build of a package on the download servers to save space.
 * Open bugs against FE3, FE4 should be closed or moved forward to a new
release.

=== File deps outside "/etc {/usr,}/{s,}bin/" ===
 * The issue with file deps is that repodata has file deps for things in
certain directories only.  File deps outside those directories have to
download a second, rather large file for possibly multiple repositories
and process them looking for the file deps.  If we keep deps within /etc
and the bin dirs we can speed up yum's processing time.
 * rdieter will present this to the Packaging Committee to be made into
a Guideline.

== Log ==
{{{
(10:00:30 AM) thl: FESCo meeting ping -- abadger1999, awjb, bpepple,
c4chris, dgilmore, jeremy, jwb, rdieter, spot, scop, thl, tibbs, warren
(10:00:33 AM) thl: Hi everybody; Who's around?
(10:00:37 AM) ***dgilmore is here
(10:00:37 AM) warren: hi
(10:00:39 AM) tibbs: Howdy.
(10:00:40 AM) jwb: hi
(10:00:40 AM) ***rdieter is here.
(10:00:49 AM) ***bpepple is here.
(10:00:50 AM) ***abadger1999 is here.
(10:01:03 AM) c4chris_ is now known as c4chris
(10:01:07 AM) ***c4chris is here
(10:01:18 AM) thl: hey, quite a lot of people this time; so let's start!
(10:01:20 AM) thl has changed the topic to: FESCO-Meeting -- EPEL --
mmcgrath, dgilmore -- status update
(10:01:23 AM) thl: dgilmore, mmcgrath ?
(10:01:43 AM) rdieter: dilgmore is around (I was chatting just moments
ago)...
(10:01:55 AM) jwb: he said he was here :)
(10:02:03 AM) dgilmore: thl: we have had some more building 
(10:02:12 AM) ***rdieter wipes glasses, tries to relearn to read
quickly.
(10:02:19 AM) dgilmore: im still waiting to hear back about getting the
sync process setup
(10:02:23 AM) c4chris: will we have ia64 at some point ?
(10:02:40 AM) dgilmore: c4chris: not unless we get donated a ia64 build
host 
(10:02:45 AM) mmcgrath: pong
(10:02:52 AM) c4chris: hmm, can I provide one ?
(10:02:58 AM) thl: I hope we'll have ia64 over time, but for now; see
dgilmore's replay
(10:03:00 AM) thl: reply
(10:03:09 AM) j-rod: |DrJef|: hey, numpy is built
(10:03:16 AM) jwb: c4chris, um... not until the buildsys can accomadate
it being outside of the RH firewall
(10:03:26 AM) c4chris: jwb, k
(10:03:27 AM) mmcgrath: Still waiting on notting for a public mirror I
believe.
(10:03:28 AM) dgilmore: c4chris: you should be able to provide one
(10:03:37 AM) dgilmore: and it could be external to Red hats network 
(10:03:44 AM) scop [n=scop] entered the room.
(10:03:48 AM) jwb: dgilmore, and still be called Fedora?
(10:03:52 AM) ***jwb questions that
(10:03:58 AM) jwb: i thought we weren't to that point yet
(10:04:07 AM) dgilmore: jwb: the current build server is at duke 
(10:04:13 AM) jeremy: and I'm here now
(10:04:31 AM) jwb: perhaps we're talking of different things
(10:04:39 AM) jwb: or i'm just confused.  move on :)
(10:04:42 AM) mmcgrath: We've talked about builders at multiple spots.
The issue becomes syncing their backend packages to make sure everything
gets built from identicial build-requires.
(10:04:48 AM) dgilmore: if we had a EPEL ia64 build host that was not
located in Duke or Red Hat i dont see a problem with that 
(10:04:50 AM) c4chris: dgilmore, if it can be done, I'm interested
(10:04:57 AM) jwb: sure
(10:05:16 AM) j-rod: mmm... ia64...
(10:05:24 AM) c4chris: I can actually justify some work hours doing just
that :-)
(10:05:29 AM) ***j-rod must be sick in the head...
(10:05:29 AM) thl: dgilmore, c4chris, I suggest you work it out; would
be good to work that out quickly, as we could support ia64 right from
the start then
(10:05:30 AM) dgilmore: mmcgrath: yeah  we would need to make sure that
the tree was in sync 
(10:05:44 AM) thl: but we probably need a ACK from the Board afaics
(10:05:47 AM) mmcgrath: dgilmore: have you heard back from anyone
concerning the mirror?
(10:05:54 AM) dgilmore: c4chris: ill chat to you about it after the
meeting
(10:05:59 AM) dgilmore: mmcgrath: not yet 
(10:06:02 AM) c4chris: dgilmore, k
(10:06:17 AM) dgilmore: just nottings quick response that he will ping
the people on it 
(10:06:25 AM) thl: and can we trust external builders (we can of course
trust c4chris, but hte question needs to be raised)
(10:06:54 AM) dgilmore: thl: we would need to trust the builders yes.  
(10:06:58 AM) jwb: can we do EPEL mock builds locally yet?
(10:07:00 AM) ***jwb assumes no
(10:07:08 AM) mmcgrath: jwb: I do.
(10:07:11 AM) dgilmore: jwb: you can with CentOS
(10:07:17 AM) alleycat left the room (quit: "Ce-i lipseste in materie de
inteligenta compenseaza prin prostie.").
(10:07:22 AM) dgilmore: or RHEL if you have a license
(10:07:30 AM) thl: dgilmore, I think jwb is asking for preconfigured
mock configs
(10:07:36 AM) jwb: dgilmore, i mean do we have the infrastructure in
place on the buildsystems and in mock
(10:07:45 AM) jwb: so one can type: make mockbuild
(10:07:47 AM) rdieter: last I knew, the preconfigured mock configs
pointed to centos.
(10:07:57 AM) mmcgrath: jwb: oh, yeah.  We've been doing test builds for
a couple of weeks.
(10:08:03 AM) warren: rdieter, and that's fine.
(10:08:11 AM) thl: warren, +1
(10:08:14 AM) jwb: mmcgrath, rdieter: test... but are those in a
released mock package?
(10:08:41 AM) dgilmore: jwb: make mockbuild depends on you locally
haveing the neccesary setup
(10:09:07 AM) rdieter: jwb: afaict, no.  (At least not fc6's mock pkg
doesn't yet include it).
(10:09:20 AM) jwb: hm..  that's my last hinging point
(10:09:35 AM) rdieter: then we just need to bug the mock maintainer for
an update. (:
(10:09:41 AM) jwb: yes
(10:09:44 AM) mmcgrath: Other than that we need to decide who can
requests forks and some of those logistical issues.
(10:10:01 AM) thl: and we should update the schedule to make sure we
don#t forget it ;)
(10:10:09 AM) dgilmore: we still need to get bugzilla configured 
(10:10:34 AM) thl: mmcgrath, dgilmore, could you maintain a "open tasks
lists" on the schedule please?
(10:10:51 AM) warren: I have a meeting with <unspecified manager>
regarding EPEL on Friday.
(10:10:55 AM) dgilmore: i am looking at lmackens update utility to do
the pushing of builds
(10:11:02 AM) jwb: warren, to discuss what?
(10:11:04 AM) dgilmore: thl: sure we can do that 
(10:11:20 AM) warren: jwb, the Client/Server split mess and implications
of this toward EPEL
(10:11:21 AM) thl: dgilmore, thx, that would be extremely helpfull;
there is so much stuff to think about
(10:11:30 AM) jwb: warren, ah excellent
(10:11:42 AM) thl: dgilmore, and a lot of stuff got discussed in the
meetings and forgotten again :-/
(10:11:44 AM) warren: I'll have news by next week
(10:12:09 AM) thl has changed the topic to: FESCO-Meeting -- EPEL --
mmcgrath, dgilmore -- ship packages in EPEL for EL-Server that are part
of EL-Client?
(10:12:15 AM) dgilmore: warren: keep us in the loop please 
(10:12:19 AM) warren: nod
(10:12:20 AM) thl: what did we agree on regarding that last week?
(10:12:31 AM) mmcgrath: I vote we don't make the distinction until the
need comes about.
(10:12:32 AM) dgilmore: thl: wait till warren is done before we discuss
this
(10:12:50 AM) rdieter: mmc/dgil: ++
(10:12:53 AM) ***cweyl takes a seat in the rabble stands
(10:13:02 AM) thl: okay :)
(10:13:09 AM) thl has changed the topic to: FESCO-Meeting -- EPEL --
mmcgrath, dgilmore -- open EPEL for sponsors and people maintaining more
then 5 packages in Extras?
(10:13:14 AM) thl: suggestions?
(10:13:27 AM) mmcgrath: I think we need some sort of requirement for it
but I don't know what that requirement should be.
(10:13:29 AM) thl: btw, owners.epel.list is still mostly empty :-(
(10:13:38 AM) rdieter: thl: you're initial suggestion sounds like a
logical next step.
(10:13:44 AM) dgilmore: lets open it up and have packages waiting so
that we have things to offer when we get everything inplace
(10:13:47 AM) nirik: what about dependencies? ie, you want to branch
package a, but it needs 20 other packages you don't maintain in extras?
(10:13:48 AM) thl: well, sponsors should be fine IMHO
(10:14:06 AM) jwb: i'd like to do a few, but i want the mock configs
sorted out first
(10:14:06 AM) rdieter: at least until we get warren's new fedora level
32 system... (:
(10:14:13 AM) warren: 250 levels
(10:14:15 AM) cgTobi left the room ("Leaving").
(10:14:17 AM) dgilmore: nirik: then you need to maintain them in EPEL or
have someone who wants to 
(10:14:20 AM) abadger1999: rdieter: +1
(10:14:20 AM) thl: 250 levels?
(10:14:23 AM) ***thl is shocked
(10:14:24 AM) warren: (joke)
(10:14:28 AM) mmcgrath: Thats the other question, should we be putting
focus on 'community ownership' or 'maintainer ownership' ?
(10:14:30 AM) thl: :)
(10:14:33 AM) XulChris: why not just recompile everything for EPEL?
(10:14:38 AM) warren: open to sponsor rank for now
(10:14:40 AM) rdieter: mmcgrath: yes. (:
(10:14:41 AM) thl: mmcgrath,  'community ownership'
(10:14:49 AM) jwb: XulChris, because we don't want to do that
(10:14:52 AM) warren: XulChris, do you want to be responsible for all
those packages? =)
(10:14:55 AM) thl: XulChris, because someone has to maintain it
(10:15:11 AM) mmcgrath: K, I put that on the EE page but I wanted to
make sure that was the general consensus.
(10:15:15 AM) warren: Sponsor rank for now, ratify?
(10:15:18 AM) dgilmore: thl: i agree  we need community ownership of
things 
(10:15:25 AM) thl: sponsor rank for now +1
(10:15:33 AM) warren: after more pieces are ready we can open it further
(10:15:34 AM) c4chris: thl, +1
(10:15:38 AM) dgilmore: sponsor +1
(10:15:40 AM) rdieter: sponsor sounds reasonable, +1
(10:15:41 AM) mmcgrath: +- 0
(10:15:46 AM) abadger1999: for now +1
(10:15:48 AM) bpepple: sponsor +1
(10:15:56 AM) jwb: +1
(10:15:59 AM) thl: warren, well, it might be a bit hard without those
packages that are not sponsors, but have lots of packages
(10:16:13 AM) cweyl: it's a start at least.
(10:16:16 AM) thl: thus my "people with more then 5 packages" suggestion
(10:16:18 AM) craigt [n=cthomas] entered the room.
(10:16:19 AM) warren: wait...
(10:16:26 AM) warren: sponsor rank gets to do what exactly?
(10:16:33 AM) rdieter: request EPEL branches.
(10:16:43 AM) nirik: is the owners/bugzilla gonna be setup soon? I hate
having packages there with no idea who branched them or how to report
bugs against them.
(10:16:43 AM) tibbs: I'm undecided. I'm not sure what will help with
issues that the denyhosts update uncovered.
(10:16:59 AM) warren: perhaps a sponsor could request EPEL branches on
behalf of a non-sponsor
(10:17:00 AM) warren: ?
(10:17:10 AM) rdieter: warren: ++, also reasonable.
(10:17:13 AM) warren: tibbs, what issues?
(10:17:14 AM) thim1 [n=thimm] entered the room.
(10:17:20 AM) thl: would that really help?
(10:17:25 AM) mmcgrath: is the assumption that there is no automatic
correlation between extras owner and EPEL owner?
(10:17:30 AM) XulChris: OT: but why are we still requesting branches?
shouldnt sponsers just be able to do it without any request?
(10:17:39 AM) tibbs: warren: Denyhosts had a security problem.  I went
to update and found that someone had branched it for EPEL.
(10:17:39 AM) abadger1999: mmcgrath: Yes.
(10:17:42 AM) thl: mmcgrath, correct
(10:17:52 AM) tibbs: No entry in the epel owners list; I had no idea
what I was expected to do.
(10:17:58 AM) thl: but I hope owners are often the same in extras and in
epel
(10:18:03 AM) warren: XulChris, that will be possible in the future with
the package database and ranking system, but for now we need a simple
policy to control it without that stuff.
(10:18:08 AM) dgilmore: nirik: hopefully soon.  though the packages are
currently sitting on the buildsys only 
(10:18:10 AM) tibbs: I went ahead and pushed the update to all seven
branches I guess I'm now maintaining.
(10:18:25 AM) rdieter: thl: generally true, I did a couple of others
(and I'm lame that I haven't fully updated owners.epel.list yet).
(10:18:40 AM) warren: tibbs, was that really a problem?  I guess the
EPEL maintainer should have communicated with you to make it better...
(10:18:54 AM) ***nirik thinks builds should fail if owners.epel doesn't
have an entry. 
(10:18:55 AM) tibbs: As far as I know there is no EPEL maintainer.
(10:19:12 AM) warren: tibbs, didn't dgilmore say he would have been if
nobody did?
(10:19:14 AM) thl: where did that branch come from? testing maybe?
(10:19:17 AM) c4chris: look in th ewiki log ?
(10:19:20 AM) rdieter: nirik has a point, that would be a good
self-check.
(10:19:29 AM) bpepple: rdieter: agreed.
(10:19:35 AM) tibbs: warren: That's really not the kind of thing we
want.
(10:19:42 AM) dgilmore: it was a branch i did for testing 
(10:19:46 AM) Urs_ShPo left the room (quit: "Leaving.").
(10:20:04 AM) thl: dgilmore, k, that explains it
(10:20:04 AM) tibbs: dgilmore: Right, but how was I supposed to know
that?
(10:20:20 AM) dgilmore: tibbs: we use denyhosts on Fedora infrastucture.
so we want it there.  if you dont want to be the EPEL mainatiner then i
will be 
(10:20:25 AM) rdieter: tibbs: practice your esp/clairvoyance skills.
(10:20:34 AM) tibbs: I don't have a problem with receiving help.
(10:20:38 AM) warren: How about this for policy: Ideally the Extras
maintainer should be the EPEL maintainer.  But if they don't want to
maintain EPEL, then someone else may do so if they effectively
communicate with the Extras maintainer. ???
(10:20:49 AM) ***nirik wonders where epel binary rpms are now? on the
buldsys? can we download/test them?
(10:20:52 AM) rdieter: common sense rules all.
(10:20:59 AM) thl: rdieter, +1
(10:21:02 AM) dgilmore: tibbs: it was a case that i should have
communicated better with you.  
(10:21:05 AM) warren: nirik, I wonder too.
(10:21:10 AM) tibbs: But I am unsure what the epel policy on pushing new
versions versus backports is, so I was unsure what I should have done.
(10:21:25 AM) rdieter: nirik: (still only) on the buildsys, afaik.
(10:21:31 AM) tibbs: I went ahead and pushed the new version out to all
branches because I evaluated it to have a low chance of disruption.
(10:21:37 AM) tibbs: But I could have backported the fix as well.
(10:21:56 AM) thl: we probably need some guidelines for EPEL soon
(10:22:03 AM) c4chris: tibbs, that sounds fine to me
(10:22:04 AM) warren: backporting has its own risks too.  It is not
clear cut.
(10:22:15 AM) warren: backporting means you're running something
upstream hasn't tested.
(10:22:19 AM) thl: otherwise we have one half up2packages, and the other
half are quite old
(10:22:22 AM) thl: that would suck
(10:22:40 AM) warren: When to backport, when to upgrade, is its own
topic in itself.
(10:22:58 AM) rdieter: the best person to answer that question is
maintainer, imo.
(10:23:06 AM) bpepple: warren: definitely.
(10:23:18 AM) c4chris: rdieter, agreed
(10:23:20 AM) thl: rdieter, agreed, too, but some guidelines could be
helpfull
(10:23:24 AM) warren: In most cases you know by using it, "oh boy, this
wont upgrade smoothly and automatically"
(10:23:31 AM) warren: or "this does upgrade automatically"
(10:23:33 AM) rdieter: warren++
(10:23:44 AM) warren: clamav is designed to be a smooth upgrade
(10:24:11 AM) dgilmore:
http://buildsys.fedoraproject.org/plague-results/fedora-4-epel/
(10:24:36 AM) nirik: (as a side note the clamav in epel is back a
release and needs a security update. ;) 
(10:24:52 AM) ***warren is using clamav FC-3 currently =)
(10:25:04 AM) thl: back to topic: so sponsors only, or packagers with
more then X packages, too (X=5?) ?
(10:25:07 AM) dgilmore: warren: thats what i use also 
(10:25:16 AM) dgilmore: thl: im ok with that 
(10:25:20 AM) mmcgrath: thl+1
(10:25:24 AM) warren: thl, it is unclear to me what that gets us
(10:25:31 AM) warren: only sponsor owned packages may go into EPEL now?
(10:25:35 AM) mmcgrath: warren: at least some level of experience.
(10:25:44 AM) warren: sponsor may request packages owned by non-sponsors
to go into EPEL?
(10:26:00 AM) dgilmore: warren: yes
(10:26:05 AM) warren: what if sponsor wants a package that they own,
that requires non-sponsor packages?
(10:26:06 AM) thl: warren, sponsors and people with more then 5 packages
get allowed to maintain packages in epel
(10:26:21 AM) mmcgrath: One quick question... how do we enforce that?
(10:26:25 AM) dgilmore: warren: rdieter requested branches for things he
is not the maintainer of as thery wer deps for things he wanted
(10:26:27 AM) warren: How do we easily enforce that if we use the same
CVSSyncNeeded page?
(10:26:48 AM) thl: -ENoIdea
(10:26:53 AM) warren: I'm ok with X=5, just enforcement wont be easy.
(10:26:55 AM) dgilmore: warren: perhaps we need a EPELCVSSyncNeeded page
(10:27:07 AM) warren: As a companion policy, I propose:
(10:27:37 AM) warren: Extras maintainer gets first crack at maintaining
the EPEL Package.  If they don't want to, someone else can do it, but
they must communicate with the Extras maintainer.  Ratify?
(10:27:48 AM) warren: (Co-maintainership is possible...)
(10:27:57 AM) rdieter: sure, +1 from me.
(10:28:01 AM) thl: warren, +1
(10:28:03 AM) bpepple: warren: +1
(10:28:04 AM) c4chris: I can make a quick table of sponsors/people with
X+ packages if necessary
(10:28:04 AM) dgilmore: +1
(10:28:08 AM) c4chris: warren, +1
(10:28:13 AM) jwb: +1
(10:28:16 AM) thl: c4chris, that would probably he helpful
(10:28:19 AM) dgilmore: c4chris: that would help
(10:28:22 AM) abadger1999: +1
(10:28:29 AM) scop: +1
(10:28:29 AM) thl: k, seem settled
(10:28:35 AM) warren: Maybe we could use X>=5 as a way to get from FD1
to FD2, which is a few levels below FD(something) sponsor
(10:28:35 AM) thl: let's move one
(10:28:37 AM) tibbs: +1.
(10:28:37 AM) c4chris: k
(10:28:44 AM) thl: warren, +1
(10:29:00 AM) thl: one last thing regarding epel (just a quick thing)
(10:29:07 AM) warren: Sorry not much progress on that, been dealing with
multiple security issues. =(
(10:29:14 AM) thl: some people did not like the EPEL acronym to much
(10:29:23 AM) thl: I saw this floating by in hte channel:     *
(10:29:23 AM) thl: I saw this floating by in hte channel:
'j-rod likes "Packaged Extras for Enterprise Linux" or just "Extras for
Enterprise Linux" -- much better acronyms' -- some people did not like
EPEL, do we want to change it to one of those? Either now or never...
(10:29:57 AM) warren: PEEL or EEL?
(10:29:59 AM) warren: EFEL?
(10:30:07 AM) ***jwb is tired of names
(10:30:12 AM) warren: EPEL, even if it is meaningless, sounds better.
(10:30:31 AM) thl: well, was just a question :)
(10:30:35 AM) thl: let's move on then
(10:30:40 AM) warren: I don't care what EPEL stands for, I like how it
sounds.
(10:30:42 AM) thl has changed the topic to: FESCo meeting -- Opening
Core - (warren, jeremy, rdieter) -- status update
(10:30:55 AM) thl: warren, jeremy, rdieter ?
(10:30:56 AM) warren: I haven't heard anything new.
(10:31:14 AM) jeremy: thl: slow movement, but not a lot
(10:31:21 AM) rdieter: no board update, it's mostly interal @rh at this
point.
(10:31:27 AM) dgilmore: can i suggest we start moving fringe core
packages into extras?
(10:31:33 AM) thl: so we just wait here what happens?
(10:31:35 AM) warren: thl, what is certain is that we have to mass
review Core before test2 or so?
(10:31:44 AM) jeremy: dgilmore: I'm fine with moving packages as people
want
(10:31:54 AM) rdieter: the sooner, the better.
(10:31:55 AM) jwb: _want_ being the key word
(10:32:00 AM) jeremy: also, I have a proposal on how to make it so that
we're not entirely deadlocked, but I need to write it up 
(10:32:03 AM) warren: jeremy, if something listed in comps is moved,
will that break rawhide installer?
(10:32:11 AM) jeremy: warren: no
(10:32:13 AM) dgilmore: jeremy: can we ask the core maintainer to
volunteer ?
(10:32:20 AM) dgilmore: get things starting to move 
(10:32:22 AM) thl: jeremy, having something out before chritmas would be
nice
(10:32:32 AM) ***thl has some free time around christmas hopefully
(10:32:41 AM) jeremy: thl: yep, I was going to write it this morning but
had to interview someone instead :)
(10:32:43 AM) warren: dgilmore, core maintainer still must remain
involved as a co-maintainer at least, especially if it is a RHEL
package.
(10:32:55 AM) jwb: why
(10:33:02 AM) dgilmore: warren: hopefully they will still maintain the
package
(10:33:11 AM) warren: they better
(10:33:17 AM) |DrJef|: ah crap... someone said something to me in
channel..and its lost in scroll
(10:33:26 AM) jwb: warren, why is that a requirement?
(10:33:32 AM) jeremy: dgilmore: I'd prefer not harassing people quite
yet
(10:33:38 AM) dgilmore: jeremy: ok 
(10:33:41 AM) warren: jwb, this doesn't exclude other people from
helping
(10:33:48 AM) tibbs: Is there a reasonabe possibility that the whole
opening core thing won't happen?
(10:33:54 AM) rdieter: I've got about 2/3's of the kde packages up for
review already... (:
(10:33:57 AM) warren: jwb, this just enforces accountability from people
who are PAID and supposed to make sure it works.
(10:33:57 AM) jwb: RHEL ownership should have no impacts to this
(10:34:01 AM) thl: we probably need some rules for co-maintainership
soon
(10:34:18 AM) warren: tibbs, no possibility what-so-ever.
(10:34:30 AM) rdieter: over my dead body. (:
(10:34:32 AM) ***jwb is not happy with this statement
(10:34:44 AM) tibbs: ?
(10:34:53 AM) warren: jwb, it is not a statement of ownership or
territorial ego, but rather responsibility enforcement.
(10:35:11 AM) dgilmore: jwb: i read it that its going to happen.   there
is no way it will not happen 
(10:35:12 AM) rdieter: tibbs, rest assured, it will happen. (or heads
will roll).
(10:35:13 AM) tibbs: I'm just trying to determine whether any action on
core reviews now could end up being wasted effort.
(10:35:21 AM) jeremy: tibbs: not at all
(10:35:27 AM) jwb: warren, responsibility enforcement for RHEL.  which
again should have no impacts here
(10:35:44 AM) jwb: don't get me wrong.  i think it's _good_ to have the
RHEL owner maintain it in fedora.
(10:35:51 AM) jwb: i just don't like it being _required_
(10:35:56 AM) XulChris: |DrJef|: i seem to remember someone saying numpy
was rebuilt
(10:35:56 AM) rdieter: jwb: it's just common sense that fc/rhel
maintainer be involved.
(10:35:57 AM) warren: jwb, RHEL maintainers *better* keep themselves
aware of what's going on in their software
(10:36:00 AM) jeremy: jwb: there's nothing that says its required
(10:36:01 AM) tibbs: I want dibs on reviewing the httpd package.
(10:36:01 AM) dgilmore: jwb: it should not be required
(10:36:09 AM) jwb: jeremy, warren just said it was
(10:36:18 AM) dgilmore: jwb: im pretty sure that rdieter  does not
maintain qt4 in RHEL5
(10:36:18 AM) jeremy: jwb: warren doesn't know what he's talking
about :-)
(10:36:31 AM) jwb: ok
(10:36:36 AM) dgilmore: tibbs: your biased 
(10:36:40 AM) warren: required was too strong of a word, maybe "strongly
encouraged with a pointy stick"
(10:36:52 AM) jwb: warren, sure i'm good with that :)
(10:37:05 AM) thl: okay, seems we are all happy now again :)
(10:37:09 AM) nirik: tibbs: and after that you can review rpm. ;) 
(10:37:15 AM) thl: anything else regarding the merge?
(10:37:26 AM) c4chris: what a "dibs"
(10:37:29 AM) c4chris: ?
(10:37:33 AM) warren: rhymes with tibbs
(10:37:39 AM) dgilmore: c4chris: he is saying he wants it
(10:37:41 AM) tibbs: "first chance at"
(10:37:44 AM) jwb: c4chris, "i get the first shot at doing this"
(10:37:49 AM) thl: seems not
(10:37:51 AM) thl has changed the topic to: FESCO-Meeting -- Encourage
co-maintainership -- c4chris
(10:37:54 AM) thl: c4chris ?
(10:37:59 AM) c4chris: oh :-)
(10:38:12 AM) c4chris: nothing yet, sorry
(10:38:19 AM) c4chris: but I'll do it
(10:38:33 AM) XulChris: c4chris: http://en.wikipedia.org/wiki/Dibs
(10:38:34 AM) thl: jeremy, any news regarding the auto-cc problem in
bugzilla?
(10:38:44 AM) ***nirik was just about to ask that same thing. 
(10:39:14 AM) thl: jeremy lost
(10:39:23 AM) jeremy: thl: sorry, 3 things at once
(10:39:23 AM) thl: c4chris, please poke jeremy about it
(10:39:26 AM) nirik: I know it works for the broken deps and evr
reports. ;) 
(10:39:28 AM) ***thl waits
(10:39:44 AM) Anvilou [n=anvil] entered the room.
(10:39:46 AM) jeremy: thl: I haven't had a chance to sit down and
actually look at anything in the past week that's code related beyond
some minor python 2.5 fixage
(10:39:50 AM) c4chris: nirik, that's a special script...
(10:39:53 AM) jeremy: thl: warren was glancing at it too I think
(10:40:05 AM) c4chris: XulChris, thx
(10:40:13 AM) nirik: c4chris: yeah, just mentioning that it works for
them... which is at least something. 
(10:40:16 AM) Anvil left the room (quit: Read error: 113 (No route to
host)).
(10:40:16 AM) thl: well, we have reached the point where we start really
needing it
(10:40:36 AM) thl: warren, jeremy, I'd really like to see this fixed
before the mass-review
(10:40:47 AM) thl: better: this year...
(10:40:52 AM) thl: is that possible?
(10:40:57 AM) tibbs: Tying two things together,
(10:41:06 AM) tibbs: is it possible to require that all EPEL packages
have a co-maintainer?
(10:41:17 AM) jeremy: it's mostly just debugging the script (which is
in /cvs/fedora, fedora-accounts module if anyone wants to look at it)
(10:41:49 AM) thl: tibbs, if we want that: sure
(10:41:56 AM) tibbs: s/possible/reasonable/ ?
(10:41:57 AM) thl: tibbs, but I think we want that for fedora, too
(10:41:58 AM) c4chris: jeremy, I'll try to have a look then
(10:42:24 AM) jeremy: it's scary sopwith code :-)
(10:42:25 AM) thl: that was at least the impression I had
(10:42:42 AM) c4chris: I'll borrow warren's +3 sword :-)
(10:42:47 AM) thl: at least two maintainers if possible for all packages
(10:43:06 AM) abadger1999: jeremy: Which file is that?
bz-make-components.py?
(10:43:07 AM) thl: I'd even would like to see three for each package
(10:43:15 AM) warren: thl, so they can blame each other when both of
them failed to fix something? =)
(10:43:28 AM) thl: warren :)
(10:43:36 AM) thl: warren, well, they should watch each other IMHO
(10:43:51 AM) thl: and jump in when one is on holiday, raveling, ...
(10:43:55 AM) thl: traveling
(10:43:57 AM) warren: thl, as long as a higher body is accountable to
seeing when maintainers fail in a timely basis and step in
(10:44:05 AM) warren: don't count on maintainers to always do the right
thing
(10:44:15 AM) thl: sure
(10:44:16 AM) c4chris: "require" is perhaps too strong a word, but
"strongly encourage" is fine
(10:44:22 AM) thl: c4chris, +1
(10:44:26 AM) bpepple: c4chris: +1
(10:44:33 AM) warren: thl, if I'm going traveling I just ask other
people that I trust to take care of stuff.
(10:44:41 AM) XulChris: strongly encourage with a pointy stick? ;-)
(10:44:50 AM) c4chris: XulChris, :-)
(10:44:50 AM) warren: naming explicit co-maintainers might help, but it
doesn't gain us anything more than what we have now.
(10:45:13 AM) thl: c4chris, can you work out some rules for
co-maintainership?
(10:45:21 AM) thl: that seems needed
(10:45:34 AM) c4chris: warren, sure, but if you do that you migth as
well name them as co-maintainers: makes things c;earer for everyone
(10:45:36 AM) thl: some ideas can be found in on the schedule pages iirc
(10:46:01 AM) c4chris: s/;/l/  doh
(10:46:12 AM) c4chris: thl, yup, will do
(10:46:18 AM) thl: c4chris, many thx
(10:46:22 AM) thl: let's move on
(10:46:28 AM) thl has changed the topic to: FESCo meeting -- MISC --
what to do with all those broken deps and upgrade paths
(10:46:41 AM) thl: do we want to discuss this again? nirik ?
(10:46:55 AM) tibbs: It's been long enough; it's time for someone else
to step in and rebuild the python packages.
(10:47:05 AM) nirik: dunno. There is one non devel broken dep (linphone)
and 2 evr non devel packages. 
(10:47:11 AM) thl: tibbs, that the next point on the schedule ;)
(10:47:27 AM) thl: let's ignore it for now
(10:47:29 AM) thl has changed the topic to: FESCo meeting -- MISC --
lots of python stuff still needs rebuilding
(10:47:29 AM) tibbs: Yes, release branches are in pretty good shape now.
(10:47:31 AM) nirik: I tried to poke the core packages with EVR
problems,  but little effect
(10:48:01 AM) thl: I'd say somebody should just queue all the remaining
python stuff in extras for rebuilding
(10:48:06 AM) tibbs: I haven't checked; are there many extras packages
with broken py deps that depend on core packages with broken py deps?
(10:48:27 AM) nirik: thats going to require good ordering... since some
depend on others. 
(10:48:31 AM) tibbs: If so, that's going to cause pain.
(10:48:33 AM) thl: there only a few broken python packages in core iirc
(10:48:44 AM) abadger1999: I thought jeremy fixed almost all the Core
packages?
(10:48:45 AM) nirik: xen is the only one I know of off hand anymore. 
(10:48:48 AM) jeremy: tibbs: the only things left broken in core are
kdebindings and xen I think
(10:48:50 AM) XulChris: blender is still failing to build with new
python in x86_64, im working on fixing it
(10:49:05 AM) ***jeremy was a package monkey and built lots and lots of
stuff ;-)
(10:49:05 AM) nirik: kdebindings I guess too
(10:49:07 AM) ***bpepple knows his python-telepathy package will fail a
rebuild right now.
(10:49:08 AM) tibbs: jeremy: Good, that means that we're mostly free to
mass-rebuild extras stuff.
(10:49:15 AM) jeremy: tibbs: should be afaik
(10:49:36 AM) tibbs: nirik: I'm off until Monday, so if you and I want
to have a go...
(10:49:43 AM) rdieter: jeremy: did you try (re)building kdebindings?  Or
just left it alone? (:
(10:49:53 AM) thl: does anyone want to have the
python-packages-rebuild-monkey title for extras? Or shall we ignore it
(no!)
(10:49:54 AM) jeremy: rdieter: I tried, it failed due to something
unrelated
(10:50:01 AM) jeremy: rdieter: iirc, it was the automake upgrade that
broke it
(10:50:05 AM) nirik: tibbs: I can assist... not sure how much time I
have for it tho... would likely be evenings. 
(10:50:07 AM) rdieter: jeremy: ah.
(10:50:20 AM) jwb: note that thl's request need not be a FESCo member
(10:50:38 AM) thl: yeah, somebody just neess to do it
(10:50:48 AM) tibbs: Well, as I wrote above, I'm happy to work on it,
but you have to keep in mind that I'm no Python expert.
(10:51:03 AM) jeremy: if there are problems with packages rebuilding,
feel free to poke me
(10:51:03 AM) rdieter: I'd say take to the extras-list asking for monkey
volunteers.
(10:51:05 AM) thl: tibbs, okay, you won :)
(10:51:06 AM) bpepple: thl: I should have some time to work on it early
next week, if no one steps up.
(10:51:15 AM) jeremy: at this point, I'm pretty good at looking at the
logs and being able to suggest a fix
(10:51:19 AM) thl: rdieter, +1
(10:51:30 AM) tibbs: jeremy: Thanks, I'll lean on you and nirik.
(10:51:38 AM) thl: tibbs, can you coordinate the efforts?
(10:51:41 AM) tibbs: If course, folks are welcome to help.
(10:51:47 AM) thl: and post to f-e-l and ask for help maybe?
(10:51:56 AM) tibbs: thl: Sure; I'll stick around here and poke the list
if there are problems.
(10:52:05 AM) thl: tibbs, k, thx
(10:52:09 AM) nirik: yeah, I would expect most would rebuild just
fine... possibly with a BR: python-devel added. 
(10:52:11 AM) thl has changed the topic to: FESCo meeting -- MISC --
Stop running repoview for debuginfo packages [WWW]
https://www.redhat.com/archives/fedora-maintainers/2006-December/msg00075.html
(10:52:23 AM) thl: well, get's a +1 from me
(10:52:29 AM) tibbs: Is there any reason this isn't a good idea?
(10:52:30 AM) bpepple: +1 here also.
(10:52:32 AM) rdieter: +1
(10:52:35 AM) jwb: +1
(10:52:40 AM) abadger1999: tibbs: Can't think of any
(10:52:40 AM) thl: (in case it's not done yet and mschwent is waiting
for fesco)
(10:52:41 AM) tibbs: +1
(10:52:42 AM) abadger1999: +1
(10:52:52 AM) thl: k, settled 
(10:52:52 AM) jeremy: +1
(10:52:59 AM) thl has changed the topic to: FESCo meeting -- Packaging
Committee Report
(10:53:27 AM) thl: abadger1999, rdieter, tibbs ?
(10:53:32 AM) rdieter: sir mschwent, though art blessed by the FESCo,
and bid you god speed. (;
(10:53:42 AM) tibbs: Not much to report; we worked on rdieter's
icon-cache proposal.
(10:53:44 AM) thl: :)
(10:53:46 AM) rdieter: thl: non-report mostly, discuss iconcache
proposal, close to consensus.
(10:54:09 AM) rdieter: (then my wiki update got lost, so I need to re-do
it). grr...
(10:54:12 AM) thl: wasn#t there something we handled pack to the PC last
week?
(10:54:19 AM) thl: or two weeks ago?
(10:54:22 AM) ***thl can't remember
(10:54:28 AM) rdieter: if there was, we didn't discuss it. (:
(10:54:32 AM) tibbs: thl: That was the thing about the thing....
(10:54:34 AM) abadger1999: Was it rpm groups?
(10:54:38 AM) c4chris: group tag, no?
(10:54:40 AM) thl: abadger1999, yes
(10:54:50 AM) thl: what was the final decision now? 
(10:54:57 AM) ***thl is getting old
(10:55:08 AM) tibbs: The vote was to allow the rpm maintainer to 
(10:55:14 AM) scop: OT: I found something susceptible in
bz-make-components.py about initial cc stuff - who should I talk to?
(10:55:16 AM) tibbs: make the group tag optional in spec files
(10:55:48 AM) tibbs: At this point, no policy has changed about whether
a spec mist have a Group: tag.
(10:55:49 AM) jeremy: scop: warren or me
(10:56:15 AM) rdieter: tiibbs: thanks for the clarification (I myself
was confused on that too).
(10:56:21 AM) tibbs: Still, I think the recent rpm announcement has
bearing here, and stuff is going to be tied up in that for a while.
(10:56:23 AM) mdomsch [n=Matt_Dom] entered the room.
(10:56:26 AM) warren: scop, write us both e-mail
(10:56:33 AM) thl: tibbs, well, the consesus in FESCo was that we want
to wait a bit further iirc
(10:56:37 AM) scop: jeremy, warren: ok
(10:56:37 AM) thl: or am I wrong with that?
(10:56:42 AM) jeremy: scop: and thanks!
(10:56:52 AM) bpepple: thl: That's what I thought also.
(10:57:05 AM) thl: did the PC discuss it again after that?
(10:57:12 AM) tibbs: thl: I understood the concensus that we would wait
on any policy changes, but that the internal rpm code change could move
forward.
(10:57:27 AM) rdieter: thl: no further PC disussion has taken place
(afaik)
(10:57:29 AM) thl: tibbs, yeah, that sounds fine
(10:57:33 AM) jwb: tibbs, yes that's what i remember
(10:57:45 AM) thl: then let's move on now
(10:57:47 AM) thl has changed the topic to: FESCO-Meeting -- packages
with static libs approval -- sparse (mdomsch) -- [WWW]
https://www.redhat.com/archives/fedora-packaging/2006-December/msg00034.html
(10:57:50 AM) thl: +1
(10:57:57 AM) rdieter: +1
(10:58:15 AM) tibbs: The reasoning here seems reasonable.
(10:58:21 AM) bpepple: +1
(10:58:26 AM) ***mdomsch was just in time
(10:58:42 AM) c4chris: +1
(10:58:55 AM) dgilmore: im ok with this 
(10:58:55 AM) tibbs: Plus at some point we have to realize that that we
can only require so much of upstream.
(10:58:56 AM) thl: k, nobody yelled, some +1, accepted
(10:58:59 AM) tibbs: +1
(10:59:01 AM) abadger1999: +1
(10:59:13 AM) jwb: +1
(10:59:22 AM) thl has changed the topic to: FESCO-Meeting -- kmod
approval -- gspca [WWW]
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209112
(10:59:44 AM) thl: jwb, I#d like to hear your opinion
(11:00:12 AM) thl: I'm a bit unsure myself (read: +0.5 currently)
(11:00:21 AM) jwb: if i'm the only one that dislikes it, then i won't
throw a fit
(11:00:31 AM) jwb: the lack of commitment to upstream is my biggest
concern
(11:00:41 AM) thl: jwb, do you dislike it? why?
(11:00:59 AM) rdieter: Is this the webcam driver for which spot spoke of
last time?
(11:01:12 AM) bpepple: rdieter: I believe so.
(11:01:13 AM) thl: rdieter, yes
(11:01:36 AM) warren: "here is documentation that talks of conflict with
drivers that are already in the kernel"
(11:01:37 AM) jwb: thim1, because they don't seem to have any desire to
upstream it, which means it remains a kmod for eternity 
(11:01:38 AM) warren: Isn't this bad?
(11:01:49 AM) jwb: warren, yeah, it's not good
(11:01:56 AM) rdieter: spot's vouging for it is good enough for me: +1
(11:02:08 AM) dgilmore: i used to use another driver written by the same
guy.  
(11:02:16 AM) jwb: spot voted for it?
(11:02:26 AM) dgilmore: to me it seems he really has no desire  to
upstream his work
(11:02:40 AM) dgilmore: but his work seems to be pretty stable 
(11:02:43 AM) tibbs: [Thu Dec 7 2006] [12:57:50] <spot>      im
interested in gspca
(11:02:45 AM) rdieter: jwb: spot gave a fwiw, that he has talked with
upstream.
(11:02:47 AM) tibbs: [Thu Dec 7 2006] [12:57:55] <spot>      because it
makes my webcam work in linux
(11:02:47 AM) tibbs: [Thu Dec 7 2006] [12:57:57] <thl>       rdieter,
well, I'll try to make it more explict in the future ;)
(11:02:47 AM) tibbs: [Thu Dec 7 2006] [12:58:04] <spot>      ive talked
to the upstream author (he is french)
(11:02:47 AM) tibbs: [Thu Dec 7 2006] [12:58:25] <spot>      and he
wants to upstream it, but because of a massive disagreement in the v4l
camp, its not likely to ha
(11:02:47 AM) tibbs: ppen anytime soon
(11:02:49 AM) tibbs: [Thu Dec 7 2006] [12:58:47] <spot>      code is
good (to my eyes), rather well tested
(11:03:11 AM) tibbs: Does that help a bit?
(11:03:22 AM) ***thl still is unsure what to do
(11:03:29 AM) dgilmore: i will give it a +1 because i think he does do
good work 
(11:03:50 AM) rdieter: So, the blocker seems v4l uncertainly, not an
unwillingness to upstream.
(11:03:52 AM) jwb: tibbs, it changes my vote from -1 to -0.5
(11:03:52 AM) warren: +1 with a "revisit 1 year from now.  if no
progress toward upstream we consider removing it"
(11:04:05 AM) thl: warren, +1
(11:04:09 AM) jwb: warren, i could live with that
(11:04:10 AM) bpepple: warren: +1
(11:04:20 AM) c4chris: warren, +1
(11:04:33 AM) warren: That's called encouragement with a pointy stick.
(11:04:35 AM) abadger1999: warren: +1
(11:04:39 AM) jwb: indeed
(11:04:49 AM) warren: pointy stick diplomacy
(11:04:51 AM) tibbs: warren: +1
(11:04:57 AM) thl: k, accepted then; who will post to the bug?
(11:05:02 AM) tibbs: I think kmods should require a co-maintainer.
(11:05:11 AM) tibbs: Maybe even two as long as we're not using dkms.
(11:05:27 AM) jwb: thl, i will
(11:05:29 AM) thl: or as long the buildsys does not hanlde it
(11:05:32 AM) thl: jwb, thx
(11:05:36 AM) thl: let's move on
(11:05:39 AM) thl has changed the topic to: FESCo meeting -- Maintainer
Responsibility Policy -- bpepple -- EOL plans
(11:05:43 AM) thl: bpepple ?
(11:06:27 AM) bpepple: Looks like Legacy is dropping F4 and earlier
dist.
(11:06:35 AM) thl: s/dropping/dropped/
(11:06:38 AM) thl: afaics
(11:06:50 AM) XulChris: really? so what does legacy cover now? anything?
(11:06:57 AM) rdieter: so I guess that makes our decision(s) easier...
(:
(11:07:01 AM) thl: so I think let's close FE3 and FE4, too
(11:07:04 AM) thl: by years end?
(11:07:07 AM) scop: +1
(11:07:10 AM) tibbs: Legacy is essentially done with at this point.
(11:07:12 AM) bpepple: +1
(11:07:16 AM) jwb: +1
(11:07:27 AM) abadger1999: +1
(11:07:33 AM) dgilmore: if legacy is done
(11:07:34 AM) warren: +1 except for clamav
(11:07:37 AM) warren: =)
(11:07:38 AM) tibbs: I'm conflicted.
(11:07:44 AM) dgilmore: ill close the builders for FE-3 and FE-4 today 
(11:07:49 AM) rdieter: +1
(11:07:54 AM) thl: dgilmore, why today?
(11:08:00 AM) tibbs: today doesn't equal "by years end".
(11:08:06 AM) dgilmore: thl: if they are done they are done
(11:08:29 AM) thl: well, we at least should give people one or two weeks
to prepare
(11:08:38 AM) tibbs: We should at least wait until Legacy makes their
announcement.
(11:08:41 AM) dgilmore: thl: ok 
(11:08:43 AM) thl: dgilmore, years end would be better, even is legacy
is done already
(11:08:44 AM) dgilmore: January 1
(11:08:51 AM) XulChris: tibbs: according to the legacy web page they
already announced it
(11:09:00 AM) bpepple: http://fedoraproject.org/wiki/Legacy
(11:09:02 AM) warren: just close it Jan 1st
(11:09:15 AM) jeremy: scop: fwiw, that looks sane to me
(11:09:18 AM) thl: bpepple, can you post that info to the list please?
(11:09:19 AM) abadger1999: XulChris: Regardless, we should announce it
so people that care can get their packages into shape before EOL.
(11:09:20 AM) rdieter: make sure to be there at year-end count-down,
throw the switch to close the builders.. (:
(11:09:27 AM) bpepple: thl: yup.
(11:09:46 AM) thl: btw, do we want to run a final package cleanup in FE3
nad FE4?
(11:09:53 AM) thl: to save space on the servers?
(11:10:08 AM) thl: e.g. leave only the package with the highest EVR
around?
(11:10:18 AM) dgilmore: thl: we should cut down to just the latest
package 
(11:10:26 AM) dgilmore: thl: yes
(11:10:28 AM) tibbs: I don't see why not.
(11:10:30 AM) rdieter: thl/dgilmore: +1
(11:10:34 AM) c4chris: sure
(11:10:37 AM) scop: need to check for broken deps after that though,
just in case
(11:10:38 AM) warren: jeremy, scop: will that blow away whatever is
already in auto-CC field?
(11:10:52 AM) thl: k, settleed then
(11:10:58 AM) thl has changed the topic to: FESCo meeting -- Alternative
paths of membership advancement -- warren
(11:11:03 AM) thl: warren, any news?
(11:11:03 AM) warren: thl, skip me
(11:11:08 AM) warren: busy
(11:11:11 AM) thl has changed the topic to: FESCo meeting -- Free
discussion around Fedora Extras
(11:11:11 AM) scop: warren, I don't know, didn't dig that deep into what
the script actually does
(11:11:18 AM) nirik: what about open fe3/fe4 bugs? should be all closed?
(11:11:19 AM) thl: anything else?
(11:11:28 AM) c4chris: nirik, yes
(11:11:28 AM) thl: nirik, good question
(11:11:32 AM) fab [n=bellet] entered the room.
(11:11:32 AM) thl: c4chris, +1
(11:12:16 AM) abadger1999: nirik: Similar to what Dave Jones does with
kernel bugs, I'd think.
(11:12:19 AM) tibbs: Everyone should go through their bugs and move some
of them forward.
(11:12:25 AM) thl: what do people think of the 'File deps outside "/etc
{/usr,}/{s,}bin/"' stuff?
(11:12:29 AM) nirik: if so, perhaps someone should identify them and put
a 'we are closing jan 1st... ' message in them
(11:12:33 AM) thl: is it worth the trouble?
(11:12:52 AM) thl: abadger1999, +1
(11:12:53 AM) rdieter: thl: I don't think seth, et all, would have asked
if it weren't.
(11:13:16 AM) thl: rdieter, the question is yet again: FESCo's or PC's
job?
(11:13:19 AM) tibbs: thl: Cutting down file deps is a good idea in any
case.
(11:13:23 AM) c4chris: I'd say mark them closed.  People will reopen in
the proper branch if they care
(11:13:33 AM) bpepple: c4chris: +1
(11:13:34 AM) thl: I think we should have something about it in the
guidelines
(11:13:47 AM) nirik: I see 80 open fe4/fc5 bugs. 
(11:13:48 AM) rdieter: thl: ah, in that case, partially both.  PC's job
to codify it, FESCo's job to implement it. (:
(11:13:49 AM) thl: and then cleanup the exisiting packages according to
the guidlenes
(11:13:56 AM) tibbs: I'm still not completely sure of the underlying
issue.
(11:13:58 AM) thl: rdieter, exactly
(11:14:07 AM) tibbs: There are separate file lists for some directories?
(11:14:17 AM) thl: tibbs, yes
(11:14:44 AM) jwb: did everyone see my post to fesco list today?
(11:14:55 AM) thl: tibbs, "/etc {/usr,}/{s,}bin/" is im primary.xml
iirc, the other stuff in filefoo.xml
(11:15:14 AM) c4chris: jwb, answered, even :-)
(11:15:15 AM) thl: jwb, yes, saw it
(11:15:49 AM) jwb: is there anyone that has a problem with me staying
for now on a limited basis until i can get some scheduling things
resolved?
(11:16:04 AM) thl: rdieter, abadger1999, tibbs, thim1, can you bring the
'File deps outside "/etc {/usr,}/{s,}bin/"' stuff up in PC and "codify"
guidelines?
(11:16:14 AM) bpepple: jwb: I don't see any problem.
(11:16:15 AM) rdieter: thl: sure.
(11:16:24 AM) thl: rdieter, thx
(11:16:25 AM) tibbs: thl: Sure, but how strong should the prohibition
be?
(11:16:39 AM) tibbs: "file deps outside those directories should be
justified in a comment"?
(11:16:42 AM) rdieter: I'd argue on the order of like static libs,
strongly discouraged.
(11:16:43 AM) thl: tibbs, don#t know, I got to the toppic accidentally,
too :)
(11:16:50 AM) tibbs: or "...should be voted on by FESCo"?
(11:16:52 AM) dgilmore: jwb: i have no problem with it 
(11:17:04 AM) thl: jwb, I think you should IMHO
(11:17:11 AM) tibbs: rdieter: But strong discouragement usually means
"the committee must vote".
(11:17:19 AM) tibbs: We're getting into a lot of committee voting.
(11:17:20 AM) thl: tibbs, no, not yet another think fesco needs to vote
on
(11:17:26 AM) jwb: thl, just to clarify: think i should stay?
(11:17:37 AM) thl: good reasons during review and a comment in the spec
file should be fine
(11:17:46 AM) thl: jwb, stay in fesco please ;)
(11:17:54 AM) rdieter: thl++
(11:17:55 AM) tibbs: jwb: Your contributions have always been valuable.
I don't see why you'd need to leave.
(11:17:56 AM) tyll: Isn't there a way to add the needed information for
file deps outside "/etc {/usr,}/{s,}bin/" to primary.xml without adding
every other file?
(11:18:05 AM) c4chris: thl, +1
(11:18:09 AM) tibbs: At least you're coming to the meetings.
(11:18:18 AM) abadger1999: tibbs: +1
(11:18:22 AM) rdieter: gotta go in a sec to lunch...
(11:18:27 AM) abadger1999: jwb: Has always had good insights.
(11:18:35 AM) scop: on that subject, I will probably miss the next two
meetings
(11:18:39 AM) daMaestro [n=jon] entered the room.
(11:18:40 AM) thl: yeah, it's quite late already...
(11:18:49 AM) tibbs: Note that was not a dig at anyone at all.  Just a
note that you're still trying to be here.
(11:19:02 AM) thl: while at it: do we want to have a meeting on
2006-12-28?
(11:19:08 AM) jwb: ok.  it'll be limited for a while but i'll do what i
can
(11:19:13 AM) jwb: thanks all
(11:19:21 AM) thl: jwb, thx for your work
(11:19:22 AM) dgilmore: thl: probably best to skip that 
(11:19:28 AM) dgilmore: alot of people will be on holidays
(11:19:30 AM) jwb: thl, np
(11:19:41 AM) c4chris: dgilmore, right
(11:19:44 AM) rdieter is now known as rdieter_away
(11:19:48 AM) abadger1999: tyll: /etc and the bin directories are what's
in primary.xml to provide the most used information but limit the size
of the download.
(11:19:48 AM) tibbs: I'll be in computer range on the 28th.
(11:19:56 AM) bpepple: thl: 12-28 works fine for me.
(11:20:18 AM) thl: let's discuss next week again if we want to hae a
meeting on the 28th
(11:20:24 AM) thl: k, anything else?
(11:20:32 AM) ***thl will end the meeting in 60
(11:20:50 AM) thl: btw, are you guys still fine with the way I run the
meetings?
(11:21:04 AM) c4chris: thl, yup
(11:21:09 AM) tyll: abadger1999, but adding 32 more files won't be so
much overhead, so maybe this would be easier than fixing the packages
(11:21:13 AM) thl: I know, the schedule pages got a bit more
complicated, but they help me getting and overview of what going on
(11:21:25 AM) tibbs: thl: No need to feel insecure; the meetings run
great.
(11:21:34 AM) bpepple: thl: +1
(11:21:46 AM) ***thl will end the meeting in 30
(11:22:02 AM) [splinux] [n=splinux] entered the room.
(11:22:04 AM) scop: I'd like to think that if people here are not happy
with something, they're not quite about it ;)
(11:22:13 AM) scop: s/quite/quiet/
(11:22:16 AM) ***thl will end the meeting in 15
(11:22:20 AM) rsc: hm, mein Flaming im Bezug hat zumindest mal eine
E-Mail bewirkt. Nett.
(11:22:29 AM) c4chris: scop, don't worry :)
(11:22:34 AM) rsc: uh, wrong channel. sorry.
(11:22:35 AM) thl: -- MARK -- Meeting End
}}}

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