On Thu, Nov 18, 2004 at 11:23:34PM +0200, Anton Zinoviev wrote: > On Thu, Nov 18, 2004 at 01:44:43AM -0500, Joey Hess wrote: > > > > - upload to unstable > > Advantage: Easy, sid_d-i images will use them, fully autobuilt. > > Disadvantage: Any sarge fixes would have to go through t-p-u, > > which does not currently have a full set of autobuilders. > > - upload to experimental > > Advantage: Getting fixes into sarge stays easy. > > Disadvantage: Only autobuilt on a few arches, we'd have to add > > experimental_d-i CDs, and do something to make the > > daily builds use experimental udebs. > The upload to unstable is risky - it means that it will be difficult to > make updates in rc2 if some need arises. Its not only the lack of > autobuilders for t-p-u. T-p-u doesn't have its own distribution and > daily built images and this means that the future changes in sarge will > be untested. > I think that in general it will be usefull to develop the infrastructure > of experimental. With the help of experimental we would not need to > break rc1, we could use the following distribution: > testing -> rc1 > unstable -> pre-rc2 > experimental -> rc2 > After the release of rc2 we could use this: > testing -> rc1 > unstable -> rc2 > experimental -> rc2-updates > After a very short period of testing this could be changed to > testing -> rc2 > unstable -> fixes for rc2 > experimental -> rc3 > When rc2 becomes stable we could use unstable in order to make frequent > pre-releases of rc3. The hidden impact of such an approach is that it freezes certain kinds of base system changes out of testing for the entire time between the rc1 release and the rc2 release. I think the tradeoffs made to be able to trim down the base system and update library dependencies instead of keeping rc1 usable were good ones. -- Steve Langasek postmodern programmer
Attachment:
signature.asc
Description: Digital signature