Hi,

> 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.
>
>
I would think the same if I would ignore the discussion about these topics
in the last months/years about this topic. DeltaStreams and MC2 are there
because there are experiencable shortcomings they want to solve. As far as
I can tell both are in a usable state but not fully matured, yet. But they
have state where there might be used for such a project. And this is a
work this community can survive for the first weeks.

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