Re: Granual release proposal
Andrew Lenharth <andrewl@master.debian.org> writes:
> Preface: I can see the flames forming now, and this proposal is far
> from perfect, but it is a start.
>
> Proposal: A more granual release process
Granular? Gradual?
> Solution: Now that we have package pools, we can revise the release
> process without large effects on archive size. I would propose
> creating new sections for major subsystems. Major groups of
> packages in their own section can then be stablized as a section
> (against the current stable base) and released. Since most of the
> time the testing and stable branches of a section are both compiled
> against the current stable base, users should be able to follow
> testing for only those section they are interested in. I could see
> the following sections being useful (by no means exhastive): base,
> xwindows, kde, gnome, network, dev, sound, misc.
>
The fight over what sections Debian should be divided in would
probably be a religious war like few others. So I won't comment on
that :)
> The release cycle would thus work like this.
>
> All sections would normally be being compiled agaist the current
> stable base. When a section is ready to be release (that section's
> testing meets release criteria and the maintainers of packages there
> feel it is ready), its packages are moved into that section's
> stable. Main will then be updated, since it is simply a collection
> of all stable sections. Debian announces a new minor release! This
> process doesn't impose any new packages in the archive, it just
> involves more directories and a few Packages.gz files.
>
> When a new base is approaching release condition, an announcment
> will be made to give all other sections a chance to be tested
> against the new base. When the new base is stablized we have a new
> release, however, we then wait until all sections are functional
> against this new base before releasing. Debian announces a new
> major release.
I think there are a few problems with your approach.
Suppose Debian is divided into 10 sections. Suppose there are two
versions (stable and testing) of each section which at least should
work reasonably. This means 2^10 possible combinations. While sections
such as sound may be quite independent from others such as network,
many others (especially 'misc') are not. This would mean that each
section should be extensively tested in at least 10 different
environments, and that the work of the maintainers would increase
exponentially. The maintainer of some sound player using OSS, KDE and
Mesa for some effect plugin would already need to test his program in
at least 2^3 = 8 different environments.
The traditional approach may not be the most marketable, but for the
quality it's best, IMHO. I just think that the testing/stable cycle
should be accelerated a bit (more releases with less changes, in other
words).
Aaron
PS: Would you mind breaking your paragraphs at 80 chars next time?
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: