> 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 I see your point, but at the same time some of the stuff Chris is talking about involves all of those things. Like suspend... it's more than just the kernel needed. > 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. Which can be the kernel, selinux, xorg, _and_ something_else depending on the 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. It'll also be a big PITA. That could be a lot of repos depending on how things fall out. I think the bigger question is, are the Core developers going to have time to do this? If not, then it's largely a waste of time. I'm cautiously optimistic :) josh
