On Thu, Jul 7, 2011 at 2:59 PM, Rob Weir <apa...@robweir.com> wrote: > On Thu, Jul 7, 2011 at 8:49 AM, Simon Phipps <si...@webmink.com> wrote: > > > > On 7 Jul 2011, at 13:17, Mathias Bauer wrote: > >> > >> This would at least require that someone having done that at LO would > >> contribute a patch for OOo. Having a patch could help to do the removal > >> in the same way as in LO. That could make sure that afterwards the code > >> bases became more similar and merging of code changes could become > >> easier in the future. Perhaps that's something you should suggest on the > >> LO dev list. > >> > >> (I hope this suggestion isn't seen as an offense - really, if you are > >> asking for patches you have to ask those who did the work, not those who > >> might receive it.) > > > > Not an offense, no, although we might consider it's unlikely that a > volunteer in any project would want to do this sort of work twice. We may > instead want to encourage new Apache volunteers who want to join the > development activity but need to learn how everything works to create > patches that mirror the cleanup at LO, as a route to learning about AOOo. > > > > If one wished to make it impossible to ever collaborate at the source > code level between two projects, to frustrate attempts at automated > merging, then the ideal way of doing this would be to change millions > of lines of code for trivial reasons, to "improve" variable names, > indentation, remove code that the preprocessor was already removing, > etc. If you want to put two nails in the coffin of collaboration, > then do such "clean up" twice, independently and in two different > repositories, ensuring millions of future merge conflicts. >
Hence the desire to see the work that has already been done on LO contributed here, rather than a related-but-different cleanup. > > Of course, such clean up is an easy way to get impressive numbers for > patches and developers. But on balance, I'd avoid the impulse to > churn the code unnecessarily. I like the idea of "Easy Tasks". But > let's make them be real tasks. >
