From Fedora Project Wiki

2006 October 19 FESCo Meeting

Attending

  • thl
  • dgilmore
  • warren
  • rdieter
  • scop
  • abadger1999
  • bpepple
  • tibbs
  • ch4chris
  • jwb (late)

Summary

EPEL

  • There are some unresolved questions from within Red Hat that need to be sorted out.

Enhance AWOL

  • tibbs's original work was lost. This will be resurrected this week and discussed next week.

When to Touch Other People's Packages

  • thl will send a writeup to the list.

Packaging Committee Report

  • Committee Membership dropped to 9 members.
  • disttag proposal to allow using 6.89 for devel/rawhide passed.
  • Core has already said they are not going to use this/veto.
  • FESCo voted down: "Extras will use .fc6.89 for devel even if Core does not plan to use it" so the current plan is that the disttag for devel will remain the next release. (ie: fc7 for upcoming devel)
  • Meeting time was moved to Tuesdays.

Misc

Extras Package Enables a Repository

Kmod Support in the Buildsys

  • thl status report:
  • Nothing currently automated
  • Have to hardcode kversion and kvariant in the spec
  • Needs updating for each kernel update
  • Working on merging kmodtool changes from kerneldrivers.org
  • Working on getting kmodtool into Core

Legacy Branch Request

  • pygpgme needs to be branched for FC-3 so that infrastructure can use it on RHEL4.
  • Asked if infrastructure uses the packages directly out of the FC-3 tree or if they rebuild the packages anyway.
  • After meeting follow up: Yes, infrastructure uses the FC-3 built packages directly.

Package Database

  • Infrastructure has a skeleton up but no data imported yet.
  • Need to proxy from the internal servers to the outside world so everyone can see it.
  • Brain dump of stages to be functional http://www.fedoraproject.org/wiki/Infrastructure/PackageDatabase/RoadMap
  • comps.xml being generated from the PackageDB needs to be looked at further. Dependencies inside comps may make this a harder task.
  • comps info needs to be part of the package-collection data rather than package as the information can be different in different collections.

Log

