Issue 133 in metacello: MetacelloBrowser: Abstract test not indicated

> Status: New
> Owner: ----
> Labels: Type-Defect Priority-Medium Product-Core
>
> New issue 133 by [hidden email]: MetacelloBrowser: Abstract test not indicated
> http://code.google.com/p/metacello/issues/detail?id=133
>
> At least three test classes for the MetacelloBrowser are
> abstract but not declared as such.
> The attached  changeset includes the necessary changes.
>
>
>
> Attachments:
> MetacelloBrowserAbstractTests.1.cs  811 bytes
>

> Now in 1.60.1 (296): Fixed  Issue 133: MetacelloBrowser: Abstract test not indicated.
> I also added a test for this.
>
> Thanks Tobias!
>
> Cheers,
> Alexandre
>
>
> On 15 Apr 2011, at 09:19, [hidden email] wrote:
>
>> Status: New
>> Owner: ----
>> Labels: Type-Defect Priority-Medium Product-Core
>>
>> New issue 133 by [hidden email]: MetacelloBrowser: Abstract test not indicated
>> http://code.google.com/p/metacello/issues/detail?id=133
>>
>> At least three test classes for the MetacelloBrowser are
>> abstract but not declared as such.
>> The attached  changeset includes the necessary changes.
>>
>>
>>
>> Attachments:
>> MetacelloBrowserAbstractTests.1.cs  811 bytes
>>
>

>> Why are you creating new versions (again)?
>>
>> I've asked you multiple times to use the open development version and to not spin off new metacello versions on each commit and here you've gone off and done it again ...
>
>
> There was 1.59, 1.59.1, 1.60. So why not 1.60.1?
> I am now working on fixing the issues Tobias raised. I think it makes sense to put all his fixes into 1.60.1. I started with 133, there is 132 and 134 that will come up.
> Something wrong with that?
>
> Alexandre
>

> > Do you recall the many, many, many emails that we have exchanged talking about working in a single metacello version vs creating a separate metacello version for each commit?
>
> Yes I do.
>
> > I have asked you to document your process and I have seen nothing.
>
> Easy:
>  1 - do your modif (e.g., adding 10 classes and 100 methods, fixing a bug, adding a comment, or simply fixing a typo in a comment)
>  2 - run the test, if green then go to 3 else to 1
>  3 - commit and add a new version number

>
>
> > I now think the root cause is that you do not under "Software versioningg" or you are choosing not to think in terms of "Software versioning" when thinking of metacello versions ...
>
> I found the wikipedia page long, complicated and non intuitive. But this is my opinion and I do not want to force people to agree with it. Probably that if I have to manage 100 people working on many different branches, I will think about a more sophisticated process. But until then...
>
> > You are thinking in terms of a paper ... versions are not papers ...
>
> :-)
>
> Tobias fixes are important. Very important. They are as important than any other fix. This is what I wanted to gratify this with a version since this is a very important change for the future of MetacelloBrowser. No less important than all the changes that made 1.59 stable.

>> Do you recall the many, many, many emails that we have exchanged talking about working in a single metacello version vs creating a separate metacello version for each commit?
>
> Yes I do.
>
>> I have asked you to document your process and I have seen nothing.
>
> Easy:
>   1 - do your modif (e.g., adding 10 classes and 100 methods, fixing a bug, adding a comment, or simply fixing a typo in a comment)
>   2 - run the test, if green then go to 3 else to 1
>   3 - commit and add a new version number
>
> This is what Pharo is doing (e.g., 12345, 12346, 12347, ...) and most of the tool that I use (e.g., I use version 5.138.140.0.129428 of Omnigraffle :-)
>
>
>> I now think the root cause is that you do not under "Software versioningg" or you are choosing not to think in terms of "Software versioning" when thinking of metacello versions ...
>
> I found the wikipedia page long, complicated and non intuitive. But this is my opinion and I do not want to force people to agree with it. Probably that if I have to manage 100 people working on many different branches, I will think about a more sophisticated process. But until then...
>
>> You are thinking in terms of a paper ... versions are not papers ...
>
> :-)
>
> Tobias fixes are important. Very important. They are as important than any other fix. This is what I wanted to gratify this with a version since this is a very important change for the future of MetacelloBrowser. No less important than all the changes that made 1.59 stable.
>
> I will only commit on 1.60.1. We will then discuss when to move to 1.61.
>
> Alexandre

