Re: jessie to be a derivative?
On 11-05-13 13:31, Daniel Pocock wrote:
> 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?
A "derivative" is a distribution made from debian _by another party_.
Since we'd still be the ones making it, it can't be a derivative, by
definition.
> 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
That's already possible, just put mentors.debian.net in your sources.list?
Having said that, the point of mentors.debian.net is that inexperienced
maintainers can upload their packages there, so that a debian developer
can look at them and give feedback -- not that people should use it as
an archive of installable packages.
> 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.
Bad idea, for security reasons. Anyone can send patches to the BTS,
including patches that change code which is run at build time
(debian/rules or the upstream build system).
Even if you'd figure out a way to do this safely you'd still need a
*lot* of code before you can even start thinking about this:
- something to automatically turn source packages into git repositories
- something to fish patches from the BTS and apply them to said git
repositories
- some workflow to go from "commit on git repository" into "package is
built automatically"
> 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.
That suggestion has been made before, but nobody has ever come up with a
good way to decide what to do when many packages that are not in the
"core" system aren't ready to release. Yes, we could throw them out; but
one of the strengths of Debian is exactly the fact that we have so many
packages, all with the same amount of QA. If we have to throw out many
non-"core" packages, we lose that advantage.
Yes, it has downsides. Deciding that those downsides make it not worth
the effort anymore feels like throwing out the kid with the bathwater to me.
> 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.
Yes, sometimes the version in Debian stable doesn't fit your needs
because of outside requirements. In that case, the best way forward is
to either install a backport or install from source.
There isn't much we can do about that; I'm sure you're not suggesting we
ensure all possible versions of all possible packages are installable on
a stable system.
> - 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.
That is pretty much true for just about any application that speaks a
network protocol; VoIP isn't very special in that regard.
As regards interoperability: I've been doing SIP to a third party which
is not using Debian for quite a few years now, and have never seen any
issues with that. What are you talking about?
> 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.
Backports do not enjoy the same level of support that Debian stable
does. Installing backports should only be done by informed users, who
know what the downsides are. I don't think we should make some packages
be installable from backports by default, either.
--
This end should point toward the ground if you want to go to space.
If it starts pointing toward space you are having a bad problem and you
will not go to space today.
-- http://xkcd.com/1133/
Reply to: