Tracing bugs/corrections/regressions ... in Pharo

> The fact is that, while many patches find their way from Squeak to
> Pharo, very few take the other way.
>
> Why is that ?
> - squeak people are sobing pharoers
> - squeak people are too few to achieve this task
> - there is nothing interesting happening in Pharo
> No no, please don't answer, I innoculate this bullshit intentionnally
> to vaccine this thread against further crap.
>
> What IMO is the main explanation is this:
> - it's very easy to cherry pick squeak changes thanks to trunk: diff
> messages, while there is nothing equivalent in Pharo.
>
> Just browsing Squeak/Pharo diffs, it's easy to recognize text
> copy/pasted via web with tabs changed in spaces.
> Also the pharo issue tracker is full of these.
> This gives some clues.
>
> This is a very good thing that patches can be shared. But why not the
> other way around ?
> This is surprising because:
> - 1) Pharo is very active these days.
> - 2) Pharo was apparently setting a higher quality hurdle by forcing
> each modification to be traced
>       ( http://code.google.com/p/pharo/issues )
> So we could have expected more fixes coming from Pharo.
>
> Maybe it's because the process only have appearances of quality, but
> doesn't really pay off.
> Maybe I had some bad luck with
> http://code.google.com/p/pharo/issues/detail?id=3468
> Or is there many examples of issues closed without a clue ?
> Imagine you can recognize the symptoms of this bug in Pharo 1.1 and
> want to backport the patch...
> I'm interested to hear how to proceed.
>
> The simple squeak trunk diff messages are not a panacea.
> A database of changes in all flavours of Squeak might help better.
> But it's very practicle and I wish I could see an equivalent in Pharo.
>
> On the other end, I was finally forced to filter out the automated
> [Pharo-Issues] posts.
> The signal/noise ratio is far too low to sustain attention, though I
> for one care about patches.
>
> I wish my criticism could bring introspection, better and - why not -
> squeak friendly :) practices.
>
> Nicolas
>

> Do you think that a trunk process like the Squeak one would be good for
> Pharo? Any improvement to introduce in the process? Any drawback to
> remove?
>
> In the end the process is dictated by the underlying tools (MC and
> squeaksource in this case). What kind of process of
> patching/contributing would we have if tools like git and infrastructure
> like github were available to Pharo/Squeak users/developers just as easy
> like they are for any other open source project?
>
> Many of the problems are products of the way that MC, Squeaksource,
> Squeak/Pharo changesets, author/contributor attribution works in the
> Squeak/Pharo world. Maybe the problem isn't the process but the current
> tools. Maybe a profound solution is the only way to escape the tortuous
> process we have?
>
> Cheers  
>
> El mar, 01-02-2011 a las 01:47 +0100, Nicolas Cellier escribió:
>> The fact is that, while many patches find their way from Squeak to
>> Pharo, very few take the other way.
>>
>> Why is that ?
>> - squeak people are sobing pharoers
>> - squeak people are too few to achieve this task
>> - there is nothing interesting happening in Pharo
>> No no, please don't answer, I innoculate this bullshit intentionnally
>> to vaccine this thread against further crap.
>>
>> What IMO is the main explanation is this:
>> - it's very easy to cherry pick squeak changes thanks to trunk: diff
>> messages, while there is nothing equivalent in Pharo.
>>
>> Just browsing Squeak/Pharo diffs, it's easy to recognize text
>> copy/pasted via web with tabs changed in spaces.
>> Also the pharo issue tracker is full of these.
>> This gives some clues.
>>
>> This is a very good thing that patches can be shared. But why not the
>> other way around ?
>> This is surprising because:
>> - 1) Pharo is very active these days.
>> - 2) Pharo was apparently setting a higher quality hurdle by forcing
>> each modification to be traced
>>      ( http://code.google.com/p/pharo/issues )
>> So we could have expected more fixes coming from Pharo.
>>
>> Maybe it's because the process only have appearances of quality, but
>> doesn't really pay off.
>> Maybe I had some bad luck with
>> http://code.google.com/p/pharo/issues/detail?id=3468
>> Or is there many examples of issues closed without a clue ?
>> Imagine you can recognize the symptoms of this bug in Pharo 1.1 and
>> want to backport the patch...
>> I'm interested to hear how to proceed.
>>
>> The simple squeak trunk diff messages are not a panacea.
>> A database of changes in all flavours of Squeak might help better.
>> But it's very practicle and I wish I could see an equivalent in Pharo.
>>
>> On the other end, I was finally forced to filter out the automated
>> [Pharo-Issues] posts.
>> The signal/noise ratio is far too low to sustain attention, though I
>> for one care about patches.
>>
>> I wish my criticism could bring introspection, better and - why not -
>> squeak friendly :) practices.
>>
>> Nicolas
>>
>
> --
> Miguel Cobá
> http://twitter.com/MiguelCobaMtz
> http://miguel.leugim.com.mx
>
>
>
>

