[Clfs-support] clfs-embedded: release schedule.

[Andrew Bradford]

Hi,

On 04/30 11:41, akhiezer wrote:
> Hi,
> 
> 
> CLFS-Embedded should aim for a concrete, versioned, release in, say,
> October/November 2017 .

I'd love to do a 1.0 release, but this will require still quite a bit of
work on the clfs-embedded book.  There's a decent amount of bugs in trac
and points in the book which say something like "please fill this in"
which first will need attention.

So, once this is all addressed, sure, we could do a 1.0.

> It can - should - be independent of (if any)
> sysvinit/systemd/... releases/versions; this is not least as there is
> currently insufficient person-hours able to be allocated to clfs to have
> all variants released in sync - if released at all as concrete versions.

The clfs-embedded book has, afaik, always used busybox's init system
like it does today.  Switching to anything else will take considerable
effort and is unlikely to be worthwhile since the main clfs book already
covers use of systemd and sysvinit pretty well.

> It (the clfs-embedded release) should only cover tested - and stated
> explicitly - architectures/hardware - e.g. x86_64, x86, arm/rpi2 .
> 
> 
> It should include concrete, integrated bootloader page for the relevant
> arch/hw - e.g. syslinux - instead of referring to wiki. The present
> bootloader overview should be retained.

For both of these, what I'm more interested in being able to use QEMU to
boot the various "boards" and to provide instructions whose default
<screen> values match up to the intended "board" which QEMU will
emulate, so that JHALFS could be used and so that people can follow the
book without having to actually buy any hardware.  This will also make
testing of book changes via JHALFS and QEMU booting a much shorter cycle
for iterating on the book.

Sometimes hardware goes end of life or is hard to buy or is simply
expensive, being able to give the instructions directly for a QEMU
"machine" but still have notes and tips on how to deviate for common
real hardware like Raspberry Pi or BeagleBone is where I see a decent
direction being for the clfs-embedded book.

> It should include static networking config option, as well as the
> present dhcp option.

Sure.  That's reasonable.

> It 'ideally' (...) should be able to build ok with jhalfs. (Cf thread
> on alfs-discuss list Jan 2017).

Yes, I agree, see above, as today we have too many things where the user
has to make a choice from a/many tables and insert things into some of
the <screen> sections, which I believe makes JHALFS not possible, yet.

> It is noted that the 'bradfa' repo is and has been for a while, the de
> facto main repo:
> ==
> * Main repo:
>     via: http://git.clfs.org/
> * bradfa:
>     via: https://github.com/bradfa/ :
>       ** https://github.com/bradfa/clfs-embedded
>       ** https://github.com/bradfa/clfs-embedded-bootscripts
> ==

No.  Sorry for the confusion.  My (I'm bradfa) github is not the defacto
main repo.  The main repo for the clfs-embedded book and the bootscripts
has always been hosted by the project itself [1].

[1]: http://git.clfs.org/

My github is just where I work on things and then I send a pull request
to the clfs-dev list to have someone else review my changes and pull
them into the main clfs.org based git repo master branch.

> It is noted that it is intended that there _will_ be an os release this
> year that is, or is based-off, clfs/musl/busybox .

I'd love to but it will all depend on how much free time I and others
can dedicate to the project.

If you find something which needs to be updated/fixed/changed/whatever
please do send patches or pull requests or just emails saying what needs
to change and I (or someone else) will get to them as soon as we can.

The CLFS embedded book has always had a skeleton crew of developers
working on it, and sometimes even no one actively working on it.  It's
all volunteer effort so please be patient.  Any help you can provide
will be very welcomed!

Thanks,
Andrew