[Clfs-dev] Embedded Pull Request

[Rob Landley]

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.

But as always, it's just my opinion...

Rob