[syslinux] Syslinux-5.00-pre8

[Ady]

Subject:        	Re: [syslinux] Syslinux-5.00-pre8
From:           	Matt Fleming <matt at console-pimps.org>
Date sent:      	Wed, 10 Oct 2012 09:39:03 +0100

> On Tue, 2012-10-09 at 23:56 +0200, Ady wrote:
> > FWIW,
> > 
> > Since there are known bugs and issues that are going to be addressed 
> > only after 4.06, why the rush?
> 
> We are way, way behind on the release cycles. And in fact, there's
> already enough new material for a 6.0 release. The "rush" comes from the
> fact that I really want to get an Syslinux EFI prerelease (Syslinux 6.0)
> out there for people to test and trying to manage 3 releases
> simultaneously would be an absolute nightmare. Consumer hardware with
> EFI is becoming increasingly common and Syslinux *needs* EFI support.
> 
> Ideally I'd like to stabilise 4.06 and move all new development to 5.00.
> We'll see how easy that is.
> 

Matt,

I'd like to express my opinion about this.

I didn't know there was a release cycle, specially giving the 
relatively few responses to bug reports this last year. (I'm not 
complaining; just stating a fact.)

But a theoretical release cycle means nothing if a "stable" release 
is not really stable. If you already know about core bugs (which in 
part have been reported in the past), and you want users to provide 
feedback, then for that goal the prereleases should be enough. There 
is no need to send out a "stable" version just for that.

Moreover, if distros are going to "waste" time updating to some 
"unfinished" stable version, then the reaction could backfire, with 
users and maintainers thinking that Syslinux may not be worth to be 
used if it is not really stable or usable as it should be.

I'm not being completely balanced in my previous statements. The 
situation is not such a complete catastrophe, but I am just trying to 
make a point. Some known bugs are not "an edge case", but part of the 
most used features.


> > My guess is that potential issues might be reported after 4.06, by 
> > users that have been patiently waiting since 4.05. If you release 
> > more than one branch almost simultaneously (specially a round version 
> > number), then the first reply to many emails and posts will probably 
> > be:
> >  "which version?"
> >  "have you updated all the com32 modules too?"
> > and things of that sort.
> 
> Yes, this is a valid point. However the above questions generally get
> asked for every bug report anyway. I rather suspect that lots of users
> will stick with the 4.06 even after 5.00 drops. Whereas developers and
> people who want to try out the latest features are more likely to test
> 5.00.
> 

Really? I disagree. Users tend to think that between 2 "stable" 
versions, the one with a higher number is "better". The common user 
will usually go back to a previous version only after being 
disappointed with the "latest stable" version (and we could mention 
as an example other boot loaders or boot managers with such 
controversial reputation, with discussions about pros and cons of 
each version or each branch going on for years).

Regarding developers or package maintainers, why should they invest 
time to choose between different versions or branches? That's for the 
Syslinux developers, and for no-one else.


> Linux distributions, for example, are unlikely to pickup 5.00 this year,
> but if a release is available then people in the Syslinux community are
> more likely to test it. Any community testing that happens will be
> invaluable.
> 

The prereleases are for testing; not the final. If a package 
maintainer in a Linux distro (or anyone else, for that matter) wants 
to test, they should use the "testing" versions, and report feedback. 
A release is a release, not a test. Sending out a "stable final gold 
release" means putting the reputation of the project to the test of 
the users (including individual final users, developers of 'easy 
multi-boot multi-distro' tools, and Linux maintainers). If you are 
going to say "we are releasing a new stable version", you should 
better know it is really stable and complete.

Being forced to release "5.00.1" or "5.01", or "4.06.1" or "4.07" 
after a week (or a month) is not a good practice. If you plan to make 
shorter release cycles, it should be because the development is 
quicker; not because the "stable" release is not really stable (and 
4.06 isn't complete yet IMHO).

> > As a user, I wish to see some old bugs finally resolved, and 
> > potential new bugs (introduced by the soon-to-be-released 4.06) 
> > ironed out (no to mention some improvements). I fear releasing 5.00 
> > so close to 4.06 could make it harder.
> > 
> > Just a thought.
> 
> This is a reasonable thought.
> 
> Bugs that are newly introduced in 4.06 *will* be ironed out. There is no
> question of that. If people see regressions in their setups between 4.05
> and 4.06 then they obviously need fixing. The 4.06 release will not be
> abandoned as soon as it's out, if people are having issues with it they
> will be resolved. Regressions are the highest of priorities.
> 
> However, that's not to say that we should try cramming lots of new
> features in or fix every single bug ever reported before we release 4.06
> - it's a judgement call.
> 
> -- 
> Matt Fleming, Intel Open Source Technology Center
> 
> 

You as (the) developer might want to define "branches", "versions", 
"release cycles" and more. The final user don't, and don't even care. 
"5.00 is better than 4.06".

If you don't want to maintain several branches at the same time, and 
you want more and quicker feedback, then release one (really) stable 
version at a time; get the feedback and act on bug reports ASAP.

For whichever reasons, it seems 2012 was relatively slow on 
development when comparing to bug reports and user's needs (I'm not 
complaining). Releasing versions with unfinished features or known 
bugs that were reported more than once long ago won't make it better.

Several projects are already using 4.06pre7, just because until pre11 
(included) the Windows-based installers were broken. Keep releasing 
useful prereleases and acknowledging the (several months old) bug 
reports and the final release will be worth. Patch ASAP, that's how 
you get more feedback and shorter cycles.

Test, baby, test! Patch, baby, patch!!! But do it in the prereleases.

Best Regards,
Ady.