continuing with sprint development post-fc5

[Thorsten Leemhuis]

Am Donnerstag, den 02.03.2006, 19:41 -0500 schrieb Mike A. Harris:
> Nicolas Mailhot wrote:
> > Le jeudi 02 mars 2006 à 18:11 +0100, Thorsten Leemhuis a écrit :
> >>>Uhm... isn't the per Core release updates-testing repo appropriate for
> >>>exactly this sort of work?
> >>I considered the same answer. But the more I think about it the more I
> >>tend to "no, that's not a good idea". We might scare away those that
> >>only want to help testing updated packages that *should* work fine
> >>before they enter updates proper.
> >>So my vote: Create updates-experimental for this stuff. 
> > I'm pretty sure you do NOT want to create such a repository.
> > If you create a single repository, where davej will push kernels,
> > mharris xorg updates, dan selinux stuff etc :
> > 1. you're recreating rawhide (badly, by another name). What one
> > maintainer will call an acceptable experiment another will call
> > destabilising the common repo

I disagree a small bit. Rawhide would probably be way more experimental
(depends on how exactly such a repo was filled). For example it is to
experimental for me and needs to much internet-bandwidth for the
updates. But I would use such a experimental repo.

> > 2. you have the same problem as before : users are scared because they
> > may agree to experiment with the kernel, or selinux, or xorg, or
> > something_else, but never all of them at once

You can put "exclude=foo" or "include=foo" into your yum config if you
don't want everything.

Site note so skvidal: Maybe a "includewithdeps=foo" would be nice
enhancement for .repo files. E.g. include foo, but if it needs bar from
the same repo include that, too.

> > What you need is something like what happens on p.r.c., or with kernel
> > trees : specialized repos, each with a clearly defined functional
> > target, and only the stuff related to this target.

And is hard to manage and to find. Each maintainer uses a different
layout. yum repodata was often missing, too. And space it limited on
p.r.c iirc. And there is no documentation or summary where to find
what. 

> > If you do it this way it'll be a big success. If you mix everything it
> > will be a repo in search of users like updates-testing.
> > 
> > (also if you separate stuff you can always create a consolidated repo
> > too, but I doubt it'll be used)

I would use it. 

> I strongly agree with this view.  Someone may want to be a guinea pig
> for aiglx et al. but not want to mess around with experimental kernels,
> openoffice or other components.  It makes the most sense to have a
> separate repo per development domain, where a domain is a single
> package, group of packages, or group of packages including special
> dependencies they need, etc.

Well, than let do this: Create somewhere a place where all experimental
update stuff is collected in separate repos (site by site, same layout,
with yum repodata, so people actually can find it easily and don't have
to search p.r.c over and over). Create a Meta-Repo where all those files
from the other repos are included. Best of both worlds.

CU
thl