On Thu, 2009-07-02 at 00:33 -0700, Joshua Gargus wrote:
> Norbert Hartl wrote:
> > Hi,
> >
> > this proposal is really a step towards openness. I'm glad you added
> > the inbox to your original proposal. Without that it wasn't really
> > welcoming work from others. 
> >
> > I still don't think that Monticello is the right way to go. It doesn't
> > really manage changes. I can so easily overwrite a change that was
> > applied before that it is hard to use. You can argue that you have to
> > be careful anyway and that you can merge. You are right but still it
> > is hard to use. 
> 
> Do you have an alternative?  I use Monticello every day in a
> heavily-developed commercial codebase, and don't run into significant
> problems.
> 
Yes, I did this, too. In my own team the only problem was dependencies.
But in a more loose environment like this there are other things to be
aware of. Having an inbox that is world-writable is a good thing. But if
you use Monticello that does not have a notion of change but contains
the new source code than every day you don't harvest that archive it 
will detoriate. If you not use the same image as the originator of the
source package than it will eventually show a lot of changes. Only some
of these are your own changes. It is much more difficult to integrate 
those package and the have to danger to introduce regression very
easily.

> > Another thing is pharo. All of my contribution to the
> > image I did in pharo because I never saw much a chance to do this in
> > squeak. Now it can be doable. And doing something in pharo and not be
> > able to do it in squeak at the same time strikes me really. Using 
> > always Monticello with full source compare will prevent applying fixes
> > from one team to the other. The sources are just more different every
> > day.
> >
> >   
> 
> Again, do you have an alternative?  I don't think that there currently
> exists a technical solution to this problem (nor can one, to the extent
> that the codebases really are different).  Maybe someday Squeak and
> Pharo will merge, but that will be after we overcome social challenges,
> not technical ones.
> 
Well, goran took his chance to speak up. There is DeltaStreams und MC2.
While there is a risk using this pieces of software the benefit could be
really big. First you would give one of these tools the chance to 
become a part of the overall that they deserve. And they try to
eliminate the problems that are experienced with changesets and MC. So 
there has to be a point in using it. These are good tools but they all
tend to starve because at the end nobody dares to try it and to migrate
if you not promise that it is already rock solid and matured. I don't
think this is "how it works [tm]".

I just think that at this particular moment where everybody has woken up
and a little wave is making its way there could be a chance to finalize
one of the newer products. 

Norbert
> > For the new setup to work well there is still one thing to do IMHO. 
> > Sooner or later the bug tracker should help in organizing and 
> > documenting changes. But mantis is in an awful state. There are nearly
> > 2200 tickets in the database. Coming from the outside it looks like
> > really nobody cares. A bug tracker with less tickets and tickets that
> > give an overview what is going on right now is essential. Maybe not
> > for the gurus and old timers but for everyone else (e.g. me). I would
> > like to propose a cleaning initiative of mantis. I would expect a lot
> > of these old bugs to be obsolete by now. So a quick check if this bug
> > is still valid can be done. And then if it is invalid you just need
> > to close it. 
> >
> >   
> 
> Good point.  I'm hopeful that the process that Andreas describes will
> lower the barriers to addressing some of the bugs listed in Mantis.
> 
> Cheers,
> Josh
> 
> 
> > Norbert
> >
> >
> >   
> 
>