[Pharo-project] Tracing bugs/corrections/regressions ... in Pharo
stephane.ducasse at inria.fr
Tue Feb 1 06:57:40 CET 2011
The diff algorithm of mc is good.
Now miguel we can talk about that. It will not happen if nobody build it for real.
Sorry to be a pain in the ass but this is reality.
When something works (because it works - look at Moose) then you need a lot of effort
to move to the next level.
> 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
> 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?
> 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
>> 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.
> Miguel Cobá
More information about the Pharo-project