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