Re: so what? Re: Debian development modem
I've been lurking, and have some musings and suggestions which I think
might be useful. I'll use a post from Ian J. as a jumping off point.
On Thu, 28 May 1998, Ian Jackson wrote:
> I see one big reason why hamm is taking so long to release: it's not
> compatible with bo.
>
> This has made developers (many of whom were attracted by Debian's
> incremental and partial upgrade capability) very reluctant to
> upgrade. It has also made it impossible to fix bugs in bo.
>
> Let us never make this mistake again.
Major releases tend to be this way. Version numbering aside, it seems
to me that most/all debian releases have been major.
Offhand, I don't recall the details prior to 1.2 but, as I recall it,
1.2->1.3 was libc4->libc5, a.out->elf, and curses->terminfo. 1.3->2.0 is
libc5->libc6. Both upgrades involve issues which go beyond just releasing
a later, spiffier, and more featureful collection of packages. Both, to
some extent, involve incompatibilities with previous releases. These
incompatibilities make upgrading touchy. The curses->terminfo change
implied that quite a number of packages needed to be be upgraded as part
of any 1.2->1.3 upgrade, even if a.out support was preserved.
> We should, instead, simply freeze unstable every six months, and
> release it three months or so later. A package should be allowed into
> frozen (or stable) if it would improve the quality of the
> distribution.
If working on a major release which involves making next-release packages
which are incompatible with current-release packages, I think that
a directory tree needs to be maintained with up-to-date current-release
packages as well. The current release should not be frozen in time
except for bugfixes -- it needs to keep pace with new package releases
and old package featurizations as well. If not, debian will be perceived
as being outdated compared to other distributions containing later and
more current versions of the packages.
For hamm development, a decision was made to freeze bo except for serious
bugfixes (I presume this decision has remained in force during the months
of my most recent absence from debian). This, as I recall, was in
reaction to two pressures:
CD Manufacturers had problems in making an investment to produce a
1.3.0 CD, only to have it immediately superseded by a 1.3.1 CD with
minor changes. So as not to present a disincentive against putting
out debian CDs, the current release needed to be less volatile.
Some (most?) package maintainers had a problem keeping packages
current in both libc5 and libc6 formats. Dropping the requirement
for libc5 package maintenance gave an incentive for maintainers to
upgrade to libc6.
> We have often good backwards compatibility, so that it doesn't matter
> if our stable distribution is a mixture of a.out and ELF or libc5 and
> libc6.
With hindsight, it seems that we would have been better off to pay more
attention to maintaining an environment of good backwards compatibility
for packages, to have package maintenance take place in a directory tree
based on the current debian system release, and to do development towards
the next major system release in a separate tree where backwards
compatibility is maintained for current-release packages where possible.
Packages which require separate versions for debian-current and debian-next
system releases would have two concurrent versions (which might need
another change to package version numbering conventions), or would be
simply unavailable in the next-release tree.
All package maintainers would need debian-current release based
development systems. Developers working on the debian-next release
would need development systems for both debian-current and debian-next.
(debian-current and debian-next being major releases having some
degree of incompatibility. debian-current would have periodic
release-numbered minor releases).
For the debian-current release, there would probably be a stable
tree which is updated every N months with later-release packages
which are considered stable. This tree should probably be updated
no less often than every three months, so as not to fall too far
behind package releases by other distributions. There would also
probably be an unstable (unproven?) tree with the latest maintainer
release. Criteria for releasing packages from unstable (unproven?)
to stable might be that it have been in the unstable tree for at least
one month and/or have a `seems OK' endorsement by at least N debian
users (mechanics for gathering the endorsements to be determined).
Come to think of it, there would probably be three debian-current release
trees. I might name them released, proven, and unproven. `released'
would be the current minor-release stable tree. `proven' would be
packages which had met minor-release criteria but had not yet been
picked up in a release. `unproven' would be the latest maintainer
release.
In addition to these debian-current release trees, there would be
at least one debian-next tree. This would probably be mostly
symlinks back to forward-compatible packages in a debian-current
tree (probably to the package in the debian-current unproven tree).
Where it became known that cross-release compatibility for a package
would be broken, the symlink would be deleted. Such deleted symlinks
would either be left that way or replaced with compatible package versions
maintained concurrently with the incompatible version in the current-release
tree. If there is only one next-release tree, as is currently done, there
would be no guarantee that it contains a consistent package set at any
given time. Only active debian-next developers and others wishing to live
on the bleeding edge would use this tree.
CD manufacturers could release CDs based on the debian-current `released'
tree at a every-N month cycle with an incremented minor release number.
They might or might not include the current-release `proven' and/or
`unproven' trees. (if the release cycle is three months, A monthly CD
containing the latest proven & unproven trees might be attractive).
CD manufacturers might or might not offer CDs with the bleeding edge
debian-next tree. I would hope that at least one or two would.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: