Roadmap update

Bill Maltby, LFS Organizational bill at nospam.dot
Thu Jan 29 06:40:33 PST 2004


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

> Ronald Hummelink <maillist at hummelink.xs4all.nl> writes:
>
> >> Also, a while back we discussed the frequency of releases and every 2 to
> >> 3 months seemed to be a good number which will allow enough time to
> >> properly test it and make sure it's solid. It won't be bleeding edge,
> >> ever. That is what CVS is for.
> >
> > I think the release of the book should be much sooner if (high profile)
> > vulnerabilities become known (Like the kernel last time). Only has to be
> > a teeny version bump with maybe just 1 package upgrade, but imho that is
> > the responsible thing to do.
>
> 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).

>
> --
> Billy
> LFS Unassigned
>

-- 
Bill Maltby,
LFS Organizational
billATlinuxfromscratchDOTorg
Use fixed above line to mail me direct



More information about the lfs-dev mailing list