Hi,
I'd suggest that the best way forward from here, is to pick a released
LFS version, base a BLFS version off of it, and release the completed
BLFS version within 18 months of the LFS release.
For example, LFS-6.7 was released on 18/Sept/2010: can BLFS-6.7 be
released by 18/Mar/2012 ?
If in practice 'BLFS-6.7' can't be based exactly off LFS-6.7, but
instead needs some adjustment (say, a minor version of perl - just for
example), then by all means do so, and call the release 'BLFS-6.7.1'
(or similar); and include a section at the start of the released BLFS
book, detailing the what/why/&c of the adjustment. *NB* that the
adjustment need not necessarily be backported or otherwise applied to
LFS itself: i.e. there's no essential need to release LFS-6.7.1 - don't
get hidebound.
During said development period of BLFS-6.7, there will of course be LFS
releases further to LFS-6.7, namely LFS-6.8 (4/Mar/2011), LFS-7.0 (early
Sept 2011), and perhaps also LFS-7.1 (early March 2012). *But*, there's
no essential need for BLFS-6.7 to try to keep up with and incorporate
anything from LFS-6.8 et seq: you're aiming to release BLFS-6.7(.x) -
not BLFS-6.8(.x), etc; again, don't be/get hidebound.
After BLFS-6.7(.x) is released, the focus can shift to the next BLFS
version. Which does not necessarily need to be 'BLFS-6.8' based off
LFS-6.8 . Instead, the BLFS folks would decide what next version of
LFS (subsequent to LFS-6.7) would be the best one to use as a basis.
They might decide to base off LFS-7.0 (released Sept 2011), and so work
to a release of BLFS-7.0 by March 2013.
Naturally there will be folks who, while BLFS-(dev-)6.7(.x) is in the
works, would prefer to develop their BLFS based on LFS-6.8 or LFS-7.0 .
How could such work be accomodated and carried forward and later
folded into the (in the example) main BLFS-7.0 development, when the
latter begins formally? I think it's an issue that needn't be a hold-up
to the above-proposed way forward. However, some very-summary pros/cons
thoughts on this for now are:
----
* It may accomodate antipathetic groups of folks - some working on
BLFS-(dev-)6.7 and at the same time others on BLFS-(dev-)6.8 (which in
the example above may end up later transmogrifying/subsuming into
BLFS-(dev-)7.0).
* Structural changes to the book &/or package addition/deletion - as
opposed to 'just' updated package versions and commands - might need
co-ordinating as a continous process, &/or as a sort-of once-off 'merge'
after BLFS-6.7 is released and we are ready to move onto the next
formal, main BLFS dev version.
* Mailing lists might get a bit messy: I'd say keep a single (e.g.)
blfs-dev mailing list: but might be a bit onerous to mark/track what
applies to BLFS-(dev-)6.7 work, and what applies to the parallel
BLFS-(dev-)6.8/7.0 work.
* Having two (or three) parallel strands on the go, might just end up
in 'forking Balkanisation'.
----
Some misc points on other items that have cropped up in various other
posts:
====
* the 'works with LFS 6.x' entries in BLFS pages: such info is really
just flattening (parts of) several branches, down into the main one -
but without proper merging or branching or so. It's a bit crappy. And,
the info is ii{r/ui}c not really as valuable as purported: for, many of
the packages depend on stuff from BLFS, not just LFS.
* wiki: I'd say really, _really_, avoid going the wiki route: for, BLFS
needs to be (semi-)linear, authoritative, self-consistent (not
self-contradictory), coherent, concise, refined/polished (not
dumped-&-left), usable, materials being signposted well, &c&c&c. Wikis
have their place - but not for something like BLFS.
* change tracking: git >> svn > cvs. (Just my opinion - tho' it happens
to be correct ;). But again, the tool used needn't be a showstopper
hold-up for getting BLFS-6.7 &c released.
* releases or just rolling-dev-snapshots: I'd say definitely go for
releases - and properly-numbered ones at that (no Dotzlery here, please).
If you just have rolling-dev-snapshots, then how can you convince folks
that the work is _sufficiently_ tried'n'tested (& stood-behind, etc)
that they can then make the calculation that it _is_ OK for themselves
to go ahead and invest their time/resources in basing work/effort/&c off
it? Most end-user folks don't know the material in sufficent detail, to
be able to determine which particular snapshot is a 'good-un' that they
can use as a basis: whereas a properly-done release, typically carries
quite a lot more weight on that matter. If one just produces an
ever-moving pile, then in practice it usually just becomes an area for
onesself and an ever-decreasing circle of others.
* /opt : leave it in. I recall when it first appeared - in Solaris, at
least. Always seemed an ugly bolt-on. Folks (e.g. DJ?) often use it for
testing/compartmentalising - but still get leaks into rest of sys tree.
And, usually sounds like it's really another problem that they're trying
to address: but, /opt may give a readily-accessible stop-gap solution
_now_.
* multiple books: I'd say leave as a single book, released as a single
entity. If necessary, add a section/chapter detailing what set of
packages to use for respectively server/cmdline/gui/desktop/&c. Multiple
books has all sorts of grotesque practical problems, for both developers
and end-users - mailing lists, duplication, inconsistencies,
poorly-chosen borderlines, & so on. The vast majority of BLFS users, can
determine a thread through a single book - moreso if said additional
section/chapter was added.
====
To return to the main topic:
LFS currently can be both bleeding edge and educational: BLFS currently
cannot be both. It seems sometimes that BLFS goes into bursts of
"bleeding-edge over educational" mode; and so the book remains at
svn-snapshot rather than the _overall_ _more_ educationally useful
release version.
With the above proposed way forward, BLFS can be educational and
still-fairly-cutting-edge. And who knows, in time perhaps the 18 months
may sometimes hit the 14- or 12- or 15- month marks instead.
hth,
akh
p.s. Apols if/that this message breaks the threading: have only
newly-subscribed, don't have the earlier mailing-list messages in the
mail client here, and it seemingly won't let me hack the
'In-Reply-To: '/References headers.
--
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
