[Pharo-project] Tracing bugs/corrections/regressions ... in Pharo

Igor Stasenko siguctua at gmail.com
Tue Feb 1 14:42:48 CET 2011


On 1 February 2011 01:47, Nicolas Cellier
<nicolas.cellier.aka.nice at gmail.com> wrote:
> The fact is that, while many patches find their way from Squeak to
> Pharo, very few take the other way.
>

Frankly, i had the opposite impression.
For instance, Sets with nil already have more than year in Squeak,
but still didn't found their way into Pharo.


> 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

i was proposed this fix for squeak and pharo both, months before,
because NativeBoost
were dependent on that to work correctly, because it was heavily
exploiting #perform: primitive
for retrying the same method after first invocation when there was no
native code generated yet,
and primitive failed because of that.
But i weren't able to force it to be made into both forks.. because
certainly i was busy with other stuff,
so instead of pushing fix to both forks, i just made a changeset and
put it into NB site.
In that way i made sure, that no matter if fix is integrated or not, NB works :)

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

I think an upcoming Ring (yeah , to rule them all) or Torch? project
will help addressing this issue.
But i can't shed light details on it, because i don't know..


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

I am one, who would certainly be happy too, to see a interchange
between Pharo and Squeak to be easy.
I can only say, that this is because two camps using different
development process..
and not because of some intentionally political attitude.


Nicolas, i encourage you (and others) to come up with initiative, to
establish a process , or write down rules/guidelines,
how to cherrypick the code between forks.
This would help to both camps, so its worth to do.

> Nicolas
>
>



-- 
Best regards,
Igor Stasenko AKA sig.




More information about the Pharo-project mailing list