To Traits Or Not To Traits (Was: Re: Stefs roadmap for 3.9, time to get it nailed down)

goran.krampe at bluefish.se goran.krampe at bluefish.se
Thu Feb 24 09:25:13 UTC 2005


Hi fellas!

Trying to pick pieces here to comment. :)

"Lex Spoon" <lex at cc.gatech.edu> wrote:
> How about waiting until the beginning of a release cycle to make a major
> change like adding Traits?  I assume it is likely to bring out a lot of
> bugs?  If we do it at the beginning of a release cycle, then we can take
> our time and get the bugs out.

That is true, but on the other hand 3.9 is more or less in the
"beginning" because not much has gone in since it was opened up - more
or less only Diego's look AFAIK.

But this is moot because IMHO, as Cees described in more detail, Traits
needs a longer period of digestion IMHO. I mean, when we have a beta of
the Traits that is meant to be the Real And True version :) - then we
can all play with it and see how it works etc. And then, we can start
thinking about including it into the official Basic image.

But this only works if Traits *can* be implemented as a package. I still
don't know that. Nathanael?

[SNIP]
> > What we're missing is Unstable, where  
> > people are allowed to throw in mostly anything they seem fit. So you can  
> > actually work with stuff, see how it behaves, before deciding on whether  
> > to move it on to Testing (which is the doorkeeper to Stable, sort of). The  
> > Unstable update stream is a good step in this direction, maybe we should  
> > make it more prominent and push it a little more?
> > Have some very lightweight 'decision process', maybe a checklist, for  
> > adding stuff to Unstable?
> 
> The only thing we have is unstable, and that's both 3.8 and 3.9.  I
> don't think that having separate 3.9 unstable is what we want in the
> long run, but whatever.
> 
> Debian doesn't make a "stable" release by shipping a Linux kernel that
> is stable and then saying good luck.  They also ship thousands of
> packages, none of which have a "release critical" bug that is still open
> on the bug tracker.  We don't even have either (a) release critical bugs
> or (b) a released set of packages.  
> 
> For (a) someone simply needs to install a suitable bug tracker.  We
> could even use Debian's, I'd think.

Mmmm, Mantis is what we have today and... I and others (Ken just formed
a Team on the subject) are suggesting that we *temporarily* focus on. Or
did you mean some other tool?

> For (b), both SqueakMap and Package Universes could be used.  Package
> Universes supports this out of the box: use one universe for development
> and testing, and one universe for each set of packages.  You'd set the
> policies different for each kind of universe: development universes are
> wide open to changes, while stable universes require the twelve sacred
> humpalumphs to gather and perform a 3-day long ritual before a package
> is allowed to go in.
> 
> On SqueakMap, I believe you could use tags, *if* they were adjusted so
> that any old yahoo can't just add a "stable" tage to a package whenever
> they like.  Alternatively, I think Goran mentioned some sort of compound
> package that might work: a compound package would be a package that has
> a list of pointers to other packages.

Yes, or something like that. :) In short - we should merge our work in
some suitable way and I am committed to start that by taking a good look
at Universes the first thing I do (typically) in the Packages team. Or
if we don't merge we should at least make these things play nice and
integrate with each other.

So anyway, given a package oriented view here I don't think we need a
special update stream for "unstable stuff". Sure, we can still have the
unstable stream as a "first front", but generally packages is what we
want and then things work out naturally (meaning the maintainers can
make their new releases available regardless of how stable they are
etc).
 
> Anyway, I mean to post more on this eventually, but wanted to toss this
> out since you mentioned it. 
> 
> -Lex

I can create the Packages list for the Packages Team but the moderator
should probably be the Team leader. Or what the hell - I can take that
moderator crap. Ok, created. :) Please subscribe:

	packages-subscribe at discuss.squeakfoundation.org

regards, Göran



More information about the Squeak-dev mailing list