[Clfs-dev] Embedded Pull Request

[Andrew Bradford]

On 11/10/13 14:30, Rob Landley wrote:
> On 11/05/2013 07:45:44 AM, Andrew Bradford wrote:
>> Dear Rob,
>>
>> On 11/05/13 07:35, Rob Landley wrote:
>> > On 10/17/2013 03:19:16 PM, Andrew Bradford wrote:
>> >> Lots of cleaning up, few little fixes for errors others pointed out
>> >> yesterday and today.
>> >>
>> >> The biggest change that might piss off the build tools is the
>> removal of
>> >> the version number from the book.  We're not going to do a 1.0 release
>> >> for embedded, let's just use the date code as that's easy to search
>> for
>> >> in git.  Rolling releases are popular these days :)
>> >
>> > Not so much "piss people off" as "cause me, personally, to lose all
>> > interest in your project".
>>
>> I'm sorry to lose your following.
>>
>> However, the embedded book has, since November 2006, been at version
>> 0.0.1.
> 
> And I paid zero attention to it during that time, until recent movement
> in the direction of musl caught my notice.
> 
> I already _have_ a build that combines busybox and uClibc to create a
> self-hosting development environment based on just 7 packages. I rewrote
> about 1/3 of busybox to make that happen, fixed bugs in the kernel and
> qemu to make it work on multiple platforms, and so on. I don't actually
> _need_ the embedded LFS book, but I've had a vague todo item of turning
> my giant bash script into an LFS-style book forever because teaching
> other people how to do this stuff is good, and having an existing
> project already do it _for_ me means I don't have to. I would much
> rather help out somebody _else's_ project than take on another thing of
> my own, because my todo list runneth over.
> 
> By the way, that above build environment? I'm working on a release for
> it right now. (Linux 3.12 dropped, so I need a new aboriginal release
> including it, and _that_ means I should cut a new toybox release so it
> can use it, and I have pending patch submissions in the accumulated pile
> of unread email and half-finished things I need to either finish or bump
> to the next release, and I need to write up release notes and regression
> test everything across all the supported targets...)
> 
>> This has never changed and after 7 years it seems silly to keep
>> a version string that hasn't changed and which I have no intention of
>> changing any time soon.
> 
> I only started paying attention to BLFS again when they finally had a
> release recently.
> 
> Releases are important for an awful lot of reasons. It's a known
> synchronization point where everybody trying it sees the same behavior.
> One that the maintainers actually specifically tested and inspected, not
> just "cron job says it's ok" but one you know a human actually looked
> at. One that won't have changed out from under you if you go back and
> try to reproduce it next week on a different machine. Releases allow you
> to make statements of the form "this one does this, that one doesn't".
> More than one person tried it on more than one Distro. We had at least
> an informal freeze period where we didn't introduce anything potentially
> destabilizing for a bit before we cut this version to make sure people
> other than us wouldn't be surprised when they tried it.
> 
> The superiority of time-based releases over "when it's done" releases is
> described in detail in this google tech talk from an ex-Debian
> maintainer who learned it by watching the kernel and projects that
> immitated it:
> 
>   http://www.youtube.com/watch?v=IKsQsxubuAA
> 
> The superiority of having releases at all over "grab the git du jour,
> I'm sure it's ok, there's never any cleanup to do because every commit
> is always perfect and problems introduced are always immediately
> apparent and never ever subtle or occuring only for people other than
> the maintainer" is a _bigger_ deal.
> 
>> If a 1.0-type release is done, the version number will come back.  And,
>> if really desired, bringing back the 0.0.1 is as easy as 'git revert'.
> 
> It's not having a number, it's having _releases_. Realizing that they
> serve a purpose.
> 
> Not having releases means the project is not trying to package itself
> for use outside it's own developer community. If you're not part of the
> "in crowd", you're not of interest to the project's developers. It's a
> big red flag saying "What's a user? Can't be bothered." A developer's
> first experience with the project _won't_ be reproducing a known working
> version multiple other humans successfully reproduced from scratch out
> of the box.
> 
> Releases are project hygiene on the level of showering.
> 
> That is why I lost interest.

Thanks for your input.  You make a very good point about releases and
their positive impact on a project, especially from a user's
perspective.  I'll keep this in mind.

Possibly, if someone wants to give some good direction on what to do in
regards to the kernel and bootloader instructions, when musl hits 1.0
and busybox does another release (their git has musl supported without
patches now, iirc) embedded CLFS could have a real 1.0 release.

Thanks,
Andrew