[syslinux] Syslinux-5.00-pre8

[Matt Fleming]

On Wed, 2012-10-10 at 12:26 +0200, Ady wrote:
> Matt,
> 
> I'd like to express my opinion about this.

Sure, feel free.

> 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.)

OK, perhaps "release cycle" was a poor choice of words, since that
implies that there is a specific period of time between releases. AFAIK,
the Syslinux project doesn't have a release cycle. The point I was
trying to make was that there are new features pending and it only makes
sense to merge them as part of a new release. EFI support is the big
one. So when I said "We are way, way behind on the release cycles" I
meant that 4.06 needs to be released so that we can move on to
developing newer versions with new features and a corresponding bump in
the version major number.

> 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.

OK, let's clear some things up here. I do not know of any core bugs
apart from the NTFS issue that Paulo and Shao are working on, and it
seems likely that I'll hold off on 4.06 final until that issue is
resolved. If anyone knows of any core bugs that I've overlooked, please
speak up. I should probably be clearer with my emails but everytime I've
mentioned the 4.06 final release I've always used words like "aiming",
"hoping" when referring to getting the release finished. Obviously I'm
not going to cut a final release with large changes like the NTFS patch
and no testing. However, I do want to keep the momentum going so that we
can do the final release as soon as it's ready.

But I would not say that 4.06-pre12 is in any way unstable. Missing
features do not make a release unstable. But again, if there's some
report that I'm missing please someone point it out.

> 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.

Let's be fair, the above is a bit of an exaggeration. I've no reason to
believe that 4.06 will an unstable release.

> > > 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).

I have tried to be clear when speaking of 5.00 as containing many new
features and rewriting a lot of the core code. Anyone familiar with
software version schemes should realise that incrementing the version
major number (from 4 to 5) comes with a certain level of risk because of
the fact that lots of code will have changed.

Again, that's not to say that I think 5.00 will be in any way unstable,
I don't. It's just that the *potential* for instability is greater when
moving from one major release to another.

> 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.

That is what package maintainers *do*. Developers more than anyone
should understand which version suits their needs best.

> > 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.

You are throwing the word "stable" around a bit too much. Why do you
think we'll be releasing an incomplete or unstable Syslinux version?

There is only so much testing that people will do with the prereleases.
It is invaluable testing, that's for sure and it turns up lots of bugs.
But it's when people deploy a release in their running environment that
the really obscure bugs turn up. A final release of 5.00 will get people
to actually deploy and *use* it - that's the benefit that a final
release has over prereleases.

> 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).

Please give details why you think it isn't complete.

-- 
Matt Fleming, Intel Open Source Technology Center