process, configuration, and the browser

> Hi Dale,
>
> I was wondering about something. As you may expect, in all the
> software projects that I am deeply involved (Mondrian, Spy, Klotz,
> ...) I create a new version at each big or small increment (e.g.,
> bug fix, adding a comment). It works well since I authoritatively
> designed myself as the unique integrator. For example, Doru worked
> on Mondrian and simply saved the Monticello packages. I saw this,
> and generated a new version. This works well.
>
> Now I am wondering who should have the hand on a configuration. As
> you have rightfully argued against having duplication of versions in
> all the .mcz configuration, merging and conflict are not easy to
> solve. But by having one single integrator (i.e., one guy who is in
> charge of saving new configuration version), it makes the whole
> story simpler I feel.
>
> Just a though.
>
> Cheers, Alexandre
>

>
> On 04/07/2011 06:34 AM, Alexandre Bergel wrote:
>> Hi Dale,
>>
>> I was wondering about something. As you may expect, in all the
>> software projects that I am deeply involved (Mondrian, Spy, Klotz,
>> ...) I create a new version at each big or small increment (e.g.,
>> bug fix, adding a comment). It works well since I authoritatively
>> designed myself as the unique integrator. For example, Doru worked
>> on Mondrian and simply saved the Monticello packages. I saw this,
>> and generated a new version. This works well.
>>
>> Now I am wondering who should have the hand on a configuration. As
>> you have rightfully argued against having duplication of versions in
>> all the .mcz configuration, merging and conflict are not easy to
>> solve. But by having one single integrator (i.e., one guy who is in
>> charge of saving new configuration version), it makes the whole
>> story simpler I feel.
>>
>> Just a though.
>>
>> Cheers, Alexandre
>>
>

>> BTW, I am still waiting for a detailed explanation of the
>> difference between using mcz versions and metacello versions for
>> incremental checkpoints of work....I just don't see the advantage
>> (and see a number of disadvantages) so I am waiting for you to
>> describe the advantages of such approach ... please reread my
>> earlier email on this subject as I don't feel you've responded to
>> any of the points that I made weeks ago and I don't feel like
>> repeating myself over and over....I am willing to be convinced, but
>> so far you haven't tried:)
>
> Easy. The benefits are: - to have plenty of successive
> micro-increments - to not have to write things like "MetacelloBrowser
> 1.59 (dkh.258)" but simply "MetacelloBrowser 1.59"
>
> The only disadvantage I see is for concurrent editing of the
> configuration. Since there has been just one integrator for what I am
> concerned with, so there is no problem.
>
> In any case, this is a rather minimal point that I can perfectly
> accommodate with MonticelloBrowser.
>
>> I don't think it is necessary to have a single integrator in this
>> project.
>
> No no. I am not saying this. It is perfectly fine that you create new
> version.
>
>> You have to realize that on a regular basis (i.e., multiple times
>> per working session) I move my work back and forth between Pharo
>> and GemStone and even different Pharo versions and I use the
>> checkpointed configuration (plus the MetacelloBrowser) to do this
>> work ... it has the main advantage that I am continually using the
>> MetacelloBrowser to do everything so that I can find out which
>> commands are working smoothly and which ones are rough around the
>> edges and which commands I need to add ... Also, I agree with you
>> on the principle of making a bunch of small incremental commits of
>> the project configuration (the mcz file history provides a neat
>> record of what was done and a simple mcz diff between versions
>> provides the detail of just what was changed in the configuration
>> and which mcz files were involved) ...
>
> I am happy that you liked the browser. I will work on it soon
> (cleaning the code, redo the website and documentation).
>
>> _If_ we were working on the same project version, we _could_ branch
>> the configuration mcz file for a period of time and then merge when
>> we're done. To be honest I think that this would work out real well
>> it would involve branching each of the mcz files that we were
>> changing so that we could avoid stepping on each other's toes while
>> doing the work and then merge back together again when we were
>> finished with the larger unit of work ...
>
> It would be nice to have this support yes. Even if I am not a big fan
> of branching.
>
>> I know that folks are currently using the "all developers load
>> latest version of mcz files and one integrator pulls it all
>> together" ... but there are disadvantages to that approach (namely
>> I can't commit a version of a package with "known broken code that
>> needs to be worked on at home on a different machine or needs to be
>> loaded into another image before I can fix it" ... this is
>> something that I do all of the time as I work at work and at home
>> on features/bugs that span multiple work machines and multiple
>> images).
>>
>> A configuration branch per developer/feature/bug with explicit
>> merges into the "trunk" would easily allow for this type of work
>> ... of course tool support would be needed, but then that's what
>> tools are for ...
>>
>> I feel like we should be trying to push boundaries here and not
>> just support the status quo, even though supporting the status quo
>> is important...
>
> +1 I fully agree
>
> Alexandre
>
>>
>> On 04/07/2011 06:34 AM, Alexandre Bergel wrote:
>>> Hi Dale,
>>>
>>> I was wondering about something. As you may expect, in all the
>>> software projects that I am deeply involved (Mondrian, Spy,
>>> Klotz, ...) I create a new version at each big or small increment
>>> (e.g., bug fix, adding a comment). It works well since I
>>> authoritatively designed myself as the unique integrator. For
>>> example, Doru worked on Mondrian and simply saved the Monticello
>>> packages. I saw this, and generated a new version. This works
>>> well.
>>>
>>> Now I am wondering who should have the hand on a configuration.
>>> As you have rightfully argued against having duplication of
>>> versions in all the .mcz configuration, merging and conflict are
>>> not easy to solve. But by having one single integrator (i.e., one
>>> guy who is in charge of saving new configuration version), it
>>> makes the whole story simpler I feel.
>>>
>>> Just a though.
>>>
>>> Cheers, Alexandre
>>>
>>
>

