Mirror problem

[Rob Landley]

On Wednesday 01 March 2006 9:57 pm, Nathanael D. Noblet wrote:
> On Wed, 2006-03-01 at 19:39 -0600, Michael Miller wrote:
> > Hmm, right you are.  The snapshots have the fix but the release does not.
> > Given that the release is over a year old, maybe it's time for a new
> > release.  Maybe after the BusyBox 1.1.1 release.
>
> Not that I'm authorative on this, but every time this comes up they
> inform the questioner that they won't be doing releases. It makes sense
> as to why they don't. On the other hand it would be nice to have a
> stable working copy.

Erik said this in an email to me:

> > 3) Is buildroot ever going to have an official release? :)
>
> It definately needs one...

February 14, 2006.  12:53 am.  And I'm holding him to it.

I haven't brought it up because I haven't gotten busybox 1.1.1 out yet 
(!grasshouse->throw(stone[])), but I'm down to two blocking issues and I'm 
fixing one of them now, and the other's mainly code review.

(You may notice my sneaky early strategic move on this in svn 14100, about 
which I deny all knowledge and ooh look, over there!)

In the longer term, I have a number of cake mixes, and am not afraid to use 
them...

> I've actually been wondering about the whole thing and think instead of
> releasing buildroot, there should simply be a way to create stable
> configs. So combination of packages & their versions which work
> together. So creating something that will allow people to contribute
> a .config that builds X,Y & Z and is known to work. I think there are
> really only two things that need to happen to buildroot to make it
> possible.
>
> 1) Patch buildroot to be able to specify particular configs. This is
> somewhat possible with how make works, but making it more integrated
> perhaps by creating a config directory for storing them, and adding the
> ability to browse the configs to choose which one to use straight from
> make menuconfig.
>
> 2) Modify packages .mk / conf files to be able to specify the exact
> version instead of hardcoding them in the makefiles. Thus allowing the
> building of arbitrary package version combinations.

You still want to have releases, because you want known good reference points 
you can point people at and go "start here".

Development breaks stuff.  It's unavoidable.  Nobody's first experience with a 
project should be "grab today's svn snapshot and hope".

Rob
-- 
Never bet against the cheap plastic solution.