Norbert Hartl wrote:
> 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.
>   

That's a good point.  It's difficult to predict how well it will work in
practice.  But, it's even more difficult to design better tools when we
don't see where the current ones fail.
>   
>>> 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. 
>   

Personally, I have a tendency to over-engineer and build "The Right
Thing" the first time.  Following the example of my excellent
colleagues, I have learned to resist this impulse to a certain extent.

In this case, I don't see any danger in using the currently-available
tools.  In particular, I don't see anything in the process that makes it
difficult to experiment with or adopt better tools as they become
available.  On the other hand, I perceive some risk to the current
momentum if we make the process contingent on tools that may not yet be
ready for the task.

Cheers,
Josh


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090702/fdd3c81d/attachment.htm