>
> On 04/15/2011 10:23 AM, Alexandre Bergel wrote:
>>> Do you recall the many, many, many emails that we have exchanged talking about working in a single metacello version vs creating a separate metacello version for each commit?
>>
>> Yes I do.
>>
>>> I have asked you to document your process and I have seen nothing.
>>
>> Easy:
>>  1 - do your modif (e.g., adding 10 classes and 100 methods, fixing a bug, adding a comment, or simply fixing a typo in a comment)
>>  2 - run the test, if green then go to 3 else to 1
>>  3 - commit and add a new version number
>>
>> This is what Pharo is doing (e.g., 12345, 12346, 12347, ...) and most of the tool that I use (e.g., I use version 5.138.140.0.129428 of Omnigraffle :-)
>>
>>
>>> I now think the root cause is that you do not under "Software versioningg" or you are choosing not to think in terms of "Software versioning" when thinking of metacello versions ...
>>
>> I found the wikipedia page long, complicated and non intuitive. But this is my opinion and I do not want to force people to agree with it. Probably that if I have to manage 100 people working on many different branches, I will think about a more sophisticated process. But until then...
>>
>>> You are thinking in terms of a paper ... versions are not papers ...
>>
>> :-)
>>
>> Tobias fixes are important. Very important. They are as important than any other fix. This is what I wanted to gratify this with a version since this is a very important change for the future of MetacelloBrowser. No less important than all the changes that made 1.59 stable.
>>
>> I will only commit on 1.60.1. We will then discuss when to move to 1.61.
>>
>> Alexandre
>

> I finally got back to my computer earlier than I expected. So, the discussion can be resumed...
>
>> In monticello you mean. Because I could just commit the first of three
>> related changes to the repo. That doesn't mean that I should update the
>> Metacello configuration to put it available to users. When I have the
>> other two commits done and commited (monticello has three new versions)
>> then I do *one* metacello release (encompassing three commits, not that
>> my users care indeed, it could be thousands).
>
> This is the way you program and I respect this. I use a slightly different way of numbering, and it has worked very well so far. When someone asks to use Mondrian or Hapao, I recommend to use the last version. This is simple and everybody understand. All the tests are green. If they are not green, then I apology for the damage caused and I fix them.
> If a user finds a bug, then I merely open a bug fix and try to fix this rapidly. Once fixed, I made another release. We do this for Moose and it just works. I am not saying this is better than other way of working. Look, we are lucky to live in a free World :-)
>
> Again, I want to be able to precisely trace the version of an application, without having to ask about the number of the .mcz file configuration. I value being able to easily know which version a user has when he says he is using 1.60.1. Asking what is the version of the .mcz file is conter-productive in my opinion.
>
>>> This is what Pharo is doing (e.g., 12345, 12346, 12347, ...) and most of the tool that I use
>>
>>> (e.g., I use version 5.138.140.0.129428 of Omnigraffle :-)
>>
>> No idea what that could even mean to the *end user* (the target for
>> Metacello)
>
> That doesn't matter. If I have to report a bug in Omnigraffle, I would give this number and they would precisely know which version I am using.
>
>> What will happen when you have 10 release out there?
>> Will you update the ten release to include a fix, that is a nightmare
>> (effectively you're maintaining 10 branches of your code base, no
>> project can survive that).
>
> No. I consider every version as a release. And having plenty of them is healthy. People have to always use the last version of Mondrian, Spy, Moose and so on.
>
> So, shall I use Pharo 1.2.1 or use the last version of Pharo? Am I a user or a developer?
> Unfortunately, I haven't got much resources to directly contribute to improve Pharo core. Will I get slashed if I use the last version of it? :-)
>
> Cheers,
> Alexandre
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

