<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Norbert Hartl wrote:
<blockquote cite="mid:1246521280.17185.37.camel@cineflux" type="cite">
<pre wrap="">On Thu, 2009-07-02 at 00:33 -0700, Joshua Gargus wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Norbert Hartl wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">Do you have an alternative? I use Monticello every day in a
heavily-developed commercial codebase, and don't run into significant
problems.
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
</blockquote>
<br>
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.<br>
<blockquote cite="mid:1246521280.17185.37.camel@cineflux" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap=""><!---->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.
</pre>
</blockquote>
<br>
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.<br>
<br>
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.<br>
<br>
Cheers,<br>
Josh<br>
<br>
<br>
<blockquote cite="mid:1246521280.17185.37.camel@cineflux" type="cite">
<pre wrap="">
Norbert
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">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
</pre>
<blockquote type="cite">
<pre wrap="">Norbert
</pre>
</blockquote>
<pre wrap="">
</pre>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
<br>
</body>
</html>