Another prerelease for the 5.00 (elflink) branch should be making its
way to the mirrors now. The shortlog for -pre7 to -pre8 is listed below.
Just like the 4.06 branch I was really hoping to drop a final release
this week. Once 4.06 is out I'll merge that into 5.00.
If you can, please test it out and let know any of any bugs you find.
Because so much of the core infrastructure is rewritten in 5.00 be on
the look out for inconsistencies between it and the 4.X releases.
Thanks!
---
Chandramouli Narayanan (1):
module: Fixed the upper limit in symbol table walk through
Matt Fleming (3):
console: Close stdin, stdout, stderr on ldlinux.c32 unload
extlinux: Handle error case for find_mount()
installers: Install ldlinux.c32 automatically
--
Matt Fleming, Intel Open Source Technology Center
From: Matt Fleming <matt at console-pimps.org> To: syslinux at zytor.com Date sent: Tue, 09 Oct 2012 22:04:39 +0100 Subject: [syslinux] Syslinux-5.00-pre8> Another prerelease for the 5.00 (elflink) branch should be making its > way to the mirrors now. The shortlog for -pre7 to -pre8 is listed below. > > Just like the 4.06 branch I was really hoping to drop a final release > this week. Once 4.06 is out I'll merge that into 5.00. > > If you can, please test it out and let know any of any bugs you find. > Because so much of the core infrastructure is rewritten in 5.00 be on > the look out for inconsistencies between it and the 4.X releases. > > -- > Matt Fleming, Intel Open Source Technology Center >FWIW, Since there are known bugs and issues that are going to be addressed only after 4.06, why the rush? 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. 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. TIA, 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.
Subject: Re: [syslinux] Syslinux-5.00-pre8 Copies to: syslinux at zytor.com Date sent: Wed, 10 Oct 2012 12:48:30 +0100> On Wed, 2012-10-10 at 12:26 +0200, Ady wrote:> 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, 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. A user testing one distro on UFD, then another, then another... would probably get a fragmented MFT at some point. I don't know if the problem presents itself only when installing ldlinux.sys (and then all is fine, no matter what), or if otherwise when the MFT gets to be fragmented the boot process won't work (even when ldlinux.sys was already installed, before the fragmentation started). So, IMHO, that is a (the) core known issue still present for 4.06. Now, if the final release of 4.06 is going to have this issue covered, then that's a very important step. But users that _are_ testing the current prereleases need some time to test and report back. If 4.06 is out this week, I think part of the potential testers of the prereleases won't have such opportunity. But first Paulo and Shao may need some more time to solve the matter. Additionally, having some commonly used directives not working as they should (for so long time), is IMHO also important. I wouldn't consider the problems in submenus or in "menu default" or in their respective (currently wrong) documentation something to keep postponing. But that's just my humble opinion. I can help with testing prereleases or with docs if needed, but not with commits. If you think that it is better to release 4.06, 4.10 and 5.00 close in time, then go head and I'll do what I can to help. I just wanted to express my humble opinion when it may still be relevant. Best Regards, Ady.
Op 9-10-2012 23:04, Matt Fleming schreef:> Just like the 4.06 branch I was really hoping to drop a final release > this week. Once 4.06 is out I'll merge that into 5.00.Hi Matt, the 4.10 branch is dropped when 4.06 (NTFS) and 5.00 (modular?) are merged? Or 4.06 + 4.10 ending up together in 4.11 or 4.20 followed by 5.nn? Best regards, Bernd Blaauw
Date sent: Wed, 10 Oct 2012 12:54:54 -0400 Subject: Re: [syslinux] Syslinux-5.00-pre8> 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. >> > 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 >Jeff, Just to be clear, my comment about users expecting NTFS was only related to 4.06, and in the context of other recent email threads. Regarding a broader context, I also agree that (U)EFI support is much more significant. Regarding old bugs, I am not referring to, for example, display.c32 (which doesn't work since 4.00). But during 2012 some bug reports were not acknowledge, or there was no action to correct them (as I said before, I'm not complaining, just stating a simple fact). I'm more than glad that there is "action" now. I just thought postponing SOME of those "old" bug reports again would be an error in this specific opportunity. Fortunately, it seems they are being taken care now. About testing (U)EFI support in Syslinux, I still think that prereleases are more appropriate. That's their goal. Anyway, I just expressed my concern about releasing more than one version almost simultaneously. Saying something after the fact wouldn't had help anyone :). Whatever Matt decides, I hope for development to pick up and for users to have a "stable" (in the same sense as you described it) usage. Best Regards, Ady.