= 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 at 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
}}}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-extras-list/attachments/20061218/ebd6208e/attachment.sig>