> Alexandre,
>
> If you do not know what "Software versioning" is and you are not interested in learning, please tell me why I should pay attention to anything else you have to say on the subject?
>
> Dale
>
>
> On Apr 15, 2011, at 5:25 PM, Alexandre Bergel wrote:
>
>> I finally got back to my computer earlier than I expected. So, the discussion can be resumed...
>>
>>> In monticello you mean. Because I could just commit the first of three
>>> related changes to the repo. That doesn't mean that I should update the
>>> Metacello configuration to put it available to users. When I have the
>>> other two commits done and commited (monticello has three new versions)
>>> then I do *one* metacello release (encompassing three commits, not that
>>> my users care indeed, it could be thousands).
>>
>> This is the way you program and I respect this. I use a slightly different way of numbering, and it has worked very well so far. When someone asks to use Mondrian or Hapao, I recommend to use the last version. This is simple and everybody understand. All the tests are green. If they are not green, then I apology for the damage caused and I fix them.
>> If a user finds a bug, then I merely open a bug fix and try to fix this rapidly. Once fixed, I made another release. We do this for Moose and it just works. I am not saying this is better than other way of working. Look, we are lucky to live in a free World :-)
>>
>> Again, I want to be able to precisely trace the version of an application, without having to ask about the number of the .mcz file configuration. I value being able to easily know which version a user has when he says he is using 1.60.1. Asking what is the version of the .mcz file is conter-productive in my opinion.
>>
>>>> This is what Pharo is doing (e.g., 12345, 12346, 12347, ...) and most of the tool that I use
>>>
>>>> (e.g., I use version 5.138.140.0.129428 of Omnigraffle :-)
>>>
>>> No idea what that could even mean to the *end user* (the target for
>>> Metacello)
>>
>> That doesn't matter. If I have to report a bug in Omnigraffle, I would give this number and they would precisely know which version I am using.
>>
>>> What will happen when you have 10 release out there?
>>> Will you update the ten release to include a fix, that is a nightmare
>>> (effectively you're maintaining 10 branches of your code base, no
>>> project can survive that).
>>
>> No. I consider every version as a release. And having plenty of them is healthy. People have to always use the last version of Mondrian, Spy, Moose and so on.
>>
>> So, shall I use Pharo 1.2.1 or use the last version of Pharo? Am I a user or a developer?
>> Unfortunately, I haven't got much resources to directly contribute to improve Pharo core. Will I get slashed if I use the last version of it? :-)
>>
>> Cheers,
>> Alexandre
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>

>
> On Apr 15, 2011, at 8:01 PM, Alexandre Bergel wrote:
>
>> Even if I do not fully agree on your schema, I am willing to follow it.
>
> If you don't understand it, how can you follow it? If you don't understand it how can you agree or disagree?
>
>> Dale, let's be constructive please.
>
> If you want to be constructive, express a willingness to learn about "Software versioning".... We cannot have a meaningful conversation about Metacello unless you are wiling to learn some of the concepts ...
>
>
>> How can I help you to turn the yellow test green? I would like to incorporate Tobias fixes, but I do not feel confident in committing if tests are not green.
>
> If you understood the process that I want to follow, you would not be pleading with me to turn the tests green on a version that is not ready to be used by anyone else, whether or not the tests are green ... you would also know that there is a very simple answer to your problem .... a hint is that I've already mentioned the solution in an earlier email....
>
> Dale

> I can't believe that all started because I prefer to write "1.60.1" instead of "1.60 (dkh.288)".
>
> Alexandre
>
>
> On 15 Apr 2011, at 22:12, Dale Henrichs wrote:
>
>>
>> On Apr 15, 2011, at 8:01 PM, Alexandre Bergel wrote:
>>
>>> Even if I do not fully agree on your schema, I am willing to follow it.
>>
>> If you don't understand it, how can you follow it? If you don't understand it how can you agree or disagree?
>>
>>> Dale, let's be constructive please.
>>
>> If you want to be constructive, express a willingness to learn about "Software versioning".... We cannot have a meaningful conversation about Metacello unless you are wiling to learn some of the concepts ...
>>
>>
>>> How can I help you to turn the yellow test green? I would like to incorporate Tobias fixes, but I do not feel confident in committing if tests are not green.
>>
>> If you understood the process that I want to follow, you would not be pleading with me to turn the tests green on a version that is not ready to be used by anyone else, whether or not the tests are green ... you would also know that there is a very simple answer to your problem .... a hint is that I've already mentioned the solution in an earlier email....
>>
>> Dale
>
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
>
>

