> > 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?

Mantis is a big step forward for us, but it is not suitable for
generating a released set of packages.  That's because it does not let
you attach bugs to individual packages, and thus there is no way to tell
which packgaes are buggy and which are pristine.

Maybe Mantis can be modified for this; if so, that's great.  The point
is, we don't have it right now.

I don't think it would be hard....  If nothing else, we can probably
steal Debian's bug tracker.  And anyway, there are loads of bug trackers
around.  Or, maybe Brent wants a go at a bug tracker that works like
this, complete with a Squeaky GUI--that would be marvelous!  But
whatever we do, we need some sort of bug tracker that can attach bugs to
packages.


> 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).

There is an important point ignored here: We need to release *sets* of
packages.  Check out the "Why Package Universes Exist" page on the swiki
for a long ramble about it, but the idea is: packages are only reliable
in the context of other packages.  This is because packages interact
with each other.  If we want to have a *set* of packages that are all
reliable with respect to each other,  then we need to manage such a set
together instead of trying to release one package at a time.

	http://minnow.cc.gatech.edu/squeak/3786

An example of not managing this, is RPM hell: you load RPM's from all
different RedHat/Mandrake/FedoraCore distributions, and then you end up
with an unstable system that can't load any more packages because the
dependencies are screwed up.  You can go a little forther if you use
--nodeps, but eventually your tottery system is doomed.  The problem
here is not RPM.  The problem is that you loaded packages that weren't
built with each other in mind.

Packages give a lot of flexibility to the individual maintainers, but it
is important not to take that all the way to the extreme of having each
package live on an island and being developed completely independently. 
Packages interact.  That's why we load multiple packages into the same
image.  Packages interact in far more ways than their dependencies can
ever truly specify, and they very much interact with things in the base
image they are loaded into.  No package will have a dependency on
whether #new calls #initialize, but it certainly is important!

Along these lines, the image can itself be thought of as a package; it's
just a big package, that is maintained using different tools.  It should
be managed exactly the same way, however.  It needs to be developed
along with the other packages.  And just as you can't make a release of
the Tetris package by itself, you can't make a release of an image by
itself.  You need to release an image plus a set of packages.

Releasing an image by itself is not much good, especially as more and
more things are in packages.  Developers need not only a stable image,
but a stable image plus a lot of goodies at their fingertips.


-Lex