"Hosts" within tinderbox?

[Ade Lovett]

Anyone else want to chip in on this before I just go ahead and do it?

In a few days or so, my tinderboxes will be finished processing for  
"a while" with the last of my major projects (bison1->bison2), so  
I'll have a bit of time to work on this.

I'd appreciate a few extra responses -- even benign dictatorships can  
get it wrong sometimes :)

-aDe

On Oct 06, 2007, at 04:12 , Ade Lovett wrote:
> Therein lies my hidden agenda, as it were.
>
> Having done plenty of investigation on this subject, I have come to
> the conclusion that in order to support multiple build hosts etc., is
> going to require essentially a ground-up rewrite.  We've tried to
> shoehorn in concepts, but the overall infrastructure just simply
> isn't designed for multiple systems.
>
> So, what I'm proposing is as follows:
>
> 1.  A cleanout of detritus within tinderbox-HEAD (such as removing
> Hosts).  Overall, the code in HEAD is considerably cleaner than 2.x,
> and this will also help in terms of not having to manage two
> tinderbox branches.
>
> 2.  A new release (based on HEAD) of the tinderbox code, with the
> TINDERBOX_2_X branch being EOL'd.  Whether we call it 3.0, or 2.6, or
> Depleted Uranium, I really don't care.  The point being that we move
> to a single tinderbox code, which snapshot releases on the way for
> inclusion in the ports tree.
>
> 3.  A sit down whiteboard session, identifying requirements for a
> *new* tinderbox system (multi host, multi arch, and so on), with a
> ground up rewrite.
>
> Comments as always.
>
> - -aDe