You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by IngridvdM <In...@gmx-topmail.de> on 2011/08/03 08:45:58 UTC
Re: OOO340 to svn - directory setup
Am 03.08.2011 08:12, schrieb Jürgen Schmidt:
> On Wed, Aug 3, 2011 at 12:28 AM, Eike Rathke<oo...@erack.de> wrote:
>
>> Hi IngridvdM,
>>
>> On Tuesday, 2011-08-02 20:17:52 +0200, IngridvdM wrote:
>>
>>>> The Hg archive should simply replicate the current structure at OOo,
>>>> also for ease of adding in pending CWSs as branches, so a separate l10n
>>>> repository.
>>>>
>>> Another good argument to separate l10n from trunk was given in an
>>> earlier thread: This way it is easier for developers to get only
>>> what they will need usually and spare the extra time and space.
>>>
>>> I think this is a good argument and I wonder whether we shouldn't be
>>> prepared to identify more such stuff - for example the binfilter.
>>
>> The problem with binfilter is that it depends on modules not in
>> binfilter, changing them incompatibly may entail changes necessary to
>> binfilter, those changes should be in one changeset, which I think is
>> not possible when not in trunk, insights anyone?
>>
>>
> well binfilter is maybe not the best example because in the long term we
> should think about the elimination of binfilter completely. Announcing the
> end of life of these filters, then allow the import only for some time and
> the next step is to drop it ...
>
Ok agreed, binfilter is not the best example.
But what about the general idea to have a second directory where we can
place all the stuff that is not needed to build the main office (so not
needed in the usual day to day work of a code developer), but anyhow
belongs to the product and to each codeline/release.
Maybe templates or some extensions could qualify for this stuff. Maybe
we have nothing right now but my point is, if we identify such things
later I do not want to clutter the directory structure with more and
more directories next to trunk.
I think even that it would be more natural to have those main office
components and the extras components both within trunk. That should also
ease the creation of release branches.
So another suggestion for the directory setup:
ooo/trunk/main
with all the other main office modules
ooo/trunk/main/sw (writer)
ooo/trunk/main/sc (calc)
ooo/trunk/main/sd (draw)
ooo/trunk/main/chart2 (chart)
...
ooo/trunk/extras
with l10n and maybe more stuff later
ooo/trunk/extras/l10n
ooo/tags/...
ooo/branches/...
this could look like this for example
ooo/branches/R3_4/main
ooo/branches/R3_4/extras
ooo/branches/R3_4_1/main
ooo/branches/R3_4_1/extras
ooo/site/...
Kind regards,
Ingrid
> Juergen
>
>
>
>> Eike
>>
>> --
>> PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
>> Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
>>
>
Re: OOO340 to svn - directory setup
Posted by Jürgen Schmidt <jo...@googlemail.com>.
On Wed, Aug 3, 2011 at 8:45 AM, IngridvdM <In...@gmx-topmail.de> wrote:
> Am 03.08.2011 08:12, schrieb Jürgen Schmidt:
>
>> On Wed, Aug 3, 2011 at 12:28 AM, Eike Rathke<oo...@erack.de> wrote:
>>
>> Hi IngridvdM,
>>>
>>> On Tuesday, 2011-08-02 20:17:52 +0200, IngridvdM wrote:
>>>
>>> The Hg archive should simply replicate the current structure at OOo,
>>>>> also for ease of adding in pending CWSs as branches, so a separate l10n
>>>>> repository.
>>>>>
>>>>> Another good argument to separate l10n from trunk was given in an
>>>> earlier thread: This way it is easier for developers to get only
>>>> what they will need usually and spare the extra time and space.
>>>>
>>>> I think this is a good argument and I wonder whether we shouldn't be
>>>> prepared to identify more such stuff - for example the binfilter.
>>>>
>>>
>>> The problem with binfilter is that it depends on modules not in
>>> binfilter, changing them incompatibly may entail changes necessary to
>>> binfilter, those changes should be in one changeset, which I think is
>>> not possible when not in trunk, insights anyone?
>>>
>>>
>>> well binfilter is maybe not the best example because in the long term we
>> should think about the elimination of binfilter completely. Announcing the
>> end of life of these filters, then allow the import only for some time and
>> the next step is to drop it ...
>>
>> Ok agreed, binfilter is not the best example.
> But what about the general idea to have a second directory where we can
> place all the stuff that is not needed to build the main office (so not
> needed in the usual day to day work of a code developer), but anyhow belongs
> to the product and to each codeline/release.
> Maybe templates or some extensions could qualify for this stuff. Maybe we
> have nothing right now but my point is, if we identify such things later I
> do not want to clutter the directory structure with more and more
> directories next to trunk.
>
> I think even that it would be more natural to have those main office
> components and the extras components both within trunk. That should also
> ease the creation of release branches.
> So another suggestion for the directory setup:
>
> ooo/trunk/main
> with all the other main office modules
> ooo/trunk/main/sw (writer)
> ooo/trunk/main/sc (calc)
> ooo/trunk/main/sd (draw)
> ooo/trunk/main/chart2 (chart)
> ...
> ooo/trunk/extras
> with l10n and maybe more stuff later
> ooo/trunk/extras/l10n
>
> ooo/tags/...
> ooo/branches/...
> this could look like this for example
> ooo/branches/R3_4/main
> ooo/branches/R3_4/extras
> ooo/branches/R3_4_1/main
> ooo/branches/R3_4_1/extras
>
> ooo/site/...
>
i would definitely support such a structure but on the other side the
question is if it would be enough to trigger optional parts with appropriate
configure switches, e.g. mysql-connector-enabled. Extensions are somewhat
special because they can be provided as standalone extension packages or
they can be bundled. And therefor both directory structures can make sense.
But for the i18n stuff i would definitely separate it as you propose because
we have the main language English in the main repository. And of course as
you already mentioned we can identify useful parts that should belong to the
extra repo later.
Juergen
>
> Kind regards,
> Ingrid
>
> Juergen
>>
>>
>>
>> Eike
>>>
>>> --
>>> PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
>>> Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD
>>>
>>>
>>
>
Re: OOO340 to svn - directory setup
Posted by Ingrid von der Mehden <In...@gmx-topmail.de>.
Am 03.08.2011 21:23, schrieb Mathias Bauer:
> On 03.08.2011 10:38, IngridvdM wrote:
>
>> Am 03.08.2011 10:24, schrieb Stephan Bergmann:
>>> On Aug 3, 2011, at 8:45 AM, IngridvdM wrote:
>>>> Ok agreed, binfilter is not the best example.
>>>> But what about the general idea to have a second directory where we can place all the stuff that is not needed to build the main office (so not needed in the usual day to day work of a code developer), but anyhow belongs to the product and to each codeline/release.
>>>> Maybe templates or some extensions could qualify for this stuff. Maybe we have nothing right now but my point is, if we identify such things later I do not want to clutter the directory structure with more and more directories next to trunk.
>>>
>>> Remember, with svn the complete directory structure can always be changed. So I see no need to come up with a perfect solution up front.
>>>
>> It is not only svn to think about. When it comes to building and
>> packaging and creation of release branches there is easily a lot of
>> scripting involved. Those things are often not so nice to change
>> afterwards. So may we can think a day or two about a good directory
>> structure before. ;-)
>
> As Stephan wrote, the structure can be changed easily afterwards.
> Building and packaging should follow dependencies (after all that was
> the idea of our new build environment) and so the directory structure is
> of second order importance.
>
> Besides that I agree that moving parts that are already known to be no
> part of the regular OOo installation set into separate top level
> directories makes sense. We just shouldn't dive too deep into that now.
>
Agreed and it wasn't my point to dive deep into which single parts
should be moved around. My point was only to prepare that we can move
parts with less hassle later. I just want to prepare the target
directory for such moves. Nothing more, nothing less. It is really a
quite simple and quick question that could be solved right now.
What directory setup do you prefer and why:
1)
ooo/trunk/main/sw
ooo/trunk/extras/l10n
or 2)
ooo/trunk/sw
ooo/l10n
I would prefer 1) because it accumulates all that belongs to the trunk
code line in the trunk directory, while still allowing to easily check
out only one directory for the typical day to day code development.
Collecting more and more directories outside trunk that logically would
belong to trunk, will complicate the creation of release branches
unnecessarily. In addition something that is not logically is a problem
in itself, because it confuses people.
Kind regards,
Ingrid
> Regards,
> Mathias
>
Re: OOO340 to svn - directory setup
Posted by "Pedro F. Giffuni" <gi...@tutopia.com>.
Hi;
--- On Wed, 8/3/11, Mathias Bauer wrote:
...
>
> As Stephan wrote, the structure can be changed easily
> afterwards.
> Building and packaging should follow dependencies (after
> all that was the idea of our new build environment) and
> so the directory structure is of second order importance.
>
> Besides that I agree that moving parts that are already
> known to be no part of the regular OOo installation set
> into separate top level directories makes sense. We just
> shouldn't dive too deep into that now.
>
I agree.
Moving around the directory structure would break bugzilla
patches and make it difficult to merge some branches. We
should really wait a bit and let the dust settle first.
cheers,
Pedro.
Re: OOO340 to svn - directory setup
Posted by Mathias Bauer <Ma...@gmx.net>.
On 03.08.2011 10:38, IngridvdM wrote:
> Am 03.08.2011 10:24, schrieb Stephan Bergmann:
>> On Aug 3, 2011, at 8:45 AM, IngridvdM wrote:
>>> Ok agreed, binfilter is not the best example.
>>> But what about the general idea to have a second directory where we can place all the stuff that is not needed to build the main office (so not needed in the usual day to day work of a code developer), but anyhow belongs to the product and to each codeline/release.
>>> Maybe templates or some extensions could qualify for this stuff. Maybe we have nothing right now but my point is, if we identify such things later I do not want to clutter the directory structure with more and more directories next to trunk.
>>
>> Remember, with svn the complete directory structure can always be changed. So I see no need to come up with a perfect solution up front.
>>
> It is not only svn to think about. When it comes to building and
> packaging and creation of release branches there is easily a lot of
> scripting involved. Those things are often not so nice to change
> afterwards. So may we can think a day or two about a good directory
> structure before. ;-)
As Stephan wrote, the structure can be changed easily afterwards.
Building and packaging should follow dependencies (after all that was
the idea of our new build environment) and so the directory structure is
of second order importance.
Besides that I agree that moving parts that are already known to be no
part of the regular OOo installation set into separate top level
directories makes sense. We just shouldn't dive too deep into that now.
Regards,
Mathias
Re: OOO340 to svn - directory setup
Posted by IngridvdM <In...@gmx-topmail.de>.
Am 03.08.2011 10:24, schrieb Stephan Bergmann:
> On Aug 3, 2011, at 8:45 AM, IngridvdM wrote:
>> Ok agreed, binfilter is not the best example.
>> But what about the general idea to have a second directory where we can place all the stuff that is not needed to build the main office (so not needed in the usual day to day work of a code developer), but anyhow belongs to the product and to each codeline/release.
>> Maybe templates or some extensions could qualify for this stuff. Maybe we have nothing right now but my point is, if we identify such things later I do not want to clutter the directory structure with more and more directories next to trunk.
>
> Remember, with svn the complete directory structure can always be changed. So I see no need to come up with a perfect solution up front.
>
It is not only svn to think about. When it comes to building and
packaging and creation of release branches there is easily a lot of
scripting involved. Those things are often not so nice to change
afterwards. So may we can think a day or two about a good directory
structure before. ;-)
Kind regards,
Ingrid
> -Stephan
Re: OOO340 to svn - directory setup
Posted by Stephan Bergmann <st...@googlemail.com>.
On Aug 3, 2011, at 8:45 AM, IngridvdM wrote:
> Ok agreed, binfilter is not the best example.
> But what about the general idea to have a second directory where we can place all the stuff that is not needed to build the main office (so not needed in the usual day to day work of a code developer), but anyhow belongs to the product and to each codeline/release.
> Maybe templates or some extensions could qualify for this stuff. Maybe we have nothing right now but my point is, if we identify such things later I do not want to clutter the directory structure with more and more directories next to trunk.
Remember, with svn the complete directory structure can always be changed. So I see no need to come up with a perfect solution up front.
-Stephan