>>
>> Maybe I had some bad luck with
>> http://code.google.com/p/pharo/issues/detail?id=3468
>> Or is there many examples of issues closed without a clue ?
>
> In a case like that, the changeset was just merged in the release.
>
> The test is failing, as you can see:
>
> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompletedBuild/testReport/KernelTests.Methods/CompiledMethodTest/testPerformInSuperclassCanExecutelongMethodWithTemps/
>
>

> 2011/2/1 Marcus Denker <[hidden email]>:
>>>
>>> Maybe I had some bad luck with
>>> http://code.google.com/p/pharo/issues/detail?id=3468
>>> Or is there many examples of issues closed without a clue ?
>>
>> In a case like that, the changeset was just merged in the release.
>>
>> The test is failing, as you can see:
>>
>> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompletedBuild/testReport/KernelTests.Methods/CompiledMethodTest/testPerformInSuperclassCanExecutelongMethodWithTemps/
>>
>>
>
> This is probably because you must
>    (Object recompile: #perform:withArguments:)
>

> Nicolas
>
> We wanted to see the diff like in squeak (check the mails in september) but the squeaksource server would die under the
> diff size to generate (sic lukas). So? Do you think that we are explicitly against squeak. If we ever reached this state of mind, this is
> years that we passed it.
>
>> Maybe it's because the process only have appearances of quality, but
>> doesn't really pay off.
>
> Why do you say that? We log all our bugs and actions. So you can take all the fixes for squeak if you want. This is not my goal in life.
> Now we are more busy than average and sometimes opening a bug entry when you already pushed the code in the server
> is subject to missing some parts. But this is life.

>>
>> The test is failing, as you can see:
>>
>> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompletedBuild/testReport/KernelTests.Methods/CompiledMethodTest/testPerformInSuperclassCanExecutelongMethodWithTemps/
>>
>>
>
> This is probably because you must
>    (Object recompile: #perform:withArguments:)
>
> Nicolas

> we wrote the test to make sure that
> the behavior is documented.
>
>>>
>>> The test is failing, as you can see:
>>>
>>> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompletedBuild/testReport/KernelTests.Methods/CompiledMethodTest/testPerformInSuperclassCanExecutelongMethodWithTemps/
>>>
>>>
>>
>> This is probably because you must
>>   (Object recompile: #perform:withArguments:)
>>
>> Nicolas
>

> Nicolas
>
> We wanted to see the diff like in squeak (check the mails in september) but the squeaksource server would die under the
> diff size to generate (sic lukas). So? Do you think that we are explicitly against squeak. If we ever reached this state of mind, this is
> years that we passed it.
>
>> Maybe it's because the process only have appearances of quality, but
>> doesn't really pay off.
>
> Why do you say that? We log all our bugs and actions. So you can take all the fixes for squeak if you want. This is not my goal in life.
> Now we are more busy than average and sometimes opening a bug entry when you already pushed the code in the server
> is subject to missing some parts. But this is life.
>

>
> On Feb 1, 2011, at 8:01 AM, Nicolas Cellier wrote:
>
>> 2011/2/1 Marcus Denker <[hidden email]>:
>>>>
>>>> Maybe I had some bad luck with
>>>> http://code.google.com/p/pharo/issues/detail?id=3468
>>>> Or is there many examples of issues closed without a clue ?
>>>
>>> In a case like that, the changeset was just merged in the release.
>>>
>>> The test is failing, as you can see:
>>>
>>> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompletedBuild/testReport/KernelTests.Methods/CompiledMethodTest/testPerformInSuperclassCanExecutelongMethodWithTemps/
>>>
>>>
>>
>> This is probably because you must
>>    (Object recompile: #perform:withArguments:)
>>
>
> The 1.3 core image was recompiled completely around 13020...
>
>        Marcus
>
>
> --
> Marcus Denker  -- http://www.marcusdenker.de
> INRIA Lille -- Nord Europe. Team RMoD.
>
>

>
> On Feb 1, 2011, at 7:04 AM, Stéphane Ducasse wrote:
>
>> Nicolas
>>
>> We wanted to see the diff like in squeak (check the mails in september) but the squeaksource server would die under the
>> diff size to generate (sic lukas). So? Do you think that we are explicitly against squeak. If we ever reached this state of mind, this is
>> years that we passed it.
>>
>>> Maybe it's because the process only have appearances of quality, but
>>> doesn't really pay off.
>>
>> Why do you say that? We log all our bugs and actions. So you can take all the fixes for squeak if you want. This is not my goal in life.
>> Now we are more busy than average and sometimes opening a bug entry when you already pushed the code in the server
>> is subject to missing some parts. But this is life.
>
>
> Another aspect: Every 100% regid requirement kills a process. We tried that in Squeak in the past. E.g. at one point, people
> said we should *require* tests and a code review before adding a fix. Result: complete standstill. Yes, these things are *nice*
> and they should be done more often, but as soon as you require them, nothing will happen.
>
> The same with deprecation: Yes, we want to provide deprecation for one release for easy migration. But this in turn can not
> be a law. There is so much cruft and so little structure (API vs. internal methods undefined), that one can not move if a strict
> rule is adopted.
>
> Strict rules kills human processes.
>
>        Marcus
>

> Why is that ?
> - squeak people are sobing pharoers
> - squeak people are too few to achieve this task
> - there is nothing interesting happening in Pharo
> No no, please don't answer, I innoculate this bullshit intentionnally
> to vaccine this thread against further crap.
>
> What IMO is the main explanation is this:
> - it's very easy to cherry pick squeak changes thanks to trunk: diff
> messages, while there is nothing equivalent in Pharo.
>
> Just browsing Squeak/Pharo diffs, it's easy to recognize text
> copy/pasted via web with tabs changed in spaces.
> Also the pharo issue tracker is full of these.
> This gives some clues.
>
> This is a very good thing that patches can be shared. But why not the
> other way around ?
> This is surprising because:
> - 1) Pharo is very active these days.
> - 2) Pharo was apparently setting a higher quality hurdle by forcing
> each modification to be traced
>      ( http://code.google.com/p/pharo/issues )
> So we could have expected more fixes coming from Pharo.
>
> Maybe it's because the process only have appearances of quality, but
> doesn't really pay off.
> Maybe I had some bad luck with
> http://code.google.com/p/pharo/issues/detail?id=3468

> 2011/2/1 Marcus Denker <[hidden email]>:
>>>
>>> Maybe I had some bad luck with
>>> http://code.google.com/p/pharo/issues/detail?id=3468
>>> Or is there many examples of issues closed without a clue ?
>>
>> In a case like that, the changeset was just merged in the release.
>>
>> The test is failing, as you can see:
>>
>> https://pharo-ic.lille.inria.fr/hudson/job/Pharo%20Core%201.3/lastCompletedBuild/testReport/KernelTests.Methods/CompiledMethodTest/testPerformInSuperclassCanExecutelongMethodWithTemps/
>>
>>
>
> This is probably because you must
>    (Object recompile: #perform:withArguments:)

>
> Nicolas
>
>>
>> --
>> Marcus Denker  -- http://www.marcusdenker.de
>> INRIA Lille -- Nord Europe. Team RMoD.
>>
>>
>>
>
>

>
> On Feb 1, 2011, at 7:04 AM, Stéphane Ducasse wrote:
>
>> Nicolas
>>
>> We wanted to see the diff like in squeak (check the mails in september) but the squeaksource server would die under the
>> diff size to generate (sic lukas). So? Do you think that we are explicitly against squeak. If we ever reached this state of mind, this is
>> years that we passed it.
>>
>>> Maybe it's because the process only have appearances of quality, but
>>> doesn't really pay off.
>>
>> Why do you say that? We log all our bugs and actions. So you can take all the fixes for squeak if you want. This is not my goal in life.
>> Now we are more busy than average and sometimes opening a bug entry when you already pushed the code in the server
>> is subject to missing some parts. But this is life.
>
>
> Another aspect: Every 100% regid requirement kills a process. We tried that in Squeak in the past. E.g. at one point, people
> said we should *require* tests and a code review before adding a fix. Result: complete standstill. Yes, these things are *nice*
> and they should be done more often, but as soon as you require them, nothing will happen.
>
> The same with deprecation: Yes, we want to provide deprecation for one release for easy migration. But this in turn can not
> be a law. There is so much cruft and so little structure (API vs. internal methods undefined), that one can not move if a strict
> rule is adopted.
>
> Strict rules kills human processes.
>