2006 December 7 FESCo Meeting

Members

Present

thl
tibbs
bpepple
rdieter
dgilmore
jeremy
abadger1999
spot
warren
scop
awjb
Absent

ch4chris
jwb
Summary

EPEL

dgilmore is getting sync to master mirror setup. Looking into using
lmacken's update system for that.
Need signing keys setup.
Need someplace to announce epel package builds.
distag discussion: should it be epel or el?
RHEL uses el. One reason to use epel is so you can tell from the disttag
whether the package in question came from RHEL or EPEL.
disttag's traditional meaning has been "what is this built for" rather than
"what project built this".
disttag is not as good an indicator of where a package comes from as
information available from rpm querying the header info. disttags are not required, CentOS uses .el, etc.
We're going to stick with .el[VERNUM] for now.
RHEL 5 is split into a RHEL5-server and RHEL5-client. We may need to have
two download repos to account for the split.
Opening Core

Red Hat management is generally for the idea. Just need to figure out the
details.
We need to plan the schedule for the next release of "Core" so we FPB to
set the schedule and determine what we have to o by when to get this integrated.
mass-review of Core packages still needs to be discussed on f-e-list.
The Core + Extras merge is going to happen for FC7.
Broken deps and EVR problems

Kudos to nirik for having stepped up and fixed a bunch of these issues.
tibbs proposed that we don't push packages that violate EVR ordering between
released branches.
lmacken's new update system will check EVR before pushing.
Extras QA SIG might be a good place to work on broken deps and EVR issues.
Until mock/plague integrates kmod support keping kmods off the deps/EVR
reports is nearly impossible.
dkms as being experimented with @ freshrpms suggested as a sane way to do
kernel modules except that it requires the end-user to have development tools installed.
kmods haven't really been given a good test until the mock/plague
integration has been tried.
Packaging Committee Report

FESCo approving Conflicts
No disapproval for disallowing conflicts but there was discussion of
whether FESCo wants to approve conflicts.
Leaving to reviewer was generally frowned upon.
Having a list of allowed situations was seen as a possible compromise --
to be discussed withthe Packaging Committee.
Kmod Approval

gspca https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209112
spot said he looked into the gspca module and that the module code is good
and the author wants it upstream but the v4l camp is not agreed upon certain things which makes getting the module upstream not likely until some consensus is reached.
Maintainer Responsibility

Waiting on Legacy folks to decide whether to shutdown the builders.
Free Discussion

Renaming packages
When a package is renamed, the package owner is allowed to import the
renamed package as a new module, mark the old module as a dead.package and request branches. Referring to the old package and the fact that this is a rename helps people know what's going on in regards to the branches.
Part of this policy is listed here:
http://www.fedoraproject.org/wiki/Extras/PackageEndOfLife and we can link to that as a reference.
awjb will document this.
Log

