role of unstable in releasing Debian (Re: R 3.0.0 and required rebuilds of all reverse Depends: of R)
Hello,
[ some quotes reordered ]
2013-04-01 16:45, Neil McGovern:
> As for consensus, have a read over this thread to see if there's anyone
> supporting your views.
Well, if you resort to this argument, here I am, supporting some part of
those views. Not supporting the rude tone though.
> http://wiki.debian.org/DebianStability.
I did not sign that. Also, I'd rename it to
'EverythingExceptStableReleasesIsUnimportant'. This is IMO not the same
as 'stability', more on that under.
> Also see dev-ref 3.1.
That is mostly fine, the questionable point there is 'most users will
only benefit from your packages when they are released as part of the
next stable release'. And we advertise our great testing/unstable
branches, the point would be even more questionable.
> And the huge amount of discussion that lead to
> http://wiki.debian.org/ReleaseProposals in 2005.
Nice link, thanks. Do I understand correctly, there were 30
models/changes proposed there but nothing of them was tried or voted or
considered for adoption? In other words, the deliberate choice of
Release Team so far is
http://wiki.debian.org/JustIgnoreAndContinueAsAlways [1]?
One very interesting proposal there,
http://wiki.debian.org/SubProjectPerStabilityLevel, lists "It might be
hard to find people who actually WANT to work on the stable/testing
teams" as one of disadvantages. If it's false, we might try to seriously
consider implementing it as practically disadvantage-free [2]. If it's
true, I don't understand how "only stable matters for us" can be true.
> You seem to believe that unstable is more important than stable
> releases. I do not. One of us is in the wrong project.
I do consider, from certain point and for the software of certain [6]
categories, working on unstable more important than working on stable.
Working on unstable now will benefit wheezy+1, wheezy+2, wheezy+3, ...,
wheezy+inf, unstable/experimental, developers, prospective contributors,
upstreams. Working on stable [5] will benefit, limitedly [3], wheezy and
upstreams.
On stability. I, particularly, would not measure Debian quality in a
number of open RC bugs in the coming stable release. If Debian is
released once in 10 years with 0 RC bugs, most of users will go away. If
Debian is released with only 100 carefully selected RC-free packages,
most of users will go away. The package which crashes and misbehaves
here and there (100 normal bugs, 10 important ones) is [4] IMHO less
useful than the one which works more or less fine but always knowingly
crashes on armel (1 RC bug). Documentation, feature sets, translations,
friendliness with mortal bug reporters -- lack of any of those will have
an influence but hardly ever filed as RC bug. The current system doesn't
take many things into account.
I also do think that the Release Team tries to do a good job but The
Process doesn't scale and should be eventually replaced. As well as that
part of release guidelines which currently just counts relevant RC bugs.
[1] empty but nice page linked from http://wiki.debian.org/ReleaseProposals
[2] the second mentioned disadvantage is "Stable might be permenently 1-2
years out of date instead of being new once every four years.", and as
of moment of writing stable is permanently 1-3 years out of date.
[3] because:
- not much can be done, limited set of changes are accepted and many
bugs are not fixable by "strangers";
- fixing issues in "other" packages -- more risky;
- often porting bugfixes from already released upstream point releases
-- zero benefit to upstream/non-Debian users, less tested changes.
[4] if there is no viable alternatives
[5] as opposed to freely working on unstable
[6] but quite broad
--
Eugene V. Lyubimkin aka JackYF, JID: jackyf.devel(maildog)gmail.com
C++ GNU/Linux userspace developer, Debian Developer
Reply to: