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
