On 1 February 2011 01:47, Nicolas Cellier <[email protected]> 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.
