extract GSI Check into an own repository

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

extract GSI Check into an own repository

Peter Kovacs-3
Hello all,


In Order to automate the Translation Process Mechtilde has requested to
extract the GSI Check into an Own Repository.

GSI Check has an own Versioning, the current Version in the Repo is
named 1.9.

So It makes totally sense to extract the Code into an own Repository.


I created a work Package on Jira:

https://issues.apache.org/jira/browse/OPENOFFICE-183#


Any Objection with this endeavor?

(If not)

Any tasks to add to this work package?


If the work package is accepted I create a bugzilla report for the
extraction.


All the Best

Peter


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: extract GSI Check into an own repository

Dave Fisher-2
Hi Peter,

Your issue assumes that developers know where the gsicheck code is in the repository. I haven’t a clue and therefore can’t even comment on whether or not a new repository makes sense.

Regards,
Dave

> On May 29, 2020, at 10:20 AM, Peter Kovacs <[hidden email]> wrote:
>
> Hello all,
>
>
> In Order to automate the Translation Process Mechtilde has requested to extract the GSI Check into an Own Repository.
>
> GSI Check has an own Versioning, the current Version in the Repo is named 1.9.
>
> So It makes totally sense to extract the Code into an own Repository.
>
>
> I created a work Package on Jira:
>
> https://issues.apache.org/jira/browse/OPENOFFICE-183#
>
>
> Any Objection with this endeavor?
>
> (If not)
>
> Any tasks to add to this work package?
>
>
> If the work package is accepted I create a bugzilla report for the extraction.
>
>
> All the Best
>
> Peter
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: extract GSI Check into an own repository

Peter Kovacs-3
Hi Dave,


I am figuring out what GSICheck needs. So I already have an overview. is
you look for files gsicheck you will find it.

The Codebase is really small, and it uses following Classes from AOO:


I see following Includes:

#include "precompiled_l10ntools.hxx"
#include <stdio.h>
#include <tools/fsys.hxx>
#include <tools/stream.hxx>
#include <tools/list.hxx>

// local includes
#include "tagtest.hxx"
#include "gsicheck.hxx"

#include "precompiled_l10ntools.hxx"
#include <tools/string.hxx>
#include "tagtest.hxx"

#if OSL_DEBUG_LEVEL > 1
#include <stdio.h>
#endif

#include "gsicheck.hxx"

#include <tools/string.hxx>
#include <tools/list.hxx>
#include <hash_map> /* std::hashmap*/
#include <rtl/string.h>


Am 29.05.20 um 19:28 schrieb Dave Fisher:

> Hi Peter,
>
> Your issue assumes that developers know where the gsicheck code is in the repository. I haven’t a clue and therefore can’t even comment on whether or not a new repository makes sense.
>
> Regards,
> Dave
>
>> On May 29, 2020, at 10:20 AM, Peter Kovacs <[hidden email]> wrote:
>>
>> Hello all,
>>
>>
>> In Order to automate the Translation Process Mechtilde has requested to extract the GSI Check into an Own Repository.
>>
>> GSI Check has an own Versioning, the current Version in the Repo is named 1.9.
>>
>> So It makes totally sense to extract the Code into an own Repository.
>>
>>
>> I created a work Package on Jira:
>>
>> https://issues.apache.org/jira/browse/OPENOFFICE-183#
>>
>>
>> Any Objection with this endeavor?
>>
>> (If not)
>>
>> Any tasks to add to this work package?
>>
>>
>> If the work package is accepted I create a bugzilla report for the extraction.
>>
>>
>> All the Best
>>
>> Peter
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: extract GSI Check into an own repository

Dave Fisher-2
Hi -

I was asking where it was:

/trunk/main/l10ntools/source/makefile.mk
/trunk/main/l10ntools/source/gsicheck.cxx
/trunk/main/solenv/bin/gsicheck

There are several tools in l10tools …

What is the advantage of a separate repository? And is gsicheck the only candidate?

Regards,
Dave

> On May 29, 2020, at 11:01 AM, Peter Kovacs <[hidden email]> wrote:
>
> Hi Dave,
>
>
> I am figuring out what GSICheck needs. So I already have an overview. is you look for files gsicheck you will find it.
>
> The Codebase is really small, and it uses following Classes from AOO:
>
>
> I see following Includes:
>
> #include "precompiled_l10ntools.hxx"
> #include <stdio.h>
> #include <tools/fsys.hxx>
> #include <tools/stream.hxx>
> #include <tools/list.hxx>
>
> // local includes
> #include "tagtest.hxx"
> #include "gsicheck.hxx"
>
> #include "precompiled_l10ntools.hxx"
> #include <tools/string.hxx>
> #include "tagtest.hxx"
>
> #if OSL_DEBUG_LEVEL > 1
> #include <stdio.h>
> #endif
>
> #include "gsicheck.hxx"
>
> #include <tools/string.hxx>
> #include <tools/list.hxx>
> #include <hash_map> /* std::hashmap*/
> #include <rtl/string.h>
>
>
> Am 29.05.20 um 19:28 schrieb Dave Fisher:
>> Hi Peter,
>>
>> Your issue assumes that developers know where the gsicheck code is in the repository. I haven’t a clue and therefore can’t even comment on whether or not a new repository makes sense.
>>
>> Regards,
>> Dave
>>
>>> On May 29, 2020, at 10:20 AM, Peter Kovacs <[hidden email]> wrote:
>>>
>>> Hello all,
>>>
>>>
>>> In Order to automate the Translation Process Mechtilde has requested to extract the GSI Check into an Own Repository.
>>>
>>> GSI Check has an own Versioning, the current Version in the Repo is named 1.9.
>>>
>>> So It makes totally sense to extract the Code into an own Repository.
>>>
>>>
>>> I created a work Package on Jira:
>>>
>>> https://issues.apache.org/jira/browse/OPENOFFICE-183#
>>>
>>>
>>> Any Objection with this endeavor?
>>>
>>> (If not)
>>>
>>> Any tasks to add to this work package?
>>>
>>>
>>> If the work package is accepted I create a bugzilla report for the extraction.
>>>
>>>
>>> All the Best
>>>
>>> Peter
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: extract GSI Check into an own repository

Mechtilde Stehmann-2
Hello Dave,

Am 29.05.20 um 20:44 schrieb Dave Fisher:

> Hi -
>
> I was asking where it was:
>
> /trunk/main/l10ntools/source/makefile.mk
> /trunk/main/l10ntools/source/gsicheck.cxx
> /trunk/main/solenv/bin/gsicheck
>
> There are several tools in l10tools …
>
> What is the advantage of a separate repository? And is gsicheck the only candidate?
the advantage will be to automate the translation process on the pootle
server without need of a complete build environment of AOO. So we need
the executable binary for the pootle server.

In former time (TM) we had it as aseparate tool to ccheck the *.sdf
files outside the build environment.

>
> Regards,
> Dave

Kind regards

--
Mechtilde Stehmann
## Apache OpenOffice
## Freie Office Suite für Linux, MacOSX, Windows und OS/2
## Debian Developer
## PGP encryption welcome
## F0E3 7F3D C87A 4998 2899  39E7 F287 7BBA 141A AD7F


signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: extract GSI Check into an own repository

Peter Kovacs-3
In reply to this post by Dave Fisher-2
In general:

I am not a big fan of the monolith structure AOO uses with storing
everything in one Repository.

I prefer to have small Repositories, with nice individual Release cycles
and modular main repo. They are easier to document, and maintain, or to
disembark and switch to other tools / libraries.

Smaller Repos are not as fearsome for newbies, in comparison to one big
repo. And it enforces a natural sustained architecture as is described
by experts like Robert C. Martin (Clean Architecture) or Carola
Lilienthal (German: Langlebige Software Architekturen; translates
sustained software architecture).

And my last general argument is, the smarter we set our build
environment to handle modularity, the easier it is for Distros to adopt
Apache OpenOffice. Distros are the best recruits for developers. We see
that in the support from FreeBSD, which made a lot of Bugfixing. Also
the OS/2 Development is a good support for our cause. I am sure that
there are more examples if we look back in history, which I have not
experienced.

This is of course  a long term vision.

Am 29.05.20 um 20:44 schrieb Dave Fisher:
> There are several tools in l10tools …
>
> What is the advantage of a separate repository?

Next to what Mechtilde described:

For me it is much more transparent, if we have it in a separate
repository. We could even provide a README what it does! That would be
an improvement.

> And is gsicheck the only candidate?

We have discussed to extract UNO and turn it into a library, with  an
own release cycle. (even incubate / seed it into an own Project.)

I see the same basic strategy that we discussed for UNO can be applied
to StarBasic, which makes this maybe with some modification interesting
for other developers, who do not have interest in AOO as such.

I have no overview which other application or potential libraries AOO
stores. So I personally would take this slow, step by step. With
GSICheck we have an immediate win, without being complicated to move.

Let us learn how to pull Releases from a Repo instead of the mechanism
we use now. That makes it easy to extract it now.



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: extract GSI Check into an own repository

Carl Marcum
Hi Peter,

On 5/29/20 7:41 PM, Peter Kovacs wrote:

> In general:
>
> I am not a big fan of the monolith structure AOO uses with storing
> everything in one Repository.
>
> I prefer to have small Repositories, with nice individual Release
> cycles and modular main repo. They are easier to document, and
> maintain, or to disembark and switch to other tools / libraries.
>
> Smaller Repos are not as fearsome for newbies, in comparison to one
> big repo. And it enforces a natural sustained architecture as is
> described by experts like Robert C. Martin (Clean Architecture) or
> Carola Lilienthal (German: Langlebige Software Architekturen;
> translates sustained software architecture).
>
> And my last general argument is, the smarter we set our build
> environment to handle modularity, the easier it is for Distros to
> adopt Apache OpenOffice. Distros are the best recruits for developers.
> We see that in the support from FreeBSD, which made a lot of
> Bugfixing. Also the OS/2 Development is a good support for our cause.
> I am sure that there are more examples if we look back in history,
> which I have not experienced.
>
> This is of course  a long term vision.

I agree that smaller projects work well for Git. Even down to one
artifact (think module) per sub-project.

I do that with my personal projects that have a handful of sub-projects
with Gradle builds but could that work with our build systems?

Thanks,
Carl

>
> Am 29.05.20 um 20:44 schrieb Dave Fisher:
>> There are several tools in l10tools …
>>
>> What is the advantage of a separate repository?
>
> Next to what Mechtilde described:
>
> For me it is much more transparent, if we have it in a separate
> repository. We could even provide a README what it does! That would be
> an improvement.
>
>> And is gsicheck the only candidate?
>
> We have discussed to extract UNO and turn it into a library, with an
> own release cycle. (even incubate / seed it into an own Project.)
>
> I see the same basic strategy that we discussed for UNO can be applied
> to StarBasic, which makes this maybe with some modification
> interesting for other developers, who do not have interest in AOO as
> such.
>
> I have no overview which other application or potential libraries AOO
> stores. So I personally would take this slow, step by step. With
> GSICheck we have an immediate win, without being complicated to move.
>
> Let us learn how to pull Releases from a Repo instead of the mechanism
> we use now. That makes it easy to extract it now.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: extract GSI Check into an own repository

Peter Kovacs-3

Am 04.06.20 um 12:48 schrieb Carl Marcum:

> Hi Peter,
>
> On 5/29/20 7:41 PM, Peter Kovacs wrote:
>> In general:
>>
>> I am not a big fan of the monolith structure AOO uses with storing
>> everything in one Repository.
>>
>> I prefer to have small Repositories, with nice individual Release
>> cycles and modular main repo. They are easier to document, and
>> maintain, or to disembark and switch to other tools / libraries.
>>
>> Smaller Repos are not as fearsome for newbies, in comparison to one
>> big repo. And it enforces a natural sustained architecture as is
>> described by experts like Robert C. Martin (Clean Architecture) or
>> Carola Lilienthal (German: Langlebige Software Architekturen;
>> translates sustained software architecture).
>>
>> And my last general argument is, the smarter we set our build
>> environment to handle modularity, the easier it is for Distros to
>> adopt Apache OpenOffice. Distros are the best recruits for
>> developers. We see that in the support from FreeBSD, which made a lot
>> of Bugfixing. Also the OS/2 Development is a good support for our
>> cause. I am sure that there are more examples if we look back in
>> history, which I have not experienced.
>>
>> This is of course  a long term vision.
>
> I agree that smaller projects work well for Git. Even down to one
> artifact (think module) per sub-project.
>
> I do that with my personal projects that have a handful of
> sub-projects with Gradle builds but could that work with our build
> systems?

I think we can work around the Issue by putting creating tar.gz files,
and include them into our boots trapper.

In the long run, I think, it would be super cool if our SCONs build
system has some package manager capabilities like Maven or portage.

If you never heard of portage, take a look at it. it is a super cool
package manager of Gentoo, that builds Application at install using
directly the upstream code.

Gentoo was awesoem (crazy) times. :)

At least it is my dream to have simple tools like those for building.
(And provide simple export tools for distros. If Gentoo ships code files
for AOO package instead in doing in by binary, I will party.)


All the best

Peter



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]