(10:00:48) thl has changed the topic to: FESCo meeting in progress -- init
(10:00:58) ***dgilmore is here
(10:00:59) thl: hi everyone!
(10:01:06) thl: Who's around?
(10:01:10) ***jima is here, but rabble.
(10:01:19) warren: I'm back home as of today, still settling in
(10:01:21) ***rdieter is here.
(10:01:28) ***scop is here
(10:01:31) jima: geez, i make so many of these meetings, i might as well run for fesco next time.
(10:01:31) ***nirik is in the rabble seats, and also working on some other things, but sorta around.
(10:01:35) thl: warren, Ignore the flame war on fedora-maintainers ;)
(10:01:54) ***abadger1999 here
(10:01:58) warren: which flamewar?
(10:02:01) ***bpepple is here.
(10:02:07) rdieter: exactly.
(10:02:10) tibbs: I'm here but my keyboard is dying.
(10:02:15) thl: k, so let's start slowly; abadger1999, do you write the summary today?
(10:02:33) abadger1999: Yep.  I'm back on top of things.
(10:02:53) ***c4chris__ is here
(10:03:01) thl has changed the topic to: FESCo meeting in progress -- EPEL
(10:03:16) dgilmore: thl: we are waiting on CVS branches
(10:03:17) thl: there are still some thing inside Red Hat that need to be sorted out
(10:03:24) dgilmore: which needs some help from jeremy
(10:03:32) thl: jeremy is fighting hard for us
(10:03:37) thl: but we can't start yet
(10:03:38) adrianr [n=adrian]  entered the room.
(10:03:55) rdieter: which implies there's someone/something that's resisting this?
(10:03:56) thl: that sucks, I know
(10:05:01) thl: rdieter, afaics it's more "I don't like a particular detail and thus I raise my hands to stop this for now"
(10:05:07) ***cweyl is lurking in the rabble seats
(10:05:23) c4chris__: anything we can do to help ? what's the "detail" ?
(10:05:51) thl: I don#t know the complete details, sorry
(10:06:01) c4chris__: np
(10:06:09) rdieter: hopefully jeremy's fedora-fu, ninja, kickboxing skills will be sufficient.
(10:06:22) thl: I hope so
(10:06:25) thl: so let's move on
(10:06:25) dgilmore: rdieter: if  not  maybe we will need spots nigas also
(10:06:35) rdieter: orbital laser?
(10:06:40) thl has changed the topic to: FESCo meeting in progress --  Enhance AWOL
(10:06:47) thl: rdieter, good idea ;)
(10:06:56) thl: well, "Enhance AWOL"
(10:07:05) thl: it seems no one really brings this forward
(10:07:41) dgilmore: thl: i think we need a better way to determine  awol  but i have no idea what or how
(10:07:41) thl: What i#d like to see is something similar to what I did with "When to touch other peoples packages"
(10:07:50) thl: e.g. write a proposal
(10:07:54) thl: present in to the list
(10:07:57) thl: sorry
(10:08:11) thl: present in to the FESCo (with a difff against the current one)
(10:08:16) thl: then to the list
(10:08:31) thl: modify it if needed
(10:08:35) tibbs: Enhancing AWOL was only about clarifying how to orphan multiple packages at once.
(10:08:41) thl: and then vote and agree on it in a meeting
(10:08:48) thl: tibbs, I know
(10:09:07) thl: but without somebody who does above steps it's not getting forwards
(10:09:23) thl: So I'm inclinded to say we drop it soon if no one steps up to handle it
(10:09:51) thl: come one; It's not that much work for this particular issue
(10:09:55) thl: anybody?
(10:10:07) thl: non FESCo-members are also invited
(10:10:16) ***dgilmore nominates jima
(10:10:41) dgilmore: i would  do it  but dont really have the time right now
(10:10:42) bpepple: I'll do it.  Though I probably cant't get to it till next week.
(10:11:22) rdieter: dgilmore: not nice volunteering someone else (and, seconded, by the way). (:
(10:11:32) thl: bpepple, k, thx; then I'll set November, the 2nd as target for now
(10:11:39) jima: rdieter: hey! :P
(10:11:40) bpepple: np.
(10:11:56) dgilmore: rdieter: :)  yeah
(10:12:17) thl: bpepple, and please be sure to show us a diff somehow (maybe with the included wiki stuff)
(10:12:20) tibbs: Sorry, didn't I present a document to the committee for enhancing AWOL already?
(10:12:41) thl: tibbs, I got the impression it's not ready yet
(10:13:10) thl: is it ready? is a diff against the old one avilable somewhere? that would make reviewing a lot easier
(10:13:52) tibbs: I originally posted a set of exactly what changed, but it all wasnot in the proper schedule format.  Someone else took it and seems to have removed all of that.
(10:14:25) thl: well, the problem was: mjk had the page in this namespace in hte wiki
(10:14:33) thl: and hje deleted it when he left us
(10:14:42) bpepple: D'Oh!
(10:14:53) thl: I recovered the latest version
(10:15:03) thl: but maybe it wasn't the latest version
(10:15:16) Finalzone [n=luya]  entered the room.
(10:16:07) thl: tibbs, do you want to proceed with it? or shall we hand it over to bpepple for now?
(10:16:08) tibbs: Originally the page was under my namespace, but I moved it under Schedule.
(10:16:21) _wart_ [n=wart]  entered the room.
(10:16:27) tibbs: I'm happy to hand it off if bpepple wants to work on it.
(10:16:51) thl: tibbs, well, I'd would like to see the latest version first
(10:17:09) thl: that could save us all some work if that incluides everything we need already
(10:17:20) thl: let's look out for it after the meeting
(10:17:37) thl: and then decide how owns this topic from now on
(10:17:55) thl has changed the topic to: FESCo meeting in progress --   When to touch other peoples packages
(10:18:06) thl: any further modifications needed?
(10:18:10) tibbs: OK, I have the message I originally mailed to the steering committee which details the proposed changes.
(10:18:19) thl: otherwise I'll send it to the list soon
(10:18:23) tibbs: Sorry, that was about AWOL.
(10:18:26) thl: tibbs, great
(10:18:33) c4chris__: thl, +1
(10:18:44) thl: can you send it to me? I'll put it in the wiki
(10:18:57) thl: tibbs, then we can decide later how to proceed
(10:19:35) thl: k, I'll send "When to touch other peoples packages" to the list soon
(10:19:51) thl has changed the topic to: FESCo meeting in progress -- Packaging Committee Report
(10:20:17) thl: spot, abadger1999, tibbs, scop ?
(10:20:46) rdieter: we dropped committee from 10->9 members, dropped quorum 6->5
(10:21:05) bpepple: rdieter: Did someone leave?
(10:21:25) rdieter: yes.
(10:22:03) abadger1999: jpo doesn't have enough time at present.
(10:22:09) rdieter: and (barely) passed disttag proposal to use 6.89 for devel/rawhide.
(10:22:28) rdieter: f13 promised core veto.
(10:22:39) ***dgilmore  really doesnt like that idea
(10:22:54) scop: meeting time was moved to Tuesday starting from next week
(10:23:02) thl: rdieter, well, I'd try my best to veto that, too
(10:23:07) ***nirik wonders what the advantage would be... easier detection of packages needing rebuild?
(10:23:15) thl: well, as long as I don't see a list of benefits
(10:23:20) rdieter: nirik: that's one.
(10:23:21) thl: that could change my mind
(10:23:39) rdieter: makes mass rebuilds easier.
(10:23:43) thl: rdieter, I don't buy that; detecting when a package was build is quite easy
(10:23:49) abadger1999: nirik: yes, but it's not fool proof, which is one of f13's problems with it.
(10:23:55) jima: setting dist to .fc6.89 for rawhide?
(10:23:58) thl: and I'm not even sure we need a mass-rebuild each time
(10:24:06) tibbs: The point is to let Extras consider it.
(10:24:19) dgilmore: we  would need to change the buildsys macros  reight before mass rebuild  to implement that and have fc7  packages have fc7
(10:24:19) tibbs: If extras doesn't decide to use it, no problem.
(10:24:21) tibbs: Core has decided not to use it.
(10:24:39) tibbs: dgilmore: Yes, that's the idea.
(10:24:57) thl: tibbs, well, Core and Extras should use the same stuff
(10:25:04) ***nirik thinks it looks like just added complexity.
(10:25:06) thl: tibbs, that why we created the Packaging COmmittee
(10:25:08) dgilmore: tibbs: thats extra work for me  or  whoever else helps me  for zero gain that i can see
(10:25:17) ***dgilmore  would need to really be sold on the idea
(10:25:20) bpepple: thl: +1
(10:25:22) thl: I even see disadvantages
(10:25:34) tibbs: Packaging committee just says "yes, this is allowed".  We won't dictate policy for the Extras buildsys.
(10:25:46) thl: so let's do that step by step:
(10:26:23) f13: thl: don't forget, sometiems the first massrebuild isn't the last massrebuild.  OMGGCCBUG!
(10:26:27) thl: can I get some -1, 0, or +1 for "extras won't use .fc6.89 for devel if core does not plan to use it"
(10:26:27) f13: (:
(10:26:38) thl: f13, I know, I know :)
(10:26:40) jwb_gone: thl, +1
(10:26:46) jwb_gone is now known as jwb
(10:26:48) dgilmore: thl   i vote -1
(10:26:49) thl: f13, I'm on your side here ;)
(10:26:54) bpepple: thl: +1
(10:27:00) abadger1999: thl: Double negative?
(10:27:05) scop: 0 (I voted for 0 in packaging committee too)
(10:27:10) jwb: yeah, double negatives are weird
(10:27:13) tibbs: I abstain here.
(10:27:15) thl: abadger1999, yeah, that's a bit problematic
(10:27:16) jwb: i vote to not sure it
(10:27:16) abadger1999: A +1 == do not use .fc89, right?
(10:27:21) jwb: s/sure/use
(10:27:29) ***jwb apologizes for being late.  real life
(10:27:33) abadger1999: err .fc6.89
(10:27:35) rdieter: abadger1999: right.
(10:27:40) abadger1999: +1
(10:27:44) c4chris__: I don't like .fc6.89 as a disttag.  I'm not sure if that's a +1 or a -1
(10:27:58) dgilmore: c4chris__: its a -1
(10:27:58) jwb: tibbs, who brought up this proposal?
(10:28:07) abadger1999: It's a +1
(10:28:09) f13: jwb: Axel Thimm
(10:28:22) jwb: f13, ok thank oyu
(10:28:28) ***f13 sees chaos with the vote (:
(10:28:32) c4chris__: dgilmore, not according to abadger1999 ...
(10:28:35) thl: f13, agreed, sorry
(10:28:40) dgilmore: as the person  most likely to implement it I really want to strongly oppose it
(10:28:45) f13: nobody knows which way they're voting, just like a US President election
(10:28:58) ***dgilmore is confused now
(10:29:01) abadger1999: let's rephrase: "extras will use .fc6.89 for devel even if core does not plan to use it"
(10:29:06) f13: dgilmore: funny, thats me on the Core side and I feel exactly like you.
(10:29:06) jwb: dgilmore, thl used a double negative :)
(10:29:21) abadger1999: Vote -1 to disagree with using .fc6.89
(10:29:22) bpepple: abadger1999: -1
(10:29:25) abadger1999: Vote +1 to agree
(10:29:26) thl: abadger1999, -1
(10:29:27) abadger1999: -1
(10:29:29) jwb: -1
(10:29:32) c4chris__: abadger1999, -1
(10:29:33) dgilmore: -1
(10:29:56) BobJensen is now known as BobJensen-Away
(10:29:57) ***rdieter abstains (for now): 0
(10:30:04) jwb: i think it's silly to differ now given that we're supposedly merging with Core anyway
(10:30:10) thl: jwb, agreed
(10:30:17) bpepple: jwb: agreed.
(10:30:41) rdieter: jwb: good point, count me as -1 then.
(10:30:46) dgilmore: i count 6 negative.  i abstinance  thats enough to have it knocked back  right?
(10:30:51) thl: Then we wait for the decision from core for now
(10:30:53) rdieter: yup
(10:31:03) f13: thl: core already made the decision
(10:31:10) tibbs: Core is a definite no.
(10:31:12) warren: -1
(10:31:17) dgilmore: f13: well  i guess we need to shout from the roof  dont do it
(10:31:18) thl: k, so, then there is no need to discuss this further afaics
(10:31:31) rdieter: stick a fork in it
(10:31:44) thl: k, anything else from the Packaging Committee?
(10:32:00) rdieter: that's it.
(10:32:12) thl: k, so let's move on
(10:32:25) thl has changed the topic to: FESCo meeting in progress --  Sponsorship nominations
(10:32:30) thl: any new nominations?
(10:33:01) dgilmore: none from me
(10:33:31) tibbs: I suppose we should consider Mamory Tasaka,
(10:33:41) tibbs: but I have not looked over his 34 reviews yet.
(10:33:47) nirik: BTW, for sponsors looking for people to sponsor I put together a list last week: http://www.scrye.com/~kevin/fedora-extras/sponsors-report-2006-10-14
(10:33:56) tibbs: Sorry, Mamoru Tasaka.
(10:34:16) bpepple: tibbs: I think he reviewed a couple of my packages, and he did a good job.  Is he interested?
(10:34:36) tibbs: I haven't discussed it with him.
(10:34:56) tibbs: I just noticed that he is the non-sponsor reviewer with the largest number of completed reviews.
(10:35:02) thl: tibbs, please ask him, and if he agrees send a RFC to cvsextras-sponsors please
(10:35:10) abadger1999: nirik: Nice list.
(10:35:23) tibbs: We really need to re-consider Paul Johnson as well.
(10:35:29) volp [n=volp]  entered the room.
(10:36:03) nirik: I think some of the folks on there with multiple packages should be looked at by sponsors...
(10:36:18) nirik: the folks with only one submission and no bugzilla activity will probibly sit there for a while.
(10:36:27) thl: nirik, can that list be integrated in c4chris__'s reports somehow?
(10:36:44) thl: tibbs, well, propose him on the list, too
(10:36:56) thl: I'll ask cwickert it he's interested
(10:37:10) nirik: possibly. I just generated it by hand... if c4chris__ can figure a way to automate it, that would be great
(10:37:32) thl: k, so let's move on
(10:37:52) c4chris__: nirik, I'll give it a try
(10:38:02) thl has changed the topic to: FESCo meeting in progress -- approve kmod's
(10:38:06) thl:  rt2x00-kmod is on the list
(10:38:18) jwb: hm, i missed that one
(10:38:24) thl: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=202528
(10:38:50) thl: hmmm
(10:38:58) thl: I think i left a comment in the report
(10:39:04) thl: but seem it never landed there
(10:39:06) thl: forget about this
(10:39:13) thl: we'll get back to it next week
(10:39:20) thl: doesn't make to much sense without it
(10:39:43) thl has changed the topic to: FESCo meeting in progress -- misc
(10:40:01) f13: thl: as an 'outsider' I have a topic.
(10:40:19) thl: f13, wait a moment please
(10:40:31) thl: first: clement, -- https://www.redhat.com/archives/fedora-packaging/2006-October/msg00132.html
(10:40:48) tibbs: This absolutely must get fixed ASAP.
(10:40:49) thl: do we agree that we remove it as quickly as possible?
(10:40:53) rdieter: +1
(10:41:00) bpepple: thl: +1
(10:41:05) tibbs: +1.
(10:41:08) scop: +1
(10:41:11) jwb: +1
(10:41:15) tibbs: Delete the package or just fix it to not install the repo?
(10:41:23) thl: delete it now
(10:41:25) thl: fix later
(10:41:33) dgilmore: thl: i say we just remove the repo config file
(10:41:39) rdieter: delete first, then fix (later)
(10:41:42) cwickert [n=chris]  entered the room.
(10:41:47) dgilmore: thl: just fix it
(10:42:02) jwb: dgilmore, it needs a fix, rebuild, and push to be effective
(10:42:09) f13: thl: haha, thats what I was going ot bring up
(10:42:13) thl: dgilmore, the maintainer should fix it
(10:42:20) rdieter: thl: +1
(10:42:25) dgilmore: jwb: yeah  a it will take the same time to propagate as a removal
(10:42:26) scop: I can take care of the push if something happens quickly
(10:42:27) thl: and someone really should tell him that that was quite bad bad
(10:42:43) rdieter: (and tell the reviewer)
(10:42:48) thl: rdieter, agreed
(10:42:52) thl: and fedora-extras-list
(10:43:02) tibbs: It's just one line from the specfile.
(10:43:06) thl: can anybody handle all the steps please?
(10:43:09) thl: scop ?
(10:43:19) nirik: perhaps rpmlint could add a check for repo files and tag it as a E ?
(10:43:19) jwb: i can fix it
(10:43:28) bpepple: nirik: +1
(10:43:40) thl: jwb, k, then fix it
(10:43:41) dgilmore: jwb: if you dont want to i will
(10:43:46) jwb: already working on it
(10:43:49) dgilmore: :)
(10:43:53) tibbs: Seems everyone wants to fix it.
(10:43:59) tibbs: I already had vi open.
(10:44:03) thl: :)
(10:44:07) jwb: tibbs, you're ahead of me.  go ahead
(10:44:08) thl: well, settled then
(10:44:10) thl: f13 ?
(10:44:33) jwb: tibbs, if i don't hear from you in 10 minutes that it's done, i'll proceed ;)
(10:44:35) tibbs: Wow, no changelog for the last change, either.
(10:45:02) f13: thl: I was going to ask if this should be an Extras acceptable practice, or if it should go into Packaging guidelines.  Becuase if it's a packaging guideline, then fedora-release doesn't pass muster (:
(10:45:03) dgilmore: sounds like some maintainer education is needed
(10:45:11) thl: btw who tells the packager and the list about it? tibbs, jwb, dgilmore ?
(10:45:24) rdieter: fedora-release is a reasonable exception, clearly. (:
(10:45:25) bpepple: f13: It should go into the Packaging Guidelines.
(10:45:33) dgilmore: thl: ill write something to the list and mainatiner
(10:45:39) thl: dgilmore, thx
(10:46:17) thl: Packaging Guidelines +1 -- fedora-release is a special exception
(10:46:23) dgilmore: +1
(10:46:25) tibbs: Running test builds now; I'll check in and build in a few.
(10:46:27) c4chris__: +1
(10:46:29) rdieter: I almost think this falls under the general category of "don't do anything stoooopid".
(10:46:30) abadger1999: +1
(10:46:30) bpepple: thl: +1
(10:46:40) dgilmore: rdieter: pretty much
(10:46:49) thl: rdieter, agree; maybe we should have a page "*this* is stupid"
(10:46:51) abadger1999: rdieter: heh.  One would think ;-)
(10:46:53) cweyl: rdieter: that's always been my favourite rule :)
(10:46:56) volp left the room (quit: Read error: 60 (Operation timed out)).
(10:47:14) dgilmore: but  stupidity got through  the cracks  so we need to say dont do this in addition to dont be stupid
(10:47:16) f13: Packaging Wall of Shame
(10:47:28) rdieter: having a "this is stupid" page might not be a bad idea.
(10:47:28) f13: dgilmore: it was disabled when it went through review
(10:47:38) f13: got enabled post review.  Sneaky sneaky
(10:48:08) thl: k, so let's move on
(10:48:14) c4chris__: hmm, more QA stuff to write... ;-)
(10:48:16) dgilmore: f13: :(  it probably should have had a rm -f  in the spec
(10:48:20) thl: "kmod support in the buildsys" is in the misc list
(10:48:35) thl: i'll handle that (I assume no one else is interesed)
(10:48:47) dgilmore: thl: im not sure what the current status of kmods in the buildsys are
(10:48:49) thl: so it's more a reminder that we need to get the kmod building automated
(10:49:13) thl: nothing automated, possible with hardcoded kversion and kvariant
(10:49:29) thl: but that needs updateing for each kernel update :/
(10:49:52) thl: "integrate kmodtool changes from kerneldrivers.org" and "get kmodtool included in core" are also on my plate
(10:49:58) thl: I'm working on it already
(10:50:15) dgilmore: thl: ok  well if anything is needed in plague let me know
(10:50:20) thl: the consensus on a private dicsussion about "integrate kmodtool changes from kerneldrivers.org"
(10:50:28) thl: was to integrate changes into cvs
(10:50:30) dgilmore: I have a few additions to plague im working on
(10:50:50) thl: normally, and only discuss the big changes in FESCo and the PAckaging Committe
(10:50:57) thl: it that okay for everyone?
(10:51:06) c4chris__: thl, +1
(10:51:13) rdieter: thl: +1
(10:51:15) bpepple: thl: +1
(10:51:17) scop: sure
(10:51:31) thl: k
(10:51:50) thl has changed the topic to: FESCo meeting in progress --  Maintainer Responsibility Policy
(10:51:57) thl: sorry, I had no time for it
(10:52:12) thl: I'll try to driver this forward soon
(10:52:26) thl has changed the topic to: FESCo meeting in progress --  what next?
(10:52:36) thl: we still have some topics on the list:
(10:52:41) thl:  Comaintainership
(10:52:47) thl:  Package Database
(10:52:53) thl:  Use comps.xml properly
(10:52:59) thl:  Feature support in Extras
(10:53:07) thl: does anyone want to discuss one of those?
(10:53:07) abadger1999: I need to get a package branched for infrastructure
(10:53:17) abadger1999: pygpgme
(10:53:38) abadger1999: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=210217
(10:53:39) rdieter: a separate branch?  why?
(10:53:51) tibbs: Branched to FC3?
(10:53:51) scop: branched for an old distro version?
(10:53:53) thl: yeah, why?
(10:53:55) abadger1999: tibbs: yes
(10:54:21) abadger1999: I wrote a script to handle encrypting passwords for all the admins with thir gpg keys
(10:54:23) dgilmore: abadger1999: what are we going to use it for?
(10:54:26) tibbs: I'm pretty happy to allow legacy branches for anything infrastructure needs.
(10:54:31) thl: abadger1999, could you next time please add it before the meeting on http://www.fedoraproject.org/wiki/Extras/Schedule/BranchRequestsForOldDists ?
(10:54:34) abadger1999: But it uses pygpgme to do the heavy lifting.
(10:54:41) thl: then we are aware of it and can prepare
(10:54:54) abadger1999: thl: Can do.
(10:55:00) dgilmore: abadger1999: whats it currently branched for?
(10:55:05) thl: otherwise i agree with tibbs: I'm pretty happy to allow legacy branches for anything infrastructure needs.
(10:55:08) thl: so +1
(10:55:21) c4chris__: +1
(10:55:25) ***nirik wonders what part of the infrastructure is still on FC3...
(10:55:35) ***scop is not entirely happy to hear infrastructure runs/depends on that old distros... ;)
(10:55:40) dgilmore: nirik: we have RHEL4 servers
(10:55:44) abadger1999: It's currently just in devel.
(10:55:56) rdieter: that's what EL-4 branches are for. :)
(10:55:58) abadger1999: I figured I'd wait on my branch requests until I got approval here.
(10:56:08) dgilmore: rdieter: but they dont exist yet
(10:56:08) rdieter: +1 for FC-3 branch
(10:56:48) scop: +1 if you'll create everything in between FC-3 and devel, too
(10:56:48) bpepple: +1 for FC3 branch
(10:56:58) tibbs: +1
(10:57:14) thl: sorry, I suddenly got guests
(10:57:15) rdieter: scop: why bother with FC-4?
(10:57:20) abadger1999: scop: Yep.
(10:57:22) scop: upgrade paths?
(10:57:23) thl: jwb, can you handle the rest of the meeting?
(10:57:28) abadger1999: rdieter: because of upgrades.
(10:57:40) dgilmore: rdieter: for continuitity
(10:57:41) rdieter: scop:  upgrades between to legacy releases?  ick. ok, I guess.
(10:57:48) rdieter: s/to/two/
(10:58:09) dgilmore: the last of our FC-3  servers went to FC-5  when i upgraded the builders
(10:58:25) scop: rdieter, consider user installing the package on FC-3, then upgrading to FC-4, then FC-5, and leaving it at that because there's something in FC-6 she doesn't like
(10:58:52) jwb: thl, no actually.  more real life meetings now.  tibbs?
(10:58:55) dgilmore: i do say if we  do it we do it for all branches
(10:59:12) dgilmore: other option is to make a infratructure cvs tree
(10:59:20) dgilmore: and pull in what we need
(10:59:21) tibbs: What is left to cover?  I think I have my keyboard mostly working now.
(10:59:24) rdieter: that's even worse.
(10:59:41) c4chris__: rdieter, agreed
(11:00:14) scop: what "that" is even worse?
(11:00:31) rdieter: worse = "separate infrastructure cvs tree"
(11:00:39) scop: ok, yep
(11:00:48) jima: i agree -- i'd rather have to maintain crap for fc3.
(11:01:00) tibbs: Yes, I think that's a terrible idea.  Obviously for instrastructure we'd like to have RHEL branches, but that's otherwise held up.
(11:01:04) nirik: well, the binary is going to be locally built from the FC-3 branch? so why not just build it from a devel branch and tweak it as needed?
(11:01:36) jima: nirik: possibly less work involved.
(11:01:37) nirik: either way it's going to be a locally built package for RHEL, right?
(11:02:14) tibbs: Do the infrastructure folks uses the built FC3 packages as-is?
(11:02:45) tibbs: If so, this makes sense as long as the package maintainer is actually willing to maintain the FC3 branch.
(11:03:16) ***scop sees clement finished building, will go kick a push now
(11:03:22) dgilmore: tibbs: im  not 100% sure how we use them
(11:03:46) ***dgilmore only really deals with builders and there all fc5
(11:04:03) abadger1999: Hmm.. Good question.  Because infrastructure has been requesting FC-3 branches I assumed we use the packages as is.
(11:04:24) abadger1999: I'd have to ask mmcgrath or warren to be sure, though.
(11:04:33) tibbs: OK.
(11:04:41) tibbs: Well, anyone around to talk about the package database?
(11:04:57) jima: scop: wtg on the expedited fix.
(11:04:58) tibbs: I'm really curious to see how it's coming along.
(11:05:12) abadger1999: Sure -- there's a skeleton up for infrastructure people to start working on.
(11:05:14) tibbs has changed the topic to: FESCo meeting in progress --  Package Database
(11:05:15) scop: jima, ?
(11:05:24) jima: scop: way to go
(11:05:34) scop: ah, thanks ;)
(11:05:36) volp [n=volp]  entered the room.
(11:05:42) abadger1999: I need to proxy that out to admin.fp.o so people outside infrastructure can access it.
(11:05:58) jima: scop: nice to see we can shift into high gear when people do insane things like that.
(11:06:07) scop: pushes take a looooong time though
(11:06:11) c4chris__: and we need to put some data in there for people to look at
(11:06:23) abadger1999: And then I'm working on importing data from owners.list and CVSROOT/modules
(11:06:42) tibbs: What's actually working at this point?  It sounds as if it's fairly well along.
(11:07:10) abadger1999: yes and no.
(11:07:19) abadger1999: Like I say it's a skeleton.
(11:07:31) abadger1999: So the pieces to support the packageDB are in place.
(11:07:43) delero left the room.
(11:07:45) abadger1999: But the data and the website to pull the database info have to be written
(11:08:27) tibbs: Sounds good in any case.  I think this will help things significantly when it starts getting hooked up.
(11:08:28) c4chris__: and some tables need to be adjusted to accept a bit more data
(11:08:39) abadger1999: Right.
(11:08:44) abadger1999: http://www.fedoraproject.org/wiki/Infrastructure/PackageDatabase/RoadMap
(11:09:11) abadger1999: Brain dumped some of my thoughts on where we're at and where we are going.
(11:09:32) tibbs: Cool.  Well, I guess proper co-maintainership hinges off of this.
(11:09:48) tibbs: What about comps.xml?
(11:10:16) ***scop needs to go in a few minutes
(11:10:29) tibbs: dgilmore: anything going on there?
(11:10:31) tibbs has changed the topic to: FESCo meeting in progress --  Use comps.xml properly
(11:10:34) c4chris__: no that much.
(11:10:43) c4chris__: I need to clean it up a bit
(11:11:00) c4chris__: and dgilmore needs to push it...
(11:11:01) dgilmore: tibbs: not yet  i need to sit down with jeremy   and we havent been able to yet
(11:11:11) f13: did the uncategorized thing get fixed?
(11:11:14) tibbs: Glue him to his chair?
(11:11:29) dgilmore: tibbs: i think they stapled him to it
(11:11:30) tibbs: Folks still seem a bit lost on where some packages should go.
(11:11:33) c4chris__: tibbs, in a week or so, maybe... :-)
(11:11:34) dgilmore: doesnt help
(11:12:06) tibbs: And we don't seem to have much policy on when to add new groups.
(11:12:48) tibbs: Extras and Core need to mesh pretty closely when it comes to comps, don't they?
(11:13:10) tibbs: Otherwise the install experience gets kind of crappy with lots of random groups.
(11:13:20) f13: yeah
(11:13:24) f13: they need to mesh
(11:13:37) f13: and most likely use existing categories, just add new groups if necessary or add to existing groups
(11:13:42) f13: always "optional"
(11:14:03) tibbs: Does core have written rules for adding comps that we could refer to?
(11:14:08) f13: although, one could argue that if it's an Extras only group that the group could be optional and things WITHIN the group could be "default" or "manditory"
(11:14:13) f13: tibbs: we don't.
(11:14:29) f13: tibbs: tribal knowledge thats been passed down to me, and I usually run changes through Bill Nottingham and Jeremy Katz
(11:14:58) tibbs: I've seen Extras contributors concerned about the impact of where they put their package and how it might interfere with installs or confuse users.
(11:15:18) tibbs: Especially when it comes to things like command-line applications or servers.
(11:15:39) c4chris__: tibbs, I know.  Not clear to me either...
(11:15:51) tibbs: So it might be good to get some basic guidelines written down at some point.
(11:16:03) tibbs: I expect that the package DB will make some of this easier.
(11:16:19) tibbs: As I understand things, folks won't have to go editing comps.xml.in any longer.
(11:16:23) c4chris__: tibbs, I'm kinda hoping that when FC7 is out the dorr, some Core people will have time to discuss this
(11:16:38) tibbs: I hope you mean FC6.
(11:16:50) c4chris__: tibbs, oops, yes FC6
(11:17:17) tibbs: Anyone have anything else to discuss?  We've gone off the end of the list.
(11:17:26) tibbs has changed the topic to: FESCo meeting in progress --  finishing up
(11:17:27) ***dgilmore has nothing
(11:17:37) drpixel [n=drpixel]  entered the room.
(11:17:45) ***tibbs will close the meeting in 60...
(11:17:45) f13: tibbs: hrm.
(11:17:52) tibbs: hmm?
(11:18:01) f13: tibbs: unless the package DB has some really finegrained info on packages, comps may still be necessary
(11:18:09) f13: and I don't think we want that kind of info in a db
(11:18:26) abadger1999: f13: What's needed?
(11:18:26) ***f13 is thinking to the _future_ where core/extras all play in the same pool
(11:18:41) tibbs: I thought the idea was that the DB would have a field for category/group
(11:18:51) tibbs: And you could generate comps.xml from that.
(11:18:59) ***nirik notes that FE-NEW is down around 130... which is the lowest its been in a while. Now's a great chance to push it down further. ;)
(11:19:05) tibbs: Knowing the existing groups could allow folks to just pick from a list.
(11:19:10) f13: abadger1999: 'what groups does this package go in', 'is it default/manditory/optionl in that group', 'in this group is it dependant on another package having already been selected'
(11:19:23) jima: tibbs: that's what i was assuming, too.
(11:19:35) jima: like, have a drop-down menu or whatnot.
(11:19:53) f13: I could see a web interface to the Extras comps.in file
(11:20:00) f13: which has pretty drop downs and checkboxen
(11:20:32) dgilmore: f13: that would be cool
(11:20:41) c4chris__: f13, sure, but why not attach this to the package DB?
(11:20:53) tibbs: I, perhaps naively, assumed that this would just be part of the package DB.
(11:20:55) jima: all i'm uncertain about is why that would need to be segregated from the package db.
(11:21:04) jima: c4chris__, tibbs: +1
(11:21:18) abadger1999: f13: The first two are pretty simple to add the dependencies may or may not.  But I don't think it's out of reach.
(11:21:21) dgilmore: f13: it probably should be part of the packagedb   some kind of comps info.
(11:21:37) abadger1999: s/add the/add. The/
(11:21:47) ***dgilmore  needs to go get lunch
(11:21:51) tibbs: In other words,the packagedb stores all available info about packages and can generate or replace things like owners.list, comps, CVS ACLs, etc.
(11:22:02) f13: dunno, depends on how utterly huge and unweildy you want the DB to be
(11:22:12) f13: we're fighting that with brew right now.
(11:22:25) jima: i imagine it'd be fairly trivial to add, as compared to designing a completely different system for maintaining comps.xml
(11:22:27) f13: we didn't even want to think about doing comps info in our packagedb
(11:22:59) tibbs: It's sad to see two packagedbs.
(11:23:05) f13: for us, a package may be inherited into any number of collections or products, where the comps info may be completely invalid
(11:23:55) tibbs: Anything else to cover?
(11:24:15) tibbs: \me will close in 60
(11:24:24) tibbs: erm...
(11:24:57) tibbs: ...30
(11:25:20) tibbs: ...10
(11:25:31) tibbs: EOM.  Thanks, folks.
Retrieved from "https://fedoraproject.org/w/index.php?title=Extras/SteeringCommittee/Meeting-20061019&oldid=19185"