openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rob Weir <>
Subject Re: OOO and LibreOffice.
Date Thu, 07 Jul 2011 15:05:41 GMT
On Thu, Jul 7, 2011 at 10:29 AM, Simon Phipps <> wrote:
> On Thu, Jul 7, 2011 at 2:59 PM, Rob Weir <> wrote:
>> On Thu, Jul 7, 2011 at 8:49 AM, Simon Phipps <> 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.

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

View raw message