Why does Wesnoth stay in experimental?

[Gerfried Fuchs]

* Andreas Tille <tillea at rki.de> [2009-03-18 23:02:28 CET]:
> On Wed, 18 Mar 2009, Gerfried Fuchs wrote:
> > Uploads to unstable are meant to be in a state that makes them fit for
> > a release - this has nothing to do with that we just released lenny and
> > now can break unstable (and with that testing) for everyone.
> 
> Well, if you regard uploading an RC candidate of a game "break
> unstable for *everyone*" there is no need for further discussion.

 I was just following your reasoning of that we can and should break
unstable now that lenny is out the door. Yes, I was exaggerating, but
...

> > Wrong. unstable has the name for the reason that things like library
> > transitions and uninstallability of different things can happen.
> 
> Well, IMHO RC candidates need testing - also by users of a distribution.
> Filing a dummy RC bug against the release candidate could ensure that it
> will not be propagated to testing - that's not a big deal.

 But it will eliminate any sensible transition path to child
distributions. Please notice that Ubuntu is just about to release
jaunty. Any upload of a development release of wesnoth into unstable
means a.) either they have to stop syncing the package and have no
support for their stable version anymore (please be reminded of the
recent wesnoth security advisory), or b.) they sync a development
release - and throw a version down the throat of their users that they
will be unhappy with because they won't be able to play against people
of other releases of their own distribution, let alone against people of
other distributions (like Debian).

 And to be honest, we also have the problem within Debian: If I push it
to unstable too early I cut off the posibility for proper backports with
that, too.

 If you care only for Debian that's fine, and propably most people do,
but I don't want to limit myself to this and end up in the case of that
ubuntu (or other child distributions) have to carry around major diff
files that might be needed to get things working properly but
technically aren't really neccessary, at all. BTDT, and I had quite some
discussion with the people involved to get things back on track - for
the benefit of Debian, Ubuntu, all other child distributions and
upstream.

> > Anything uploaded to unstable still is expected to be in a state that
> > would mean that it *could* get included in a stable release.
> 
> In theory yes - but didn't we talked about a very specific example
> where you mentioned yourself that stable is under way?

 I don't read "under way" as "being there already" - do you?

> And preventing users of unstable does not help upstream to get
> enough testers.

 My approach is perfectly fine with upstream, trust me. Also, see below.

>  There are reasons for both opinions.  You are
> entertaining sticking to principles where your deeper insight into
> the details should enable you to find a reasonable compromise.
> 
> > That question shows clearly that you do want random breakages in
> > unstable and low quality.
> 
> No.  It shows clearly that I trust upstream to have stabilised
> the third RC candidate.

 I don't, and neither does upstream itself, nor does they promise it.

> Nothing more.  Please stop trying to accuse me to things like that.

 Well, you started to throw around claims that my reasoning is
unreasonable, please mind your own business.

> > That I upload the development releases to experimental is much more of
> > a courtsey, and I'm sorry that you consider it an annoyance.
> 
> I was using the packages happily and silently but raised my voice
> at RC3.   See the difference?

 Only partly. If it were any other upstream project, we wouldn't have
the discussion. There _is_ a significant difference here, though - which
is the compatibility that is only promised within stable releases.

> > If the RC candidate would be bound to be compatible with the upcoming
> > 1.6 release I would do you the favour. History has shown that it isn't,
> > so I stick with the rather-safe-than-sorry approach.
> 
> I admit this is the only point in your arguing which has some logic -
> even if I can not really believe that upstream does this kind of
> things.

 That's the core point of doing RCs. Its a statement of "almost there"
but things _can_ still happen (and they did just recently, not sure
wether it was between 12 to 13 or between 13 to 14). If it would mean
that all RCs are already bound to the strict policies of the stable
release there wouldn't be any reason to call them RCs but do them as
proper stable releases directly.

 And there is also a technical reason behind it: The logic to set the
versioned dependencies within the various binary packages is a lot
different between two stable releases and two development releases. As
things still can change within the RCs (and do, like history has shown)
setting proper versioned depends is both tricky and extremely error
prone - and I do not want to break these things.

> Finally, please just try to finish 1.6 packages and let's stop this
> arguing.  Thanks for maintaining Wesnoth

 You might also find the following page quite interesting:
<http://wesnoth.org/wiki/Wesnoth1.6ReleasePlan> - especially the times,
and by no means would I start to rant against two weeks of hiding RCs
in experimental, or especially I have no reason at all to risk any
breakage for anyone (Debian or any of its child distributions) for just
ridiculous two damned weeks.

 But whatever, thanks for your feedback anyway,
Rhonda