Discussion:
[Clfs-support] clfs-embedded: release schedule.
akhiezer
2017-04-30 10:41:13 UTC
Permalink
==
To: clfs-***@lists.clfs.org
Cc: alfs-***@lists.linuxfromscratch.org,
lfs-***@lists.linuxfromscratch.org
==


Hi,


CLFS-Embedded should aim for a concrete, versioned, release in, say,
October/November 2017 .


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.


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.


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


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


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
==


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 .


Views ...



akh





--
Andrew Bradford
2017-05-01 15:08:05 UTC
Permalink
Hi,
Post by akhiezer
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.
Post by akhiezer
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.
Post by akhiezer
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.
Post by akhiezer
It should include static networking config option, as well as the
present dhcp option.
Sure. That's reasonable.
Post by akhiezer
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.
Post by akhiezer
It is noted that the 'bradfa' repo is and has been for a while, the de
==
via: http://git.clfs.org/
** 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.
Post by akhiezer
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

Loading...