[Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
nicolas.cellier.aka.nice at gmail.com
Tue Feb 1 01:47:00 CET 2011
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
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
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.
More information about the Pharo-project