Yes On Mar 7, 2017 3:57 PM, "Pierre Labastie" <[email protected]> wrote:
> Hi, > The last stable version of jhalfs dates back 2009. The SVN version has de > facto become the only usable one on latest versions of the book. > Having a rolling release is nice, but it prevents big changes to be done, > because each revision should just run "as usual". However, making big > changes may be interesting sometimes, to implement new features, or > changing the design of some parts to ease maintenance, etc. In order to > render possible development without depriving users from their usual tool, > the solution is to make a stable release. Then development could be going > forward along the following lines: > - always generate test instructions, but comment them out a according to > the menu settings: suppose you want to just run the tests for a problematic > package, but you do not want to run the long glibc, gcc, autotool, perl... > tests. Right now, it is almost impossible: you'd have to enable all tests, > and then comment out the ones you do not want in the scripts. If instead > you can generate all tests already commented out, you would just have to > enable the tests you want. Of course, the various existing options would > remain: all tests commented out, all but critical tests commented out, only > chapter 5 tests commented out, or no test commented out... > - refactor lfs.xsl with more named templates (equivalent to functions in > .xsl), so that modifying and/or maintaining is easier: right now this > stylesheet is a spaghetti soup, with duplicate code, convoluted <xsl:when> > alternatives, and so on. > - introduce a way to update LFS without rebuilding everything (except > maybe for some packages like glibc). Needs information on what version is > installed and whether there is a newer version. > - if we have a stable version somewhere, we could even remove some parts > of the code, which are for supporting old books... > > So I propose to work towards releasing a stable version with what we have > now. Let's say it would be 2.4, with bugfixes and backports from > development coming as 2.4.1, 2.4.2, etc. > > For doing so, I guess it would be better to update dpkg and pacman > versions, with hopefully not too many other changes. This could be done > within the next days. But feel free to comment on what should be done > before that. > > Then, unless it comes out that it is more difficult than anticipated, tag > a 2.4-rc1, next week, say on Wednesday 15th, and have people test as much > as they can... > > Then make the release, say fifteen days later or so. > > Thoughts? > > Regards, > Pierre > > > -- > http://lists.linuxfromscratch.org/listinfo/alfs-discuss > FAQ: http://www.linuxfromscratch.org/faq/ > Unsubscribe: See the above information page >
-- http://lists.linuxfromscratch.org/listinfo/alfs-discuss FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