(10:00:08 AM) thl has changed the topic to: FESCo meeting -- Meeting rules at [WWW]  http://www.fedoraproject.org/wiki/Extras/Schedule/MeetingGuidelines -- Init process
(10:00:12 AM) thl: FESCo meeting ping -- abadger1999, awjb, bpepple, c4chris, dgilmore, jeremy, jwb, rdieter, spot, scop, thl, tibbs, warren
(10:00:15 AM) thl: Hi everybody; Who's around?
(10:00:20 AM) tibbs: I'm here.
(10:00:20 AM) ***bpepple is here.
(10:00:20 AM) ***rdieter is here.
(10:00:22 AM) ***dgilmore is here
(10:00:24 AM) ***jeremy is here
(10:00:25 AM) ***abadger1999 is here
(10:00:32 AM) ***spot is here
(10:00:38 AM) ***nirik is in the rabble seats with his coffee.
(10:00:42 AM) ***warren here
(10:00:44 AM) scop: pong
(10:00:53 AM) thl has changed the topic to: FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- status update
(10:01:17 AM) dgilmore: thl: getting the sync to master mirror setup
(10:01:32 AM) dgilmore: thl: looking at using lmacken's  update system
(10:01:33 AM) ***awjb is here now as well
(10:01:48 AM) dgilmore: thl: need to setup keys for signing packages
(10:01:53 AM) warren: has everyone seen lmacken's update system wiki page and screenshots?
(10:01:55 AM) warren: pretty sweet
(10:02:11 AM) thl: warren, agreed
(10:02:17 AM) ***rdieter hasn't
(10:02:33 AM) dgilmore: I think we will need to ask for a list epel-announce
(10:02:33 AM) ***bpepple hasn't either.
(10:02:44 AM) abadger1999: warren: :Beautious :-)
(10:02:53 AM) ***mmcgrath is here
(10:03:15 AM) warren: epel-announce-list?
(10:03:23 AM) warren: where does epel devel discussion happen?
(10:03:24 AM) thl: dgilmore, yeah, we might need such a list over time
(10:03:26 AM) dgilmore: warren: that would be ok
(10:03:27 AM) mmcgrath: Could we just use the fedora announce list?  Do we need an epel announce list?
(10:03:30 AM) thl: warren, on extras-list still
(10:03:40 AM) dgilmore: http://fedoraproject.org/wiki/Infrastructure/UpdatesSystem
(10:03:43 AM) rdieter: thl: +1
(10:03:45 AM) thl: the plan is to have a seperate list over time
(10:03:52 AM) ***lmacken is kind of here, but in class :)
(10:03:54 AM) thl: but for now f-e-l is good enough
(10:04:13 AM) rdieter: dgilmore: thanks, nice.
(10:04:27 AM) thl has changed the topic to: FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- disttag confusion
(10:04:34 AM) thl: dgilmore, so do we use el everywhere?
(10:04:38 AM) thl: or somewhere epel?
(10:04:38 AM) dgilmore: I would like to have a epel-accounce-list from the start  as its really not relevant to Fedora stuff and it will mean less noise for EPEL
(10:04:40 AM) ***wwoods lurking in background
(10:04:50 AM) thl has changed the topic to: FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- mailinglist
(10:04:54 AM) dgilmore: well right now rhel, centos  use el
(10:05:08 AM) mmcgrath: But what would we announce "Its here" and then a few months later "EL5 is ready"?
(10:05:22 AM) abadger1999: WOuld we do package announcements there?
(10:05:29 AM) thl: we really should get the repo into shape before we annouce it for real
(10:05:31 AM) dgilmore: if we use lmackens update system  each package will have an announcement email
(10:05:43 AM) warren: package announcements on fedora-announce-list from the beginning was a bad idea.
(10:05:43 AM) thl: there are still a lot of things and rules to be worked out
(10:06:16 AM) dgilmore: i would like somewhere to email package announcements to
(10:06:30 AM) thl: dgilmore, so proposed name for the list?
(10:06:40 AM) thl: enterprise-extras-annouce?
(10:06:46 AM) mmcgrath: well this could be part of a larger discussion.
(10:06:48 AM) dgilmore: either epel-announce-list or epel-package-list
(10:06:55 AM) mmcgrath: For example, after the merge, what happens to the fedora-extras list?
(10:07:02 AM) dgilmore: thl: that would be ok also
(10:07:20 AM) mmcgrath: sorry, thats off topic.  Ignore me.
(10:07:22 AM) thl: mmcgrath, we IMHO need a genereal mailinglist-cleanup then
(10:07:43 AM) dgilmore: thl: we do and i really dont wantto add another list
(10:07:43 AM) mmcgrath: My concern is a seperate mailing list for function vs 'team'.
(10:08:27 AM) dgilmore: lets ignore the list for now.  We will need to decide at some point where to send package announcements
(10:08:36 AM) mmcgrath: send 'em to extras.
(10:08:43 AM) rdieter: dgilmore: +1
(10:08:45 AM) dgilmore: we still have a bit of work to get everything done
(10:08:46 AM) thl: mmcgrath, +1 (at least for now)
(10:08:46 AM) mmcgrath: even the fedora cvs repo stuff gets sent there.
(10:08:52 AM) warren: fedora-extras-list was meant to be an Extras specific fedora-devel-list.  The focus has helped us to keep lots of CRAP off of fedora-extras-list.  I'd hate to lose that focus.
(10:09:08 AM) mmcgrath: its already lost that focus though.  Darn near everything goes there.
(10:09:24 AM) warren: mmcgrath, it is development focus, unlike fedora-devel-list...
(10:09:34 AM) warren: mmcgrath, just the volume has grown large
(10:09:46 AM) thl: warren, and there is confusiton with fedora-maintainers
(10:10:01 AM) warren: fedora-maintainers was meant to be a fedora-devel-list, minus the random people posting off-topic shit.
(10:10:01 AM) thl: anyway, we're losing focus currenly
(10:10:14 AM) XulChris: personally i just send to fedora-extras in most cases because more people subscribe to that list than any other
(10:10:19 AM) thl: dgilmore, maybe just work out a proposal for a list and post it
(10:10:20 AM) warren: Yes, we need to figure out what to do with the mailing lists, but we don't need to do it today.  Let's move on.
(10:10:24 AM) thl: then we can decide in a later meeting
(10:10:26 AM) dgilmore: thl: lets look at disttags  this can be decided in the next few weeks
(10:10:34 AM) thl has changed the topic to: FESCO-Meeting -- EPEL -- mmcgrath, dgilmore -- disttag confusion
(10:10:42 AM) thl: so, do we us .el or .epel ?
(10:10:46 AM) dgilmore: rhel and CentOS use .el
(10:10:58 AM) ***thl votes for .el
(10:11:01 AM) rdieter: where did the suggestion to use .epel come from?
(10:11:05 AM) dgilmore: if we use .epel  it will be very clear what are our pcakages
(10:11:10 AM) thl: rdieter, -ENOIDEA
(10:11:12 AM) warren: Please do not use .el for EPEL packages, especially when it is likely they might overlap with RHEL packages in some cases.
(10:11:15 AM) mmcgrath: I don't care what we use but I know others do.
(10:11:16 AM) dgilmore: rdieter: warren
(10:11:35 AM) rdieter: warren: overlap?  they shouldn't.
(10:11:39 AM) spot: EPEL packages should never ever overlap with RHEL
(10:11:39 AM) mmcgrath: what problems does a tag overlap cause?
(10:11:44 AM) warren: rdieter, the Client/Server problem
(10:12:00 AM) thl: well, the next topic is this in any case, so let's get over it:
(10:12:01 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:04 AM) spot: warren: they're using a merged tree
(10:12:15 AM) warren: In any case, .el and .epel creates a clear differentiation.
(10:12:24 AM) warren: from a support perspective that is a really good thing.
(10:12:29 AM) thl: I'd say we should not ship packages in epel that are part of either Server or Client
(10:12:33 AM) dgilmore: i vote that we do not push anything in server that is in client
(10:12:36 AM) warren: spot, buildroot is merged yes, but what about users?
(10:12:43 AM) rdieter: I disagree.  dist tag is meant to identify what the pkg is built *for* not the origin of the pkg.
(10:12:50 AM) thl: rdieter, +1
(10:12:56 AM) bpepple: rdieter: agreed.
(10:12:57 AM) spot: +1
(10:13:00 AM) XulChris: im not fesco but i agree with rdieter
(10:13:07 AM) warren: thl, that is overly simplistic
(10:13:23 AM) warren: thl, that means two different repos for RHEL5, which is different from the merged EPEL for CentOS5
(10:13:33 AM) nbecker [n=nbecker]  entered the room.
(10:13:41 AM) rdieter: way, way back when, some repos used something like: Release: %{foo}%{?dist}%{?repo}
(10:13:53 AM) craigt [n=cthomas]  entered the room.
(10:13:56 AM) rdieter: icky.
(10:14:02 AM) thl: warren, why would we need two repos? to satisfy deps?
(10:14:42 AM) dgilmore: thl: yes
(10:14:51 AM) rdieter: -ENOTOURPROBLEM.
(10:15:14 AM) rdieter: if a dep is missing for RHEL5/server, too bad, you can't install it.
(10:15:15 AM) dgilmore: i was asked how big our repo will be to pre warn mirrors
(10:15:21 AM) mmcgrath: Do we know there will be an issue or are we assuming?
(10:15:29 AM) dgilmore: and i said approx 22G per release
(10:15:41 AM) dgilmore: which is what devel currently is
(10:15:55 AM) warren: thl, the client/server split is going to be confusing as hell to EPEL5.
(10:15:58 AM) mmcgrath: And thats a good guess, especailly over the next year or two I'd think we would stay under that.
(10:16:06 AM) thl: dgilmore, I don#t think we'll grow that big soon, but it's probably wise to put a big number out
(10:16:14 AM) warren: satisfying deps with EPEL5 rebuilds that overlap with RHEL5 packages is one way to solve that problem.
(10:16:21 AM) dgilmore: thl: that was my thought
(10:16:24 AM) warren: Can you think of another way to solve it without having two separate repos?
(10:16:42 AM) warren: But a RHEL5 rebuild should NOT have the same disttag
(10:16:46 AM) thl: warren, but then we might replace packages from the client accidentally
(10:16:50 AM) spot: short of EL5 being more reasonably packaged? :/
(10:16:56 AM) dgilmore: warren: one repo  and make sure our packages dont get chossen if available elsewhere
(10:17:20 AM) warren: dgilmore, .epel5 vs .el5 would satisfy that, .el5 would win.
(10:17:39 AM) thl: I'd like to have one repo, too, but I'm not sure if that is doable
(10:17:47 AM) mmcgrath: +1 for one repo.
(10:17:56 AM) XulChris: one repo to rule them all
(10:17:58 AM) mmcgrath: I say we go with 1 repo until there's a problem.
(10:18:08 AM) mmcgrath: Then examine that problem and find a reasonable solution.
(10:18:10 AM) ***spot is somewhat annoyed at the continued "don't taint core/rhel with extras" mentality
(10:18:20 AM) dgilmore: i would prefer 1 repo  otherwise our disk useage will blow up or we need to do lots of hardlinking
(10:18:30 AM) thl: let's set the goal "one repo" for now and see if it works out
(10:18:36 AM) thl: and get back to it later if we have to
(10:18:43 AM) mmcgrath: spot: +1.  We have to trust our users at least a little bit to do the right thing.
(10:18:50 AM) thl: and don't ship packages in epel that are part of either Server or Client for now
(10:18:59 AM) warren: thl, what does that mean?
(10:19:11 AM) warren: I mean, the plan as-is works fine for EPEL4.
(10:19:12 AM) thl: warren, define "that" please
(10:19:22 AM) warren: "<thl> and don't ship packages in epel that are part of either Server or Client for now"
(10:19:28 AM) f13: thl: but what happens when you want to package something for EPEL and they depend on a package on Client, which isn't avail in Server?
(10:19:29 AM) spot: warren: it means we nuke things out of the EPEL tree if they end up in RHEL5
(10:19:32 AM) warren: This makes no sense when talking about RHEL5.
(10:19:35 AM) abadger1999: warren: Are we guaranteeing that there won't be foo-1.0-1.el5 and foo-1.0-2.epel5 ?
(10:19:39 AM) rdieter: warren: no overlap,period.
(10:19:50 AM) warren: Hmm...
(10:19:51 AM) rdieter: f13: The Server users are SOL.
(10:19:56 AM) mmcgrath: but the dist tag doesn't make a difference.
(10:20:04 AM) f13: rdieter: thats cute.
(10:20:08 AM) mmcgrath: especially if the releases are increased so that someone is upgrading from one to the others.
(10:20:08 AM) thl: mmcgrath, exactly
(10:20:18 AM) warren: I suspect "no overlap period" may simplify things, but may also bite us in the ass.
(10:20:21 AM) rdieter: f13: not cute, reality.
(10:20:28 AM) f13: I'd go for 2 repos with this mentality though.
(10:20:34 AM) dgilmore: spot, warren, f13:  is it possible to geta  package list for RHEL5  so we can see what extras packages are already there
(10:20:42 AM) warren: The .epel4 and .epel5 tag plus "no overlap period" policy for now would protect us.
(10:20:46 AM) f13: that way Server folks get a nicer "no package found" rather than a hellish string of 'no package to meet dep foo"
(10:20:53 AM) warren: dgilmore, RHEL5 beta2 is downloadable
(10:20:55 AM) thl: f13, agreed, I more and more think we really might need two repos...
(10:21:05 AM) f13: warren: I'm much more in favor of .el vs .epel
(10:21:13 AM) mmcgrath: are we worried that two packages will have the exact same name?  Or that someone will accidently upgrade from an EPEl package to a RHEL package and vise versa?
(10:21:20 AM) warren: thl, which in effect would be different from EPEL for CentOS.
(10:21:23 AM) thl: warren, how would a different disttag protect us?
(10:21:23 AM) warren: thus THREE repos
(10:21:45 AM) spot: warren: it is possible CentOS 5 might do the same splitting
(10:21:46 AM) f13: warren: I'm not entirely convinced that CentOS can make use of this repo if we split things out
(10:21:54 AM) f13: oh there is that.
(10:21:59 AM) warren: thl, flexibility when we hit the likely case where we realize "oh shit, no overlap isn't working"
(10:21:59 AM) thl: -ELifeSucks
(10:22:23 AM) abadger1999: Are we back to fedora.us 0.[RELNUMBER]  ?
(10:22:27 AM) thl: warren, but how do you want to make sure packages from "Core" don#t get relaced?
(10:22:31 AM) warren: abadger1999, who suggested that?
(10:22:32 AM) spot: there are more packages in FE now than in FC, and none of them overlap
(10:22:40 AM) spot: i think we can deal with the "overlap" case.
(10:22:48 AM) warren: spot, that was easy because there is *ONE* core.
(10:22:48 AM) thl: s/relaced/replaced?/
(10:23:01 AM) warren: RHEL5 makes this complicated because...
(10:23:04 AM) spot: and there will be two EL5s
(10:23:05 AM) abadger1999: Just by reading the "how do we make sure RHEL packages update EPEL packages"
(10:23:11 AM) abadger1999: And looking for a solution.
(10:23:17 AM) warren: RHEL5 buildroot -> two products -> EPEL buildroot -> two products
(10:23:42 AM) thl: well, we are running a bit out of time
(10:23:56 AM) warren: What are the actual drawbacks of using the .epel disttag?
(10:23:58 AM) warren: I don't see any.
(10:23:59 AM) thl: can somebody but some thoughts into this issue and work out a solution until next week?
(10:24:03 AM) ***nirik wonders if someone could talk with centos and rhel5 people and see if there is any solution?
(10:24:07 AM) warren: Even if we don't overlap, .epel isn't a drawback.
(10:24:10 AM) spot: warren: namespace pollution? confusion?
(10:24:15 AM) f13: warren: what spot said
(10:24:21 AM) warren: how is it confusion?
(10:24:30 AM) warren: .epel in the package name could promote LESS confusion.
(10:24:32 AM) f13: we don't do .fe7 for Extras, why do it for Enterprise extras?
(10:24:41 AM) warren: "oh, that isn't RHEL, that is clearly EPEL"
(10:24:50 AM) f13: warren: boondoggle
(10:24:52 AM) warren: f13, think about GSS dealing with a huge installed package list
(10:25:09 AM) f13: gss needs better tools than the name of the package to figure that out
(10:25:24 AM) f13: you're continuing to use this example which is a ver very poor example.
(10:25:31 AM) warren: I disagree.
(10:25:32 AM) f13: package names are neither deterministic nor accurate
(10:25:40 AM) XulChris: why dont we just have a seperate dist tag for each maintainer, isnt that pretty much the same thing?
(10:25:47 AM) warren: How does deterministic fit here?
(10:25:53 AM) f13: rpm query information is far more informative
(10:25:55 AM) XulChris: or i know, a sepearte dist tag for each package
(10:26:01 AM) ***nirik notes that centos at least now uses .el, so just having .el in the name won't help there between if it's a rhel or a centos package.
(10:26:06 AM) ***XulChris is being facetious BTW
(10:26:09 AM) f13: warren: because something could come from epel and not have a dist tag at all
(10:26:17 AM) spot: f13: +1
(10:26:23 AM) warren: f13, example?
(10:26:29 AM) f13: warren: dist tags are not required
(10:26:38 AM) f13: there are many packages in Extras that don't use a dist tag
(10:26:48 AM) mmcgrath: Thats true, its not in the guidelines right now.
(10:26:54 AM) f13: nor should it be
(10:26:54 AM) mmcgrath: Its just considered "a good idea"
(10:27:02 AM) spot: mmcgrath: and never will be mandatory (over my dead body)
(10:27:04 AM) f13: a packagers convinience
(10:27:32 AM) warren: OK, so better tools needed?
(10:27:36 AM) spot: dist tag says the dist it is for, not the place it was build
(10:27:44 AM) warren: We could write a standardized tool that lists packages and where they are from.
(10:27:52 AM) f13: warren: not even that.  rpm -qi shows you the information you're really looking for
(10:27:53 AM) warren: that would be a useful thing for support.
(10:27:57 AM) f13: Build host, Packager, etc...
(10:28:00 AM) spot: now, if we're really worried about RHEL5Client being completely different from RHEL5Server
(10:28:10 AM) warren: f13, which is TMI and slow for support
(10:28:11 AM) spot: maybe we need to treat them as separate dists
(10:28:22 AM) ***rdieter shudders
(10:28:24 AM) f13: warren: anything else is non-deterministic
(10:28:34 AM) dgilmore: lets stick with .el<ver number>  and move on for now
(10:28:35 AM) f13: warren: if it doesn't come FROM the system's rpmdb, its worthless
(10:28:38 AM) spot: rdieter: dont like it either, but this is us dealing with RHAT braindead packaging
(10:28:39 AM) warren: f13, what do you mean by non-deterministic?
(10:28:49 AM) f13: warren: ANY 3rd party repo can name any package anything
(10:28:53 AM) thl: yeah, guys, really let's stop here now
(10:28:58 AM) f13: they could stomp on our released numbers if they wanted to
(10:28:59 AM) warren: f13, I'm not talking about disttag anymore.
(10:28:59 AM) thl: we can't use all the time for one topic
(10:29:03 AM) warren: f13, i'm talking about better tools.
(10:29:05 AM) ***spot stops
(10:29:08 AM) rdieter: spot has a point, if we agree rhel5 client/server really *are* different...
(10:29:09 AM) f13: the package name itself is NOT deterministic as to where it comes from.
(10:29:11 AM) thl: let' move on and get back to it next week
(10:29:19 AM) warren: f13, I"M NOT TALKING ABOUT DISTTAG
(10:29:20 AM) thl: and or even better: work that out on the lists
(10:29:24 AM) f13: warren: neither am I
(10:29:37 AM) ***thl will switch to a different topic in 10
(10:29:40 AM) warren: move on
(10:29:40 AM) f13: warren: the name-ver-rel with or without dist tags is not deterministic
(10:29:41 AM) ***thl will switch to a different topic in 5
(10:29:47 AM) thl has changed the topic to: FESCo meeting -- Opening Core - (warren, jeremy, rdieter) -- status update
(10:29:53 AM) thl: warren, jeremy, rdieter ?
(10:30:48 AM) warren: thl, well, management likes the general idea, figuring out specifics now.
(10:30:50 AM) thl: btw, I'm getting nervous slowly -- shouldn#t we plan a schedule for F{,C}7 slowly?
(10:31:11 AM) thl: normally the first beta should show up in January afaics
(10:31:18 AM) f13: thl: thtas on Max's plate to accomplish
(10:31:32 AM) thl: f13, okay, then I'll be quiet for now :)
(10:31:44 AM) warren: thl, that's a FPB question
(10:32:20 AM) thl: warren, tehre is still this on the schedule: "tasks: warren: start a discussion on f-e-l about plans how to realize the mass-review for packages moving from Core to Extras"
(10:32:48 AM) rdieter: I could be rememberring wrong, but I thought one of the conclusions from the Summit was that the first beta would happen after the upcoming FUDCon. ??
(10:33:00 AM) f13: rdieter: thats too late
(10:33:08 AM) daMaestro left the room (quit: "Leaving").
(10:33:08 AM) rdieter: ok, I'm wrong. (:
(10:33:30 AM) thl: warren, rdieter, jeremy, is there anything FESCo should do now besides waiting for management?
(10:33:37 AM) tibbs: Might we need to accept the possibility that this won't happen for FC7?
(10:33:45 AM) rdieter: thl: afaik, not much.
(10:34:09 AM) thl: rdieter, okay
(10:34:13 AM) thl: then let's move on
(10:34:15 AM) rdieter: tibbs: I think we continue on assumption that Core/Extras merge will happen, and proceed accordingly.
(10:34:38 AM) thl has changed the topic to: FESCO-Meeting -- Encourage co-maintainership -- c4chris
(10:34:39 AM) XulChris: if core packges need to be reviewed that should happen asap
(10:34:40 AM) tibbs: Yes, but the last thing we want to do is rush to cram everything in if we run short on time.
(10:34:41 AM) warren: rdieter, please be sure FPB begins planning the F 7 schedule.
(10:34:41 AM) jeremy: tibbs: I don't see how we _don't_ do it, to be honest.  we can't do a 7 cd release (and that's what we get to otherwise)
(10:34:48 AM) thl has changed the topic to: FESCo meeting -- Opening Core - (warren, jeremy, rdieter) -- status update
(10:35:00 AM) warren: thl, regarding mass review, we aren't quite ready yet.
(10:35:21 AM) thl: warren, okay, then I'll move it of the list for now
(10:35:29 AM) thl: anything else regarding opening core?
(10:35:41 AM) thl has changed the topic to: FESCO-Meeting -- Encourage co-maintainership -- c4chris
(10:35:51 AM) thl: c4chris seems not around; skipping
(10:35:59 AM) thl has changed the topic to: FESCo meeting -- MISC -- what to do with all those broken deps and upgrade paths
(10:36:00 AM) tibbs: I believe he's on vacation.
(10:36:12 AM) thl: nirik, thx for your work
(10:36:22 AM) thl: nirik, everyone else: do we need to do more?
(10:36:32 AM) nirik: I just prodded some folks... there are still a few non devel issues that are tougher...
(10:36:34 AM) tibbs: The easy busted deps were all done.
(10:36:42 AM) tibbs: Until postgres was updated, that is.
(10:36:58 AM) nirik: linphone is tricky, and flumotion is another (broken E-V-R)
(10:37:02 AM) tibbs: Kind of annoyed that there was no announcement to fedora-maintainers about that.
(10:37:09 AM) thl: well, I don#t care much about those deps that are broken less than 7 days
(10:37:23 AM) tibbs: linphone requires an update to a core package in FC5.
(10:37:28 AM) rdieter: tibbs; yeah, someone should have a gentle discussion with pgsql maintainer.
(10:37:31 AM) tibbs: We may have to pull it from the repo.
(10:37:51 AM) jeremy: tibbs: I need to send mail to tgl about the postgres update
(10:37:58 AM) nirik: flumotion needs new twisted bits...
(10:38:04 AM) ***jeremy has been trying to beat on getting the python stack in shape and so hasn't done so
(10:38:08 AM) tibbs: EVR fixes are harder to deal with, I think.
(10:38:35 AM) tibbs: I wonder if it's reasonable to refuse to push packages that violate EVR ordering between released branches.
(10:38:46 AM) thl: well, shall we create a official "extras release manager" position that takes care of poking people?
(10:38:55 AM) ***thl nominates nirik for that job
(10:38:56 AM) rdieter: tibbs: not unreasonable, just hard to check/enforce.
(10:39:19 AM) tibbs: rdieter: Obviously it's not too hard to check.  After all, something generates that report.
(10:39:29 AM) nirik: I think it would be something the QA SIG people could work on? I'd be happy to help out when I can...
(10:39:32 AM) rdieter: tibbs: sure, *after* the push happens. (:
(10:39:48 AM) tibbs: I don't think it's terribly time consuming.
(10:39:50 AM) nirik: I think the new updates thing from lmacken does check that?
(10:39:50 AM) wwoods: QA SIG?
(10:40:01 AM) lutter [n=dlutter]  entered the room.
(10:40:02 AM) bpepple: nirik: I agree.  The QA sig makes sense.
(10:40:08 AM) thl: nirik, agreed, but have ing an official "extras release manager" might help as people might fear his voice ;)
(10:40:14 AM) warren: a "poking people" position would be nice and focused.
(10:40:18 AM) thl: wwoods, well, more a Extras QA SIG
(10:40:19 AM) lmacken: nirik: it will
(10:40:26 AM) ***rdieter starts to sharpen the official poking stick.
(10:40:28 AM) tibbs: Yes, failure to install packages in our repo because they have busted deps is certainly a QA issue.
(10:40:34 AM) wwoods: thl: ah (just found Extras/SIGs/QA)
(10:40:40 AM) scop: thoughts about kmods in devel?
(10:41:04 AM) scop: with the current setup, I don't think packagers have a chance of keeping them off the EVR problems and broken deps reports
(10:41:16 AM) tibbs: scop: dkms is the only reasonable way to do that kind of thing.
(10:41:22 AM) thl: scop, someone just needs to work on making plague/mock kmod aware
(10:41:27 AM) nirik: it would assist if the Evr and broken deps reports were generated on every push. I think mschwent changed them to once every 2 weeks or something.
(10:41:59 AM) thl: tibbs, no
(10:42:08 AM) tibbs: no what?
(10:42:10 AM) thl: tibbs, the kabi stuff is somewhat a solution
(10:42:26 AM) tibbs: Funny, that.  Does it actually exist now?
(10:42:37 AM) thl: tibbs, yes
(10:42:38 AM) warren: well...
(10:42:51 AM) thl: but just to be clear: I'm not to glad with the status of the whole kmod stuff
(10:42:52 AM) warren: kabi stuff in RHEL5 is because the kabi hashes are supposed to not change
(10:42:56 AM) nirik: will be nice once core/extras is merged, then someone can see a new kernel build in the buildsys local repo and rebuild kmods, so they get pushed at the same time.
(10:43:00 AM) warren: kabi hashes in rawhide will change ALL THE TIME
(10:43:05 AM) thl: but I don#t have to much time to improve it
(10:43:22 AM) thl: nirik, exatly
(10:43:31 AM) tibbs: I still think that dkms is the only reasonable solution for rawhide, and even it won't help when the API changes.
(10:43:42 AM) ***nirik is also unhappy with the kmod stuff... had to build the zaptel-kmod from source for my asterisk box last time. ;(
(10:43:53 AM) thl: nirik, sumbitt it to livna ;)
(10:44:16 AM) nirik: yeah, might be worth it...
(10:44:24 AM) rdieter: tibbs may have a point, freshrpms is pushing out a few dkms-based packages, and it seems to work well.
(10:44:47 AM) tibbs: Still, this probably isn't the time to get into all of that.
(10:44:47 AM) thl: rdieter, well, we all agree that for our release tree we want kmods to build for our users, or?
(10:44:55 AM) thl: and not force them to rebuild the stuff locally?
(10:45:16 AM) thl: and I further don#t think we want different solutions for rawhide and stable, or?
(10:45:19 AM) rdieter: Not necessarily.
(10:45:20 AM) tibbs: I would rather rebuild the stuff locally.
(10:45:30 AM) tibbs: Because if a user reboots a machine in the interim, I get hosed systems.
(10:45:39 AM) rdieter: dkms doesn't *always* rebuild locally either.
(10:45:57 AM) tibbs: gcc isn't that bug.
(10:46:00 AM) tibbs: big.
(10:46:18 AM) nirik: I'm starting to decide that having any kmod packages is a bad idea. :( Oh well.
(10:46:19 AM) rdieter: (though, I think we're straying way off-topic now...)
(10:46:22 AM) ***bpepple steps out real quick to get some more firewood.
(10:46:26 AM) abadger1999: thl: I'm just wondering (perhaps like tibbs) if we all like dkms better -- do we really want to give our users an inferior solution because we *think* they don't want to have gcc on their systems?
(10:46:50 AM) abadger1999: (Also assuming that we all think highly of dkms)
(10:47:00 AM) nirik: back to the topic. I am happy to try and police the non devel broken deps and evr problems in extras (time permitting)
(10:47:02 AM) warren: abadger1999, kernel-devel is also big and slow
(10:47:35 AM) scop: off topic indeed... I'm mainly interested in whether people want something done about the reports *now*
(10:47:42 AM) warren: abadger1999, dkms is almost equivalent to kmod + better automation
(10:47:58 AM) tibbs: OT: great, someone branched denyhosts for EPEL already, but now a security issue has come up and there's no epel maintainer.  This pisses me off.
(10:47:59 AM) thl: btw, I have a system locally that rebuilds kmod srpms during boot
(10:48:07 AM) scop: ignore them?  filter from reports?
(10:48:09 AM) thl: I always wanted to bring it into shape
(10:48:21 AM) rdieter: thl: sounds fun. (:
(10:48:28 AM) thl: but it does the main thing we want in 2k where dkms needs more than 100k
(10:48:33 AM) warren: tibbs, security issue for denyhosts?  URL?
(10:48:35 AM) dgilmore: tibbs: i branched it
(10:48:36 AM) nirik: scop: I think if you have a kmod it's good to bug the maintainer to rebuild on the new kernel... so I would keep it as it is now
(10:48:54 AM) tibbs: dgilmore: please, do not branch unless there is a maintainer for it.
(10:49:04 AM) dgilmore: tibbs: right now its me
(10:49:13 AM) dgilmore: for epel anyway
(10:49:15 AM) thl: okay, we are running late a bit
(10:49:16 AM) tibbs: owners.list entry?
(10:49:23 AM) thl: let's move on for now, okay?
(10:49:24 AM) tibbs: Sorry for being offtopic.
(10:49:34 AM) thl: tibbs, np
(10:49:35 AM) scop: nirik, the maintainer has zero control over when FE signing+pushing happens no matter how closely he tracks things
(10:49:40 AM) dgilmore: tibbs: owners.epel.list  is not fully synced up
(10:49:52 AM) thl has changed the topic to: FESCo meeting -- MISC -- policy frontpage
(10:50:03 AM) thl: anything we should talk about?
(10:50:13 AM) ***bpepple is back.
(10:50:17 AM) thl: seems not
(10:50:18 AM) thl has changed the topic to: FESCo meeting -- Packaging Committee Report
(10:50:18 AM) tibbs: Thse are great, BTW.
(10:50:21 AM) nirik: scop: true. Perhaps we should have pushes happen at some specific time?
(10:50:35 AM) thl: do we agree that we want to approve all Conflicts?
(10:50:44 AM) rdieter: thl: +infinity
(10:50:45 AM) tibbs: I sent the report to fedora-maintainers yesterday; hopefully everyone saw it.
(10:50:53 AM) thl: we can find a better solution later if it's to much work
(10:50:54 AM) XulChris: ∞
(10:51:00 AM) abadger1999: thl: -1
(10:51:07 AM) abadger1999: At least for now.
(10:51:11 AM) tibbs: I guess the real question is whether it should be left to the reviewer.
(10:51:15 AM) scop: nirik, good luck suggesting that to extras-signers@fp.org ;)
(10:51:18 AM) rdieter: thl: sorry, misread, not sure.
(10:51:20 AM) abadger1999: tibbs: +1
(10:51:35 AM) rdieter: what if reviewer misses it?
(10:51:36 AM) tibbs: I don't believe it should be left to the reviewer, BTW.
(10:51:44 AM) thl: tibbs, +1
(10:51:51 AM) bpepple: tibbs: +!
(10:51:57 AM) bpepple: s/!/1/
(10:52:17 AM) thl: I'd say we over time just need to work out some examples what conflicts are okay and what not
(10:52:18 AM) nirik: scop: can't one person that has the key just plan on doing a push every work day at some specific time? Or thats too much planning?
(10:52:19 AM) abadger1999: Conflicts can creep in at any time, not just during initial review.
(10:52:31 AM) thl: then document them properly and let those easy ones up to the reviewer
(10:52:34 AM) tibbs: abadger1999: QA sig can deal with those.
(10:52:42 AM) thl: and all the other need to go to the PC or FESCo
(10:52:52 AM) tibbs: Versioned conflicts generally become outdated anyway.
(10:52:52 AM) nirik: whats the problem thats trying to be solved with approval of Conflicts? did someone push something with a bad conflict?
(10:53:05 AM) warren: Conflicts: kernel
(10:53:08 AM) warren: =)
(10:53:12 AM) thl: nirik, mschwendt made a lot of noise (and he was right with it)
(10:53:15 AM) abadger1999: thl: I'd be fine with that.
(10:53:32 AM) tibbs: nirik: There are multiple issues because COnflicts: is used for multiple things, unfortunately.
(10:53:38 AM) thl: abadger1999, can the PC discuss this idea in the next meeting?
(10:53:44 AM) abadger1999: thl: My proposal to the list was Disallow unless it is this kind of conflict.
(10:54:06 AM) tibbs: The draft isn't finished; I just wanted to bring it to FESCo's attention.
(10:54:06 AM) abadger1999: If it isn't and you think it's necessary, it has to go up for discussion, updating of guidelines.
(10:54:15 AM) thl: tibbs, sure
(10:54:49 AM) thl: I'll post a mail to the list and will try to be in the next PC's meeting
(10:54:51 AM) thl: that okay?
(10:54:55 AM) abadger1999: thl: Sounds good.
(10:54:58 AM) scop: nirik, speaking for myself, I can't promise to be available for that, maybe others can, dunno.  And a full push takes a loooong time during which things may already become stale if rawhide gets pruned in the background
(10:54:59 AM) tibbs: You're always welcome.
(10:55:15 AM) thl has changed the topic to: FESCO-Meeting -- kmod approval -- gspca [WWW]  https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=209112
(10:55:22 AM) thl: did anybody look at it?
(10:55:43 AM) thl: I suspect nearly nobody did
(10:55:53 AM) warren: how effective is it to ask for kmod approval during meetings?  perhaps better on fesco list?
(10:55:55 AM) thl: so I#d say we continue to discuss this package in the bug report
(10:56:00 AM) warren: where people can take their time and provide a vote
(10:56:13 AM) scop: list++
(10:56:38 AM) thl: scop, warren, well, just use the wiki diff as start for the voting then :)
(10:56:42 AM) tibbs: I remember that bug from a while back, but it didn't seem like there was much point in continuing with it since the submitter wanted to close it.
(10:56:54 AM) rdieter: list makes more sense.
(10:56:58 AM) thl: tibbs, the submitter asked me to bring it up
(10:57:10 AM) thl: rdieter, that why the diffs get send to the list
(10:57:20 AM) thl: they are always meant as a "let's discuss this"
(10:57:27 AM) rdieter: dunno, I don't remember seeing anything on the list. ??
(10:57:40 AM) rdieter: (maybe I just missed it)
(10:57:43 AM) spot: fwiw
(10:57:50 AM) spot: im interested in gspca
(10:57:55 AM) spot: because it makes my webcam work in linux
(10:57:58 AM) thl: rdieter, well, I'll try to make it more explict in the future ;)
(10:58:04 AM) spot: ive talked to the upstream author (he is french)
(10:58:25 AM) spot: and he wants to upstream it, but because of a massive disagreement in the v4l camp, its not likely to happen anytime soon
(10:58:47 AM) spot: code is good (to my eyes), rather well tested
(10:59:09 AM) thl: spot, some sort of semi-official statement in the bug from the author and/or you would be nice
(10:59:18 AM) thl: then i'll probably give a +1 to it
(10:59:20 AM) spot: i can dig it out of my email archives
(10:59:35 AM) thl: spot, thx
(10:59:38 AM) thl: then let's move on
(10:59:40 AM) thl has changed the topic to: FESCo meeting -- Maintainer Responsibility Policy -- bpepple -- EOL plans
(10:59:43 AM) thl: bpepple, ?
(10:59:46 AM) rdieter: thl: ditto.
(11:00:22 AM) bpepple: We're waiting to hear from the Legacy folks regarding whether to shut down the builders.
(11:00:48 AM) thl: bpepple, k; can you add that info-sniplet to the wiki please? tia
(11:00:54 AM) thl has changed the topic to: FESCo meeting -- Alternative paths of membership advancement -- warren
(11:00:57 AM) thl: warren, ?
(11:01:24 AM) mmcgrath: Swag?
(11:01:38 AM) ***thl puts "kmod stuff" on his schedule for saturday
(11:01:48 AM) thl: mmcgrath, ?
(11:02:06 AM) mmcgrath: nothin...
(11:02:10 AM) thl: bpepple, ohh, you did alreay :)
(11:02:19 AM) thl: warren seems lost
(11:02:21 AM) thl: moving on
(11:02:26 AM) thl has changed the topic to: FESCo meeting -- Free discussion around Fedora Extras
(11:02:31 AM) bpepple: thl: Yeah, though a bit late.
(11:02:34 AM) thl: anything else we should discuss?
(11:02:36 AM) mmcgrath: thl: one thing
(11:02:53 AM) mmcgrath: So I attempted to do the 'special requests' on the CVSSYNC page last night.  So if anything is borked let me know.
(11:03:06 AM) mmcgrath: But do we have a specific written policy around 'renaming' packages?
(11:03:09 AM) XulChris: scop: can you join #livna for a sec?
(11:03:15 AM) thl: mmcgrath, someone will yell is anything is borked
(11:03:33 AM) thl: mmcgrath, I'm not sure myself if we have a "policy around 'renaming' packages"
(11:03:36 AM) mmcgrath: What, in general, I did was request them to import the new module and I'll remove the old one from the 'modules' file but not the actual CVS for archive purposes.
(11:04:05 AM) warren: thl, I still need to do that, it is medium on my priority list (below some security issues)
(11:04:14 AM) thl: warren, k, thx
(11:04:33 AM) scop: I have a renaming related action item in the packaging committee, but that's probably not what you're talking about here
(11:04:49 AM) thl: mmcgrath, the history wil get lost that way (or am I wrong with that?)
(11:04:50 AM) abadger1999: mmcgrath: Do we ant to remove it from the modules file?  I thought we just wanted to empty the contents of branches and stick a dead.package file in each branch.
(11:05:35 AM) mmcgrath: Beats me, thats up to you guys.
(11:06:08 AM) mmcgrath: well, for example....
(11:06:19 AM) thl: someone should bring that up to f-e-l imho
(11:06:39 AM) thl: will the checkout by tag still work if we rename a package in cvs?
(11:06:46 AM) mmcgrath: We can take it off line if you want.
(11:06:49 AM) nirik: in the past we haven't removed it from modules... just EOLed the old package (dead.package, etc)
(11:06:52 AM) mmcgrath: no idea.
(11:07:07 AM) nirik: and then added the new one (with Obsoletes. :)
(11:07:21 AM) mmcgrath: So really whenever someone wants to remove a module or rename it, the cvs doesn't change, they just add the new one and leave the old one alone?
(11:07:32 AM) abadger1999: mmcgrath: Yep.
(11:07:41 AM) abadger1999: The packager takes care of all that.
(11:08:07 AM) abadger1999: They might request branches for the renamed package-module.
(11:08:28 AM) thl: everybody okay with taht scheme? then we should document it somewhere
(11:08:29 AM) abadger1999: Having reference to the old module at that point is nice to confirm it's really just a rename.
(11:08:45 AM) mmcgrath: WORKSFORME
(11:08:53 AM) bpepple: sounds good.
(11:09:09 AM) thl: awjb, can you document it please? you wanted to rename something iirc ;)
(11:09:45 AM) abadger1999: thl: Part of it is here: http://www.fedoraproject.org/wiki/Extras/PackageEndOfLife?highlight=%28dead.package%29
(11:10:00 AM) thl: abadger1999, well, it needs to be more explict afaics
(11:10:07 AM) abadger1999: I agree.
(11:10:17 AM) awjb: thl, yes will do
(11:10:23 AM) thl: awjb, thx :)
(11:10:26 AM) thl: anything else?
(11:10:46 AM) mmcgrath: nein
(11:10:46 AM) ***thl will end the meeting in 60
(11:11:01 AM) nbecker left the room ("Kopete 0.10.3 : http://kopete.kde.org").
(11:11:14 AM) ***thl will end the meeting in 30
(11:11:30 AM) rdieter: fyi, I've started actively making EL-4 branches for a bunch of my packages, and felt some pain...
(11:11:46 AM) rdieter: I forgot how many other Extras' packages I depended on. ):
(11:12:01 AM) mmcgrath: same here.  :: cough cough :: nagios-plugins :: COUGH COUGH ::
(11:12:04 AM) thl: rdieter, I had more luck and got all my important stuff build :)
(11:12:27 AM) rdieter: (:, qt4 should be coming soon... (once I get nas done)
(11:12:34 AM) thl: rdieter, mmcgrath, so what do you suggest? Open building for other contributors?
(11:12:47 AM) mmcgrath: Not quite yet..
(11:12:49 AM) rdieter: not sure, maybe not yet.
(11:12:51 AM) f13: mmcgrath: how did that mercurial build go?
(11:13:07 AM) thl: rdieter, mmcgrath, agreed
(11:13:14 AM) thl: let's discuss that next week
(11:13:17 AM) mmcgrath: http://buildsys.fedoraproject.org/logs/fedora-4-epel/23109-mercurial-0.9.1-2.el4/
(11:13:27 AM) ***thl will end the meeting in 15
(11:13:33 AM) ***thl will end the meeting in 10
(11:13:43 AM) thl: -- MARK -- Meeting End
Search

Extras/SteeringCommittee/Meeting-20061207

Contents