> Alexandre,
>
> You are completely missing the point ... read about "software versioning" ....
>
> I can't believe that you aren't willing to learn about Software versioning ... that is really incredible to me...
>
> Seriously if you refuse to learn, I will simply fork the project ... I don't want to ... I still believe that you have something to contribute, but if you are unwilling to inform yourself so that we can have a meaningful conversation/debate, then I am unwilling to work with you...
>
> Dale
>
> On Apr 15, 2011, at 8:31 PM, Alexandre Bergel wrote:
>
>> I can't believe that all started because I prefer to write "1.60.1" instead of "1.60 (dkh.288)".
>>
>> Alexandre
>>
>>
>> On 15 Apr 2011, at 22:12, Dale Henrichs wrote:
>>
>>>
>>> On Apr 15, 2011, at 8:01 PM, Alexandre Bergel wrote:
>>>
>>>> Even if I do not fully agree on your schema, I am willing to follow it.
>>>
>>> If you don't understand it, how can you follow it? If you don't understand it how can you agree or disagree?
>>>
>>>> Dale, let's be constructive please.
>>>
>>> If you want to be constructive, express a willingness to learn about "Software versioning".... We cannot have a meaningful conversation about Metacello unless you are wiling to learn some of the concepts ...
>>>
>>>
>>>> How can I help you to turn the yellow test green? I would like to incorporate Tobias fixes, but I do not feel confident in committing if tests are not green.
>>>
>>> If you understood the process that I want to follow, you would not be pleading with me to turn the tests green on a version that is not ready to be used by anyone else, whether or not the tests are green ... you would also know that there is a very simple answer to your problem .... a hint is that I've already mentioned the solution in an earlier email....
>>>
>>> Dale
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>

> On Apr 15, 2011, at 8:31 PM, Alexandre Bergel wrote:
>
>> I can't believe that all started because I prefer to write "1.60.1" instead of "1.60 (dkh.288)".
>>
>> Alexandre
>>
>>
>> On 15 Apr 2011, at 22:12, Dale Henrichs wrote:
>>
>>>
>>> On Apr 15, 2011, at 8:01 PM, Alexandre Bergel wrote:
>>>
>>>> Even if I do not fully agree on your schema, I am willing to follow it.
>>>
>>> If you don't understand it, how can you follow it? If you don't understand it how can you agree or disagree?
>>>
>>>> Dale, let's be constructive please.
>>>
>>> If you want to be constructive, express a willingness to learn about "Software versioning".... We cannot have a meaningful conversation about Metacello unless you are wiling to learn some of the concepts ...
>>>
>>>
>>>> How can I help you to turn the yellow test green? I would like to incorporate Tobias fixes, but I do not feel confident in committing if tests are not green.
>>>
>>> If you understood the process that I want to follow, you would not be pleading with me to turn the tests green on a version that is not ready to be used by anyone else, whether or not the tests are green ... you would also know that there is a very simple answer to your problem .... a hint is that I've already mentioned the solution in an earlier email....
>>>
>>> Dale
>>
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>>
>>
>

> I finally got back to my computer earlier than I expected. So, the discussion can be resumed...
>
> > In monticello you mean. Because I could just commit the first of three
> > related changes to the repo. That doesn't mean that I should update the
> > Metacello configuration to put it available to users. When I have the
> > other two commits done and commited (monticello has three new versions)
> > then I do *one* metacello release (encompassing three commits, not that
> > my users care indeed, it could be thousands).
>
> This is the way you program and I respect this. I use a slightly different way of numbering, and it has worked very well so far. When someone asks to use Mondrian or Hapao, I recommend to use the last version. This is simple and everybody understand. All the tests are green. If they are not green, then I apology for the damage caused and I fix them.
> If a user finds a bug, then I merely open a bug fix and try to fix this rapidly. Once fixed, I made another release. We do this for Moose and it just works. I am not saying this is better than other way of working. Look, we are lucky to live in a free World :-)