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 -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130401205054.GA14204@debian-w500.Elisa
