openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Phipps <>
Subject Re: OOO and LibreOffice.
Date Thu, 07 Jul 2011 14:29:24 GMT
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.

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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message