Re: so what? Re: Debian development modem
On Fri, 29 May 1998, David Engel wrote:
> On Fri, May 29, 1998 at 10:56:35AM +0800, Bill Mitchell wrote:
> > 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).
> > ...
> > 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.
>
> I don't believe this is workable. First, I doubt that enough
> developers would have the required system resources to work on 3 (or
> more) different releases at the same time. Second, Debian has a
> purely volunteer work force. It's hard enough already getting a
> sustained effort working on a single release. If that effort was
> diminished by dividing the volunteers across multiple releases,
> nothing would ever get done.
I don't think I succeeded in communicating my suggestion very well.
I was speaking of just two releases above, debian-current (e.g., bo),
and debian-next (e.g., hamm). The bo->hamm development model stabilized
the package set released with bo a year or so ago as the production
release, except for serious bugfixes, and concentrated both system
development effort and package maintenance effort in the essentially
debian-developer-only hamm release. Now, a year or so later, users of
the the year-old debian 1.3.x release are using packages several revisions
behind what the users of other linux distributions are using.
I suspect that you are correct that many package maintainers probably
do not have the resources and the time to work on two or more releases.
For bo->hamm, debian chose to concentrate both the development effort
for the next system release and the package maintainer effort in the
mostly debian-developer-only hamm release. I am suggesting that, in
future, system development effort be focused on the developmental system
release, but that package maintenance effort be concentrated on the
current production release used by the debian user community.
The current production debian release would move forward in a series of
regular minor releases, incorporating new and updated packages. The
packages incorporated into the release would initially be considered
`unproven'. Unproven packages would go through some sort of validation
(details TBD), after which they would be considered `proven'. At
periodic release intervals, `proven' packages would be incorporated
into the production release, and the minor release number incremented.
Maintainers working on individual package maintenance would need to
do their package maintenance on a system based on the current production
release.
Development of a new system release not fully backwards compatible
with the current production release (e.g., 1.2 vs. 1.3, or 1.3 vs. 2.0)
would be done by developers able to run the new release. If these
developers also maintained individual packages, they would need to be
able to run both the current production release for package maintenance
and the new developmental release for system development. This probably
means that not all package maintainers would also be working on system
development for the next release. So be it. A smaller development team
working on next-release system development issues might well move forward
faster.
System developers working on the next system release would make a
major effort not to break backwards compatibility with packages
in current release for the current production release. In fact,
their development systems would use forward-compatible packages
from the current production release. Where it became necessary to
break inter-release compatibility for individual packages, that would
be addressed on a package-by-package basis.
At completion of system development, and prior to system release, the
situation with regard to packages with broken compatibility to the
new system release would be reviewed. These packages would need either
to be removed from the distribution or brought forward with a
new-release-compatible package revision.
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: