On Wed, Aug 3, 2011 at 8:45 AM, IngridvdM <ingrid...@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<o...@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 >>> >>> >> >
