From Fedora Project Wiki

< Extras‎ | SteeringCommittee
Revision as of 16:25, 24 May 2008 by Ravidiip (talk | contribs) (1 revision(s))
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

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

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)

Kmod Approval

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
Retrieved from "https://fedoraproject.org/w/index.php?title=Extras/SteeringCommittee/Meeting-20061214&oldid=639"