Why does Wesnoth stay in experimental?

[Gerfried Fuchs]

* Andreas Tille <tillea at rki.de> [2009-03-18 20:37:47 CET]:
> On Wed, 18 Mar 2009, Gerfried Fuchs wrote:
> >Because wesnoth follows the (ancient) kernel appoach of having even
> >minor versions for their stable releases and odd versions for their
> >devleopment releases.
> 
> Sure, I'm able to read. ;-)

 I know, often enough it's still needed to point such things out, and
it's not meant to belittle you. :)

> >Development releases are often enough incompatible
> >with their former version - like I started the campaign The South Guard
> >with 1.5.6 or such and now am able to run over walls with some of my
> >units because changed statistics to them.
> 
> wesnoth.org says:
> 
>    Wesnoth 1.5.14: Third release candidate for 1.6

 Yes - and still there just was a compatibility change between 1.5.13
and 1.5.14. The issue is not only related to campaign playability (I did
stumble into such a change myself). It is also about multiplayer server
support and posibility to play against others through the servers.

> >This is *nothing* that we want
> >to push anywhere near a stable release.
> 
> Huh what????
> Are we *really* *near* a *stable* release?  Please check your time
> travel device - it seems to be terribly broken! ;-))

 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. Doing that
only at times close to release just result in major release delays and I
_really_ would like to see more people think about their uploads all the
time and not only close to a release.

> Or are you talking about Wesnoth stable release.

 Both. I (or many) do care for the users and see it as a disservice to
send development releases down their throat when there is a clear
distinction of a stable/development release tree approach upstream. Have
you gone through the bugreports that wesnoth receive? I would by no
means want to have them doubled because of some compatibility changes in
development releases that aren't targeted as the casual end users.

> I intended to say Debian *unstable* has the name for a reason: You
> should expect some software which is not perfect there, right?

 Wrong. unstable has the name for the reason that things like library
transitions and uninstallability of different things can happen.
Anything uploaded to unstable still is expected to be in a state that
would mean that it *could* get included in a stable release. A
development release of wesnoth will never get included in a stable
release because it's a moving target upstream, unsupported upstream, and
I (and I guess I am speaking for the other team members here) am
unwilling to play upstream for such a version.

> >>I understood it once Lenny was not released but now it is definitely
> >>time for unstable
> >
> >Not for a 1.5 version.
> 
> Well, it's definitely your decision - but there are several prereleases of
> much more important software than a game that at best might break your
> savegames but not your computer.

 Again, its not only the savegames - and even then, the savegames are a
core feature of the package; breaking it deliberately falls under quite
some definition of a RC bug.

> I followed every version since 1.5.6 and *never* broke anything

 Then you never played The South Guard (and I'm sure it wasn't limited
to only that campaign), nor did try to play with someone else over the
net who had a different 1.5 version. Being able to walk over walls might
be a nice thing, but it's not meant to be.

> >>because we are even in the prerelease phase which perfectly fits things in
> >>Debian which is called *unstable*.
> >
> >Yes, but still uploads to unstable should be in a state that can get
> >considered to be part of a release at some point. The development branch
> >of wesnoth isn't.
> 
> Sorry, we do not even have a release plan.  Do you expect Wesnoth to
> need > 12 month from third RC candidate until release?

 That question shows clearly that you do want random breakages in
unstable and low quality. I really hope that I misunderstand you there
and that you do *not* only care for quality close to releases.

> >Erm, beg your pardon? I can't follow that, _at all_. i386 _is_
> >autobuilt and in the pool. Can you pretty please check the pool before
> >bringing up false reasonings?
> 
> Well, I had experimental in my sources.list and either i386 was lagging
> two or three days behind or not copied to the mirror I used.

 Yes, things like that can happen but by no means are limited to
experimental. This is the same with unstable and in no way different
there.

> At least my installation was broken for a couple of days until I
> builded from source because of missing wesnoth-core package.

 The exactly same would happen to you after an upload to unstable - and
that's the central meaning of the release name. For exactly this see
<http://bugs.debian.org/517265>.

> The day before yesterday I list my nerves and excluded experimental
> from my sources.list and that way you just loose a tester.

 That I upload the development releases to experimental is much more of
a courtsey, and I'm sorry that you consider it an annoyance.

> And no, I'm not interested in digging the archive why i386 was lagging
> behind in this concern.  Just assume you are right and I'm wrong in
> this very issue - but your reasoning about RC candidates of games in
> experimental is quite weak.

 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.

> >Thanks for thinking along. Sorry if this respond sounds a bit harsh -
> 
> I can perfectly bear harsh words.  I have problems with unreasonable
> arguing.

 Hmm, then I guess we are on the same side - as I do have problems with
the unreasonable argument that unstable is meant to be a target for
not-really-release-fit uploads. Yes, I know, others are doing bad things
with their packages, but that doesn't lower my own QA wishes and hopes.

> >and in some few hours you might even be pleased because 1.6 gets
> >finalized today.
> 
> So what was you talking about above?  It confuses me even more.

 That 1.6 has an even number and is promised to be compatible with
upcoming 1.6 patch releases. 1.5.14 has an odd number and is *not*
promised to be compatible with upcoming 1.6 (patch) release(s).

> So even if I do not understand your release policy - thanks for
> your work on this nice game

 Maybe I was able to be a bit more clear in this mail. I really hope so. :)

 So long!
Rhonda [building 1.6 packages ...]