Re: after 3.2

[Jaroslav Hajek]

On Fri, Mar 13, 2009 at 9:07 AM, John W. Eaton <address@hidden> wrote:
> On 13-Mar-2009, Thomas Weber wrote:
>
> | That said, is there really a need to have two branches, stable and
> | development? It seems the Linux kernel works quite nicely with just one
> | branch.
>
> So just dismiss with the updates to the stable releases, and only have
> a series of releases?
>
> That's fine with me, but it doesn't give people a lot of comfort when
> there are bugs in a release and the next one might be N months away
> and introduce a lot of new untested features that could cause more
> trouble even if there are fixes for the problems found in the previous
> release.
>
> The goal of the stable release series is to converge on something
> that is more or less free of show-stopping bugs, even if it doesn't
> have all the latest features.  But I'm not sure we do a good job of
> that when we do more than fix regressions (and possibly other serious
> bugs) in the stable release.  As Jaroslav noted, transplanting patches
> from the development tree can have a destabilizing effect as the two
> branches diverge.
>
> jwe
>

To carry on the idea of linear development:
I think we have essentially two groups of users using binaries: users
of packages provided by GNU/Linux distros, and users of the Windows
binaries.
As for the distro users, it's just a question of how often they can
make package updates. My impression is that most distros (e.g. Debian)
have a fairly sophisticated auto-building systems, so that updating a
binary package, say (a wild guess), once per month is not a big deal.
Perhaps the package maintainers visiting this list can comment.

As for the Windows binaries, it would be fairly nice to have something
similar to auto-updates provided by Linux distros. I'm fairly
convinced that users don't really mind bugs if there's a good chance
of getting rid of them by a few clicks within a month via some
automatic update mechanism.  Imagine a dialog popping up for the
Windows user telling him "an update is available, click OK to
install". But of course, this would require some development.

My main point is that when releases are only made twice per year,
users (other than those building from development sources) don't fully
experience one of the primary advantages of the openness of free
software: the fast bug-fixing.
Let's say that most bugs are being fixed in the development sources
within 1-2 weeks, but delivered to users in 2-4 months. It would be
very nice to close this gap somewhat.

At least that's my personal feeling. In the internet age, installing
software is not, and shouldn't be, much of a limiting factor.


-- 
RNDr. Jaroslav Hajek
computing expert & GNU Octave developer
Aeronautical Research and Test Institute (VZLU)
Prague, Czech Republic
url: www.highegg.matfyz.cz