>
> On 04/07/2011 07:46 PM, Alexandre Bergel wrote:
>>> BTW, I am still waiting for a detailed explanation of the
>>> difference between using mcz versions and metacello versions for
>>> incremental checkpoints of work....I just don't see the advantage
>>> (and see a number of disadvantages) so I am waiting for you to
>>> describe the advantages of such approach ... please reread my
>>> earlier email on this subject as I don't feel you've responded to
>>> any of the points that I made weeks ago and I don't feel like
>>> repeating myself over and over....I am willing to be convinced, but
>>> so far you haven't tried:)
>>
>> Easy. The benefits are: - to have plenty of successive
>> micro-increments - to not have to write things like "MetacelloBrowser
>> 1.59 (dkh.258)" but simply "MetacelloBrowser 1.59"
>>
>> The only disadvantage I see is for concurrent editing of the
>> configuration. Since there has been just one integrator for what I am
>> concerned with, so there is no problem.
>>
>> In any case, this is a rather minimal point that I can perfectly
>> accommodate with MonticelloBrowser.
>>
>>> I don't think it is necessary to have a single integrator in this
>>> project.
>>
>> No no. I am not saying this. It is perfectly fine that you create new
>> version.
>>
>>> You have to realize that on a regular basis (i.e., multiple times
>>> per working session) I move my work back and forth between Pharo
>>> and GemStone and even different Pharo versions and I use the
>>> checkpointed configuration (plus the MetacelloBrowser) to do this
>>> work ... it has the main advantage that I am continually using the
>>> MetacelloBrowser to do everything so that I can find out which
>>> commands are working smoothly and which ones are rough around the
>>> edges and which commands I need to add ... Also, I agree with you
>>> on the principle of making a bunch of small incremental commits of
>>> the project configuration (the mcz file history provides a neat
>>> record of what was done and a simple mcz diff between versions
>>> provides the detail of just what was changed in the configuration
>>> and which mcz files were involved) ...
>>
>> I am happy that you liked the browser. I will work on it soon
>> (cleaning the code, redo the website and documentation).
>>
>>> _If_ we were working on the same project version, we _could_ branch
>>> the configuration mcz file for a period of time and then merge when
>>> we're done. To be honest I think that this would work out real well
>>> it would involve branching each of the mcz files that we were
>>> changing so that we could avoid stepping on each other's toes while
>>> doing the work and then merge back together again when we were
>>> finished with the larger unit of work ...
>>
>> It would be nice to have this support yes. Even if I am not a big fan
>> of branching.
>>
>>> I know that folks are currently using the "all developers load
>>> latest version of mcz files and one integrator pulls it all
>>> together" ... but there are disadvantages to that approach (namely
>>> I can't commit a version of a package with "known broken code that
>>> needs to be worked on at home on a different machine or needs to be
>>> loaded into another image before I can fix it" ... this is
>>> something that I do all of the time as I work at work and at home
>>> on features/bugs that span multiple work machines and multiple
>>> images).
>>>
>>> A configuration branch per developer/feature/bug with explicit
>>> merges into the "trunk" would easily allow for this type of work
>>> ... of course tool support would be needed, but then that's what
>>> tools are for ...
>>>
>>> I feel like we should be trying to push boundaries here and not
>>> just support the status quo, even though supporting the status quo
>>> is important...
>>
>> +1 I fully agree
>>
>> Alexandre
>>
>>>
>>> On 04/07/2011 06:34 AM, Alexandre Bergel wrote:
>>>> Hi Dale,
>>>>
>>>> I was wondering about something. As you may expect, in all the
>>>> software projects that I am deeply involved (Mondrian, Spy,
>>>> Klotz, ...) I create a new version at each big or small increment
>>>> (e.g., bug fix, adding a comment). It works well since I
>>>> authoritatively designed myself as the unique integrator. For
>>>> example, Doru worked on Mondrian and simply saved the Monticello
>>>> packages. I saw this, and generated a new version. This works
>>>> well.
>>>>
>>>> Now I am wondering who should have the hand on a configuration.
>>>> As you have rightfully argued against having duplication of
>>>> versions in all the .mcz configuration, merging and conflict are
>>>> not easy to solve. But by having one single integrator (i.e., one
>>>> guy who is in charge of saving new configuration version), it
>>>> makes the whole story simpler I feel.
>>>>
>>>> Just a though.
>>>>
>>>> Cheers, Alexandre
>>>>
>>>
>>
>