Roadmap update

Archaic archaic at indy.rr.com
Thu Jan 29 12:26:39 PST 2004


On Thu, Jan 29, 2004 at 12:03:25PM -0500, Bill's LFS Login wrote:
> 
> I have my doubts about its viability just because of the lack of support
> for the wiki. Since facilities should generally meet the needs and
> desires of users and/or developers, the wiki is only viable if one or
> more of these groups want it. Most developers seem to be, at best,
> apathetic about it. Feedback from user's has been almost non-existent.

I've always kept silent on the wiki, but it would seem that people share
my view that the wiki is nothing more than a hassle for most things. To
the developer, he now has to worry about doing twice the work (or
getting someone else to do it for him), and the user has to look in more
places. IMO, any change in the book needs to be directly stated in the
book. If the idea of errata is taken, that means taking a stable release
and plastering in big bold letters that there is errata known. Also, I
think a big bold announcement on the main (news) page of the webserver.
I ask myself the question, if there is news, why can I not get it from
email. Why should there be developmental things discussed in the wiki,
but not in the mailing list? I spend a good deal of time just trying to
keep up with things of interest. I've long ago had to drop reading
lfs-support and I don't like that, but I just don't have the time, so
why would I want to commit to constantly checking out the wiki?

Now, as far as patchlevel releases, there is generally nothing in a
bugfixed version of a package that requires extensive testing.
Basically, one could check that the files installed equal the same
before and after the bugfix, and perhaps do a build of everything after
that package just for a quick confirmation of buildability. Obviously a
kernel or toolchain bugfix would all but require a full build, but
again, this should be scripted by the testers at this point and with
bugfix releases being only for the most critical stuff and not likely to
change any ABI's or anything major, all we need to do is have but one
tester say "it builds, and package X installs the same files in the same
places as before". Done. Generate and release. Then, when we recommend
to use stable versions, we are accurate and safe. As far as having to
diff, only one thing (possibly 2) should have to change. The version,
and possibly the install procedure for the one package in question. That
can be done manually faster that automated since it's such a tiny,
restricted change.

In conclusion, I think continuing to discuss development issues on the
wiki actually cost more time than it would take to just make a patch
release.

And since this is a roadmap thread, I would like to pose to Gerard that
since *many* of us have, will, or currently are building production-type
or at least stablilty-necessary machines, we should consider keeping the
5.x branch alive (at least in package updates) until the 2.6 kernel
matures. I'm guessing around 2.6.12 going by when people in large
numbers starting migrating to 2.4 from 2.2). Of course, that may mean
using an older toolchain (much like we do for building the kernel) if
the toolchain packages should make a make a major upgrade. That leaves
us off having to expend too much time on the then-secondary 5.x branch
(unless enough people clamor for it and it's deemed worthing of active
maintenance).

Comments? Opinions?

-- 
Archaic

You [should] not examine legislation in the light of the benefits it
will convey if properly administered, but in the light of the wrongs it
would do and the harm it would cause if improperly administered

- Lyndon Johnson, former President of the U.S.




More information about the lfs-dev mailing list