Re: release update and branching
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
Reply to: