[syslinux] Syslinux-5.00-pre8

[Jeffrey Hutzelman]

On Wed, 2012-10-10 at 14:21 +0200, Ady wrote:

> The most important feature (in user's eyes) is the NTFS support. My 
> previous impression was that the fragmented MFT case was being 
> considered as an "edge case". IMHO, it is a frequent case.

I consider myself a fairly extensive "user" of syslinux.  I maintain a
PXE infrastructure with a moderately complex system of menus leading to
several versions of installers for each of perhaps a dozen Linux
distributions, plus other operating systems, BIOS upgrades (mostly
DOS-based floppy images booted with MEMDISK), and various diagnostic
tools.  I wrote PXECHAIN.COM for that purpose(*).  I build versions of
these installers and other tools that boot from CD-ROM or USB flash
storage.  I also maintain part of a mechanism that automates the
installation of dual-boot Windows/Linux systems, by chaining from MDT to
the desired Linux install process by means of a small disk partition
containing SYSLINUX, put there by the Windows system near the end of its
install process.

I care not at all about NTFS support.

I _do_ care about EFI.  I certainly care that Syslinux, in all its
variations, continues to work properly on the widest variety of machines
and BIOS versions, without special handholding, because the tools I
maintain have to Just Work on whatever hardware our engineers throw at
it, which means whatever the users buy.



I also care a lot about stability.  But here I don't mean that
individual releases are "stable" as in "seem to work pretty well".  In
software release engineering, stability means not changing too quickly,
and especially, not gratuitously introducing new features into what are
supposed to be relatively minor releases, and especially not requiring
people to pick up large, complicated new features in order to get fixes
to existing problems.

That means that when deciding what to fold into a release, it's not
enough to consider how "important" a feature is or how much people claim
to want it.  One also needs to consider how large, complex, and invasive
it is, how likely it is to affect things that should be unrelated, how
serious the effects of a problem might be, and also how "stable" the
release series is supposed to be.

It also means that sometimes, especially in a "stable" release series,
you do a release which fixes some existing problems but not all of them,
because the alternative is waiting for a moment in time when there are
no known bugs at all, which may not happen anytime soon (or ever).
Fixing some problems is better than fixing none, and in a stable release
series, avoiding introducing _new_ problems is usually considered to be
more important than fixing old ones or introducing new features.

So, it's entirely appropriate to release 4.06 with known problems, if
those are problems that already existed in previous releases and are not
trivially fixed.  It's also appropriate to refuse to incorporate complex
changes close to the targeted release date, even when the change is
desirable.  And, if 4.x is supposed to be a "stable" release series,
it's also entirely appropriate to say "that feature can go into 5.00,
but it's too major to go into 4.x ever".


-- Jeff


(*) I have nothing to do with pxechn.c32, except that Gene has my
blessing and thanks for obsoleting pxechain.com with something more
general, more robust, and probably more maintainable.