[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

jessie to be a derivative?

There have been various discussions about how to change the release process

I'm not personally convinced that the process is fundamentally flawed.
If there are still as many wheezy systems in 10 years as there are
Windows XP machines in corporations today, then people won't remember
the freeze in a negative way.

So here's my own contribution: why not make Jessie a derivative?  In
other words, a greater separation between the unstable world and the
stable environment, with more ways for unstable packages to be
cultivated before they emerge in testing and a real stable release.

Taking this further (and with appropriate safety warnings in the tools):

a) making packages from mentors installable, so that people can try them
more quickly and upstreams can get involved at the bleeding edge

b) patches sent to the bug tracker should be automatically applied to a
branch in git and should produce an installable, binary `branch package'
accessible with apt-get for those who want to validate the patch.  The
maintainer has last say and what is merged and when, but users can try
more things.

c) more distinction between core and non-core packages.  There is too
much focus on packages that are tied to the Debian release and nothing
can be changed.  Here are some examples that challenge that thinking:

- Ganglia: somebody deploying Ganglia to a mixed environment is much
more concerned about having all their hosts (Debian, Redhat, Windows)
running a common version of Ganglia than using the Ganglia version that
corresponds to each host's OS version.

- VoIP/RTC: people want to use the version of the product that maximizes
their ability to make and receive calls on the public Internet.  Lack of
interoperability is fundamentally more disruptive than the regular
updates of such packages.  Backports currently goes some way to filling
that gap, but maybe backports should be enabled on all stable installs
by default, and maintainers can designate non-core packages that should
follow backports unless the user chooses otherwise.

Reply to: