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
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
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.
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 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.
--
Mike A. Harris * Open Source Advocate * http://mharris.ca
Proud Canadian.
