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
_______________________________________________
Clfs-dev mailing list
[email protected]
http://lists.cross-lfs.org/listinfo.cgi/clfs-dev-cross-lfs.org
