Roadmap update

Bill's LFS Login lfsbill at
Thu Jan 29 09:03:25 PST 2004

On Thu, 29 Jan 2004, Gerard Beekmans wrote:

> On Thu, 2004-01-29 at 07:40, Bill Maltby, LFS Organizational wrote:
> > If we make a concerted effort to make the wiki errata current and useful
> > with things such as this, and add emphasis in the book(s) directing the
> > user to check the errata area of the wiki, would this meet the need?
> > Drawback is that the user needs to check a couple more places to see if
> > security (or other issues) require changes from his base book. Also, we
> > would need to able to count on somebody to keep the stuff current (can't
> > rely on the user because he has no commitment to the project).
> I wonder if it's truly a viable solution, an errata.

See my post to Billy's post. As to it's viability, *if* various types of
*concise* updates to a release are *reliably* available, it is much more
"user friendly" than a new book (CVS extract) diff against a previous
version (assuming one is available). If the previous version is paper,
the diff becomes a manual operation and the wiki should have huge
advantages for the end user. From that POV, errata *should* be very

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.

> CVS pretty much *is* the errate. Any bugs found are fixed there, daily
> snapshots provided for user convenience. A version specific errata has
> its uses but we'll duplicate work but I think we'll just end copy and
> pasting from our CVS fix into that errata.

My suggestion would not include that. I look to relieve the editors *if*
the wiki-based tools come into more extensive use. Yes, CnP might still
be the result, but pure end-user support, which this is, should not be
a *major* function of the editors. As in my other post, I would recruit
some folks who see the value in the wiki errata and would therefore be
willing to commit to provide that service. Developers who do *not* see
that value should *not* be asked to do it.

> Maybe we'll even get to a
> point saying in such errate "this issue has come up and has been fixed
> in CVS, check

I can only see a couple potential issues with that. "Unstable
development ..." (the user might break when we told him to go there and
get a *fix*) and for support issues, what version is the user on. Having
a "release", with possible updates, seems to me to be easier to identify
than a continuously changing (and therefore *not* burned into our
brains) CVS timestamp.

I guess that a direction to the user on support might be something like

  get CVS 2004-01-29 after 13:26 UTC, but before 23:13 UTC (introduced a
  breakage), or 2004-01-30 03:05 or later which fixed the breakage ...

or did I misunderstand something? Yes, I'm overstating the situation
there! ;) I guess a tag (the point release one) would suffice.

Does this cause any monthly bandwidth usage issues that might not occur
if other methods are used?

> I'm not saying this will be, but I can see it happening because it's the
> easiest way to do things and often CVS is perfectly usable too at that.
> That also brings up the point why not use CVS all the time and even have
> a stable release.

For most of my background, SCCS/RCS/CVS served the *developers*, not the
end users (re component releases). This was for good reason. Without
going into the same args we recently saw on the glibc thingy, I would
just think carefully before going down this road. All the negatives,
AFAICT, center around support issues.

NOTE: I'm on a new ISP, if I'm in your address book ...
Bill Maltby
Fix line above & use it to mail me direct.

More information about the lfs-dev mailing list