On 7 July 2011 16:05, Rob Weir <apa...@robweir.com> wrote: > On Thu, Jul 7, 2011 at 10:29 AM, Simon Phipps <si...@webmink.com> wrote: > > 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. > > > > That would work, of course. But my point was more of the trade-offs. > Changing a million lines of code to improve performance a small amount > has an immediate, tangible but small user benefit, but also has the > side effect of making future collaboration more difficult. This > includes collaboration that down the road could have lead to even > greater user benefits. > > But I do have my views on "code cleanup" colored by my own personal > experience. Every project I've seen that undertook "code cleanup" was > very soon canceled. The insight is this: if a project has nothing > better to do, no more pressing customer demands, no greater innovation > to bring to market than changing code comments, then it is near death > already. Of course, that is only a corporate programmer view of > things. In an open source project I can see the benefits of having > "easy tasks" to introduce new developers to the code and the > development tools. That is a different situation. But I'd look for a > balance: easy tasks that don't churn the codebase and have immediate > user impact. I think we'd all agree that this is the ideal.
I suppose it also depends on what you mean by code clean up. If for example the LibO people had identified say 2 meg of redundant code, ie stuff that doesn't do anything useful and they removed it and know it has not broken anything else it seems to me that would be an easy win. Even if we established there was no such code worth removing, it is something. I don't see any licensing problems with removing stuff so it is a non-controversial starting point that gets people working together. (Ok in practice some smaller replacements might be needed but I'm considering the ideal situation) I can see months of argument on larger scale issues that never had a chance of getting anything practical done so I'm working on the basis that something is better than nothing and making a start that is positive gets the possibility of incremental improvement. -- Ian Ofqual Accredited IT Qualifications (The Schools ITQ) www.theINGOTs.org +44 (0)1827 305940 The Learning Machine Limited, Reg Office, 36 Ashby Road, Tamworth, Staffordshire, B79 8AQ. Reg No: 05560797, Registered in England and Wales.
