Roadmap update

Bill's LFS Login lfsbill at nospam.dot
Thu Jan 29 08:01:43 PST 2004


On Thu, 29 Jan 2004, Billy O'Connor wrote:

> "Bill Maltby, LFS Organizational" <bill at nospam.dot> writes:
>
> >> But we still recommend that people use the stable version of the
> >> book, so what does it matter if we have a "one off" version from cvs
> >> that has some update or other?  IOW, the "responsible" version of the
> >> book wouldn't be recommended for use, what good does that do us?
> >
> > Maybe this can be addressed with a slightly different tack? There were
> > suggestions in the past about use of the wiki for errata. ISTM that
> > security issues *do* justify a point release, but that has effects we
> > would like to avoid (work load and related activities being driven by
> > asynchronous events may ruin any attempts at scheduling and sticking to
> > the roadmap).
> >
> > 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).
>
> This "concerted effort" sounds like more work than a point release,
> not to mention the fact that wiki's aren't trustworthy enough for
> security update information.

I've seen Gerard's other post about using CVS, but I ignore that for the
moment.

It may be more work (I don't think so, though, at first glance), but it
has the advantage for the *editors* (maybe test team too?) that:
  - the work is planned for;
  - is done on a continuous basis (reduces "spikes" driven by these
    outside events);
  - so it generally "smoothes" things;
  - allows us to avoid, IIUC, having to duplicate updates (current work
    area - head? - and how many previous versions);
  - avoids all the other steps needed to publish the book (formatting,
    tagging, testing, announcing, posting on the website, ...);
  - we don't have to test the stuff;
  - the editors (and others) retain maximum flexibility in their use of
    CVS because they needn't be concerned with issues beyond what they
    currently consider.

This is based on a tentative strategy of having a few folks (not
necessarily the editors) that track these sorts of things, consult with
editors and others, if needed, and then do the update to the wiki.
I think there may be many folks willing to help in this way. Users of
the area could contribute results of using book commands, whther changes
to commands were needed (or the editors could pass this on to the wiki
folks *whenever* they stumbled across needed changes).

One requirement on the wiki would be a large notification of what has
been tested and what has not. Otherwise, it is more like the current CVS
usage and we essentially gain little.

This would need much more consideration to see if it truly feasible, and
then if it is reasonable for whatever it buys us.

Your security issue is certainly valid. But, IIUC, that is because all
areas are open to update by anybody. IIUC, that was an implementation
choice, not a requirement of the wiki. I envision that some adjustments
in the configuration, or the way we operate it, would allow the security
we need for this stuff while still offering the user benefits originally
envisioned. Nicholas would be the one to check with I think.

> Also, this puts the onus on the reader to check the wiki for errata,

I'm all for users being responsible for their own activities. If LFS is
not about enabling them to learn to do that stuff, along with the more
formal objectives, what is LFS about?

> may as well tell people to check the cvs version of the book if that's
> the case.

If we presume that CVS is unstable development only, I would think this
is not a good thing for less experienced users. Of course it has *many*
fixes, but it also has (potentially) many errors in untested text,
commands and packages.

I can't imagine sending a user to CVS for a security fix and having his
build (or operation) break as a result of following that recommendation.

During the writing of this, it also occured to me that maybe we don't
need to do *anything* other than make more effective use of
lfs-security. 1) If we annonunce on security, do we need to do anything
more concerning an already released version? 2) Do we need to have a
more-or-less permanent news" item on the website home page that mentions
when security are announced for various releases and directs the user to
the security list (or some subset)?

Thinking of all this leads me to say that we don't need to do much more
than use lfs-security effectively and (maybe) a little adjustment to the
book and website text that *strongly* advises the user that he
is responsible for following up on security issues?

We don't babysit, we help folks get started towards independence.

>
> --
> Billy
> LFS Unassigned
>
>

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



More information about the lfs-dev mailing list