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. Ofcourse this is only one possibility. Other uses of experimental are also possible. By the way, I think that the problems we encounter with the release process of the installer are not only problems of d-i. If we find a good solution of our needs we will be able to use our experience in order to improve the release process of Debian as a whole. I can remember that 2-3 years ago Raphael Hertzog as a candidate for DPL proposed the use of so called "working" distribution. "Working" has to be kept always mostly in releaseble state, it stays between "testing" and "stable". The changes in "unstable" do not go automatically in "working", acording to Raphael "working" should be maintained the similar way as now "testing" is maintained inside d-i. http://www.debian.org/vote/2002/platforms/raphael#release1 Currently the release process of Debian is a cycle with two phases: 1. change the packages, no work on the release 2. freeze the packages, work for the next release "Working" means that we can accomplish 1. and 2. simultaneously because "working" is always freezed and "testing" is never freezed. Hence more frequent releases. > Especially if we're sure that after rc2, d-i updates > for sarge will be limited to security fixes, fixes for any base system > breakage, and maybe discover1-data updates. Any chances for updates in the area of i18n? More than a month ago some languages reached a level where they could be released. Too bad for the work of the translators if their work is outcast. Some updates in the existing translations is probably also desired. Anton Zinoviev -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
