continuing with sprint development post-fc5

[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
> 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.