[discussion] svn migration plan

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

Re: [discussion] svn migration plan

Marcus (OOo)
Am 28.07.19 um 20:29 schrieb Matthias Seidel:
> Am 28.07.19 um 20:12 schrieb Marcus:
>> Am 27.07.19 um 13:45 schrieb Matthias Seidel:
>>> Am 23.07.19 um 11:08 schrieb Matthias Seidel:
>>>> Am 21.07.19 um 12:27 schrieb Peter Kovacs:

Hi Matthias,

>>>>> back to the initial discussion.
>>>> Obviously you didn't read my mail until the end...
>>>>> I have created the request. Simply requesting that trunc, branch and
>>>>> tags are moved. All other folders should remain as is.
>>>>>
>>>>> I hope this suits everyone.
>>>> Do we have the necessary code changes ready?
>>>>
>>>> We use the SVN revision in our About dialog, and for creating the
>>>> source
>>>> builds. This has to be adapted when we switch to git.
>>>> Using the git hash (short or long) instead? This should have been
>>>> discussed...
>>>
>>> Given the lack of response, this has yet to be investigated...
>>>
>>> Meanwhile my builds on Windows are now done from git. Additionally I did
>>> checkout from git on ArcaOS (OS/2) without problems.
>>>
>>> @Marcus:
>>> The switch to git hash (instead of SVN revision) would require some
>>> changes in the logic of our download page. Can you evaluate?
>>
>> I don't see any real dependency between our download webapge and SVN;
>> except with the writen SVN rev. with fixed text on the HTML webpage:
>>
>> https://www.openoffice.org/download/index.html
>>
>> Release: Milestone AOO416m1 | Build ID 9790 | SVN r1844436 | Released
>> 2018-11-18 | Release Notes
>>
>> Can you tell me how a Git hash on our pache servers looks like? If
>> there is no big difference in size, then it should be a problem.
>
> Exactly! There is a short and a long git hash. Which one we choose
> hasn't been discussed yet. We would have to take either one for new
> builds and leave the SVN revision for the old builds.
>
> I just wanted to make sure that we think about such topics *before* we
> switch.

sure, but please tell me how a Git hash (short and long) looks like.
Then we can judge if it fits.

>> *But:*
>>
>> The biggest change is for the CMS. Does it support also Git? If not,
>> then we shouldn't change also the website repo to Git as nobody of us
>> (IMHO) can support this change.
> As I understand it Peter only wants to switch trunk, branches and tags
> to Git, not (yet) the CMS (site and ooo-site).

Let's discuss this in the other thread.

Thanks

Marcus



>>>> BTW: My latest builds are based on a checkout from git, no problems
>>>> so far.
>>>>
>>>>> Please review:
>>>>>
>>>>> https://issues.apache.org/jira/browse/INFRA-18773
>>>>>
>>>>> On 21.07.19 01:42, Peter Kovacs wrote:
>>>>>> Hi brane,
>>>>>>
>>>>>> The threads are linked in my first post.
>>>>>>
>>>>>> It is for me a workflow thing.
>>>>>> I need a decentral versioning system instead of a central one.
>>>>>> And I want github as public patch interface.
>>>>>> Both do not work with svn.
>>>>>>
>>>>>> I add a reason that I heard at work. Young people do not know svn.
>>>>>> They expect to work with git.
>>>>>> IMHO it is  a dumb argument but in my country the fresh people
>>>>>> from university are dictating a little their working environment.
>>>>>>
>>>>>> Ahh and git has major pains reading OpenOffice svn repo. So I
>>>>>> can't even use git as a client.
>>>>>>
>>>>>> All the best.
>>>>>> Peter
>>>>>>
>>>>>> Am 21. Juli 2019 01:17:32 MESZ schrieb "Branko Čibej"
>>>>>> <[hidden email]>:
>>>>>>> Hi AOO devs,
>>>>>>>
>>>>>>> I just stumbled onto this thread. Coming from subversion.a.o, I'm
>>>>>>> saddened
>>>>>>> to see you've decided to switch to Git. Could someone please
>>>>>>> summarise
>>>>>>> the
>>>>>>> reasons for this decision, or give me a link to the discussion in
>>>>>>> the
>>>>>>> mail
>>>>>>> archives? I'd very much like to know if it was caused by some
>>>>>>> specific
>>>>>>> problem or missing feature in Subversion that we may be able to
>>>>>>> address.


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

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] svn migration plan

Matthias Seidel
Hi Marcus,

Am 28.07.19 um 23:12 schrieb Marcus:

> Am 28.07.19 um 20:29 schrieb Matthias Seidel:
>> Am 28.07.19 um 20:12 schrieb Marcus:
>>> Am 27.07.19 um 13:45 schrieb Matthias Seidel:
>>>> Am 23.07.19 um 11:08 schrieb Matthias Seidel:
>>>>> Am 21.07.19 um 12:27 schrieb Peter Kovacs:
>
> Hi Matthias,
>
>>>>>> back to the initial discussion.
>>>>> Obviously you didn't read my mail until the end...
>>>>>> I have created the request. Simply requesting that trunc, branch and
>>>>>> tags are moved. All other folders should remain as is.
>>>>>>
>>>>>> I hope this suits everyone.
>>>>> Do we have the necessary code changes ready?
>>>>>
>>>>> We use the SVN revision in our About dialog, and for creating the
>>>>> source
>>>>> builds. This has to be adapted when we switch to git.
>>>>> Using the git hash (short or long) instead? This should have been
>>>>> discussed...
>>>>
>>>> Given the lack of response, this has yet to be investigated...
>>>>
>>>> Meanwhile my builds on Windows are now done from git. Additionally
>>>> I did
>>>> checkout from git on ArcaOS (OS/2) without problems.
>>>>
>>>> @Marcus:
>>>> The switch to git hash (instead of SVN revision) would require some
>>>> changes in the logic of our download page. Can you evaluate?
>>>
>>> I don't see any real dependency between our download webapge and SVN;
>>> except with the writen SVN rev. with fixed text on the HTML webpage:
>>>
>>> https://www.openoffice.org/download/index.html
>>>
>>> Release: Milestone AOO416m1 | Build ID 9790 | SVN r1844436 | Released
>>> 2018-11-18 | Release Notes
>>>
>>> Can you tell me how a Git hash on our pache servers looks like? If
>>> there is no big difference in size, then it should be a problem.
>>
>> Exactly! There is a short and a long git hash. Which one we choose
>> hasn't been discussed yet. We would have to take either one for new
>> builds and leave the SVN revision for the old builds.
>>
>> I just wanted to make sure that we think about such topics *before* we
>> switch.
>
> sure, but please tell me how a Git hash (short and long) looks like.
> Then we can judge if it fits.
Looking at Damjans last commit:
https://github.com/apache/openoffice/commit/779db4a01a7b0297a1573645c842007eab71ab85

779db4a01a7b0297a1573645c842007eab71ab85 is the long hash

779db4a0 would be the short

See also:

https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection

Our git is mirrored from SVN and contains:
git-svn-id: https://svn.apache.org/repos/asf/openoffice/trunk@1863883

1863883 is the SVN revision which is taken when building from our git at
the moment.

I *think* the code is in here:
main/solenv/bin/modules/SvnRevision.pm

That said, I am far away from being a specialist on this topic. ;-)

>
>>> *But:*
>>>
>>> The biggest change is for the CMS. Does it support also Git? If not,
>>> then we shouldn't change also the website repo to Git as nobody of us
>>> (IMHO) can support this change.
>> As I understand it Peter only wants to switch trunk, branches and tags
>> to Git, not (yet) the CMS (site and ooo-site).
>
> Let's discuss this in the other thread.
Which other thread?

Matthias

>
> Thanks
>
> Marcus
>
>
>
>>>>> BTW: My latest builds are based on a checkout from git, no problems
>>>>> so far.
>>>>>
>>>>>> Please review:
>>>>>>
>>>>>> https://issues.apache.org/jira/browse/INFRA-18773
>>>>>>
>>>>>> On 21.07.19 01:42, Peter Kovacs wrote:
>>>>>>> Hi brane,
>>>>>>>
>>>>>>> The threads are linked in my first post.
>>>>>>>
>>>>>>> It is for me a workflow thing.
>>>>>>> I need a decentral versioning system instead of a central one.
>>>>>>> And I want github as public patch interface.
>>>>>>> Both do not work with svn.
>>>>>>>
>>>>>>> I add a reason that I heard at work. Young people do not know svn.
>>>>>>> They expect to work with git.
>>>>>>> IMHO it is  a dumb argument but in my country the fresh people
>>>>>>> from university are dictating a little their working environment.
>>>>>>>
>>>>>>> Ahh and git has major pains reading OpenOffice svn repo. So I
>>>>>>> can't even use git as a client.
>>>>>>>
>>>>>>> All the best.
>>>>>>> Peter
>>>>>>>
>>>>>>> Am 21. Juli 2019 01:17:32 MESZ schrieb "Branko Čibej"
>>>>>>> <[hidden email]>:
>>>>>>>> Hi AOO devs,
>>>>>>>>
>>>>>>>> I just stumbled onto this thread. Coming from subversion.a.o, I'm
>>>>>>>> saddened
>>>>>>>> to see you've decided to switch to Git. Could someone please
>>>>>>>> summarise
>>>>>>>> the
>>>>>>>> reasons for this decision, or give me a link to the discussion in
>>>>>>>> the
>>>>>>>> mail
>>>>>>>> archives? I'd very much like to know if it was caused by some
>>>>>>>> specific
>>>>>>>> problem or missing feature in Subversion that we may be able to
>>>>>>>> address.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [discussion] svn migration plan

Peter Kovacs-3
A different suggestion we use the git commit count. The command is:

|git rev-list --all --count It will deliver something that looks similar
to the svn number we already use. All the Best Peter |

On 29.07.19 00:17, Matthias Seidel wrote:

> Hi Marcus,
>
> Am 28.07.19 um 23:12 schrieb Marcus:
>> Am 28.07.19 um 20:29 schrieb Matthias Seidel:
>>> Am 28.07.19 um 20:12 schrieb Marcus:
>>>> Am 27.07.19 um 13:45 schrieb Matthias Seidel:
>>>>> Am 23.07.19 um 11:08 schrieb Matthias Seidel:
>>>>>> Am 21.07.19 um 12:27 schrieb Peter Kovacs:
>> Hi Matthias,
>>
>>>>>>> back to the initial discussion.
>>>>>> Obviously you didn't read my mail until the end...
>>>>>>> I have created the request. Simply requesting that trunc, branch and
>>>>>>> tags are moved. All other folders should remain as is.
>>>>>>>
>>>>>>> I hope this suits everyone.
>>>>>> Do we have the necessary code changes ready?
>>>>>>
>>>>>> We use the SVN revision in our About dialog, and for creating the
>>>>>> source
>>>>>> builds. This has to be adapted when we switch to git.
>>>>>> Using the git hash (short or long) instead? This should have been
>>>>>> discussed...
>>>>> Given the lack of response, this has yet to be investigated...
>>>>>
>>>>> Meanwhile my builds on Windows are now done from git. Additionally
>>>>> I did
>>>>> checkout from git on ArcaOS (OS/2) without problems.
>>>>>
>>>>> @Marcus:
>>>>> The switch to git hash (instead of SVN revision) would require some
>>>>> changes in the logic of our download page. Can you evaluate?
>>>> I don't see any real dependency between our download webapge and SVN;
>>>> except with the writen SVN rev. with fixed text on the HTML webpage:
>>>>
>>>> https://www.openoffice.org/download/index.html
>>>>
>>>> Release: Milestone AOO416m1 | Build ID 9790 | SVN r1844436 | Released
>>>> 2018-11-18 | Release Notes
>>>>
>>>> Can you tell me how a Git hash on our pache servers looks like? If
>>>> there is no big difference in size, then it should be a problem.
>>> Exactly! There is a short and a long git hash. Which one we choose
>>> hasn't been discussed yet. We would have to take either one for new
>>> builds and leave the SVN revision for the old builds.
>>>
>>> I just wanted to make sure that we think about such topics *before* we
>>> switch.
>> sure, but please tell me how a Git hash (short and long) looks like.
>> Then we can judge if it fits.
> Looking at Damjans last commit:
> https://github.com/apache/openoffice/commit/779db4a01a7b0297a1573645c842007eab71ab85
>
> 779db4a01a7b0297a1573645c842007eab71ab85 is the long hash
>
> 779db4a0 would be the short
>
> See also:
>
> https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection
>
> Our git is mirrored from SVN and contains:
> git-svn-id: https://svn.apache.org/repos/asf/openoffice/trunk@1863883
>
> 1863883 is the SVN revision which is taken when building from our git at
> the moment.
>
> I *think* the code is in here:
> main/solenv/bin/modules/SvnRevision.pm
>
> That said, I am far away from being a specialist on this topic. ;-)
>
>>>> *But:*
>>>>
>>>> The biggest change is for the CMS. Does it support also Git? If not,
>>>> then we shouldn't change also the website repo to Git as nobody of us
>>>> (IMHO) can support this change.
>>> As I understand it Peter only wants to switch trunk, branches and tags
>>> to Git, not (yet) the CMS (site and ooo-site).
>> Let's discuss this in the other thread.
> Which other thread?
>
> Matthias
>
>> Thanks
>>
>> Marcus
>>
>>
>>
>>>>>> BTW: My latest builds are based on a checkout from git, no problems
>>>>>> so far.
>>>>>>
>>>>>>> Please review:
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/INFRA-18773
>>>>>>>
>>>>>>> On 21.07.19 01:42, Peter Kovacs wrote:
>>>>>>>> Hi brane,
>>>>>>>>
>>>>>>>> The threads are linked in my first post.
>>>>>>>>
>>>>>>>> It is for me a workflow thing.
>>>>>>>> I need a decentral versioning system instead of a central one.
>>>>>>>> And I want github as public patch interface.
>>>>>>>> Both do not work with svn.
>>>>>>>>
>>>>>>>> I add a reason that I heard at work. Young people do not know svn.
>>>>>>>> They expect to work with git.
>>>>>>>> IMHO it is  a dumb argument but in my country the fresh people
>>>>>>>> from university are dictating a little their working environment.
>>>>>>>>
>>>>>>>> Ahh and git has major pains reading OpenOffice svn repo. So I
>>>>>>>> can't even use git as a client.
>>>>>>>>
>>>>>>>> All the best.
>>>>>>>> Peter
>>>>>>>>
>>>>>>>> Am 21. Juli 2019 01:17:32 MESZ schrieb "Branko Čibej"
>>>>>>>> <[hidden email]>:
>>>>>>>>> Hi AOO devs,
>>>>>>>>>
>>>>>>>>> I just stumbled onto this thread. Coming from subversion.a.o, I'm
>>>>>>>>> saddened
>>>>>>>>> to see you've decided to switch to Git. Could someone please
>>>>>>>>> summarise
>>>>>>>>> the
>>>>>>>>> reasons for this decision, or give me a link to the discussion in
>>>>>>>>> the
>>>>>>>>> mail
>>>>>>>>> archives? I'd very much like to know if it was caused by some
>>>>>>>>> specific
>>>>>>>>> problem or missing feature in Subversion that we may be able to
>>>>>>>>> address.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
Reply | Threaded
Open this post in threaded view
|

Re: [discussion] CMS migration (was: svn migration plan)

Peter Kovacs-3
In reply to this post by Marcus (OOo)

On 28.07.19 23:10, Marcus wrote:
> Am 28.07.19 um 21:31 schrieb Peter Kovacs:
>> Cms will be shut down soon. The question is how we deal with this.
>> Info is in the chat protocol in my original post.
>
> OK, then we will have a big problem in order to serve our website pages.
>
> Marcus
>
>
There are no deadlines yet. Just whishes on time frame. There is current
a loose target at Infra in 3 month. Lets say november. If we manage to
switch at december we will still be fine.

Infra offers an incompatible replacement suite. Maybe there will be
migration scripts helping us with the migration.

I would like more to move to a easy to use cms system that might help us
to reduce tech diversity and maintenance. I am quite fond of neo (1)

Neo looks interesting since it promises a easy to use front end, multi
language setup of content and the ability to integrate other sites and
resources, while technical relative "easy" maintenance.

Both Ideas sound like promising ways. with pro and cons. I am open for
more ways.


(1)https://www.neos.io/




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

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] CMS migration (was: svn migration plan)

George Karalis
Hello Peter,

I have proposed some time ago the move to a static site generator — like Jekyll, Hugo etc. —
as I was redesigning OpenOffice’s front-page. That would greatly help reduce tech diversity
and maintenance as only static html files will be served.

Most static site generators work with markdown and I believe that content writers won't have
a problem working with markdown. We could also setup an automated build pipeline that
serves the generated site with every commit, i.e. every markdown or template change.

By the way there's a fully functional redesigned front-page for anyone interested, that time
there was a server migration and it hadn't got much attention. The CMS migration provides an
opportunity to move to a whole website redesign.
---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] CMS migration (was: svn migration plan)

Gavin McDonald-3
Hi all,

On Mon, Jul 29, 2019 at 9:18 AM George Karalis <[hidden email]> wrote:
>
> Hello Peter,
>
> I have proposed some time ago the move to a static site generator — like
Jekyll, Hugo etc. —
> as I was redesigning OpenOffice’s front-page. That would greatly help
reduce tech diversity
> and maintenance as only static html files will be served.
>
> Most static site generators work with markdown and I believe that content
writers won't have
> a problem working with markdown. We could also setup an automated build
pipeline that
> serves the generated site with every commit, i.e. every markdown or
template change.


Hi George, you have just described almost perfectly Infras replacement for
the CMS!
Using Pelican and GHFM and Buildbot, you only need to 'edit' a page in
Github and that
commit will trigger a site rebuild and automatic publish of the site. It is
still in testing but
almost ready for use. I'll post more details and a docs link when its ready
for wider testing.

Gav...


>
>
> By the way there's a fully functional redesigned front-page for anyone
interested, that time
> there was a server migration and it hadn't got much attention. The CMS
migration provides an
> opportunity to move to a whole website redesign.
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


--
Gav...
Reply | Threaded
Open this post in threaded view
|

Re: [discussion] CMS migration (was: svn migration plan)

Raphael Bircher-3
Hi Gavin

Sounds like a load of work, Especially for the Templates. Does Pelican
serve HTML and markdown mixed?

Regards Raphael.

On Mon, Jul 29, 2019 at 10:48 AM Gavin McDonald <[hidden email]> wrote:

>
> Hi all,
>
> On Mon, Jul 29, 2019 at 9:18 AM George Karalis <[hidden email]> wrote:
> >
> > Hello Peter,
> >
> > I have proposed some time ago the move to a static site generator — like
> Jekyll, Hugo etc. —
> > as I was redesigning OpenOffice’s front-page. That would greatly help
> reduce tech diversity
> > and maintenance as only static html files will be served.
> >
> > Most static site generators work with markdown and I believe that content
> writers won't have
> > a problem working with markdown. We could also setup an automated build
> pipeline that
> > serves the generated site with every commit, i.e. every markdown or
> template change.
>
>
> Hi George, you have just described almost perfectly Infras replacement for
> the CMS!
> Using Pelican and GHFM and Buildbot, you only need to 'edit' a page in
> Github and that
> commit will trigger a site rebuild and automatic publish of the site. It is
> still in testing but
> almost ready for use. I'll post more details and a docs link when its ready
> for wider testing.
>
> Gav...
>
>
> >
> >
> > By the way there's a fully functional redesigned front-page for anyone
> interested, that time
> > there was a server migration and it hadn't got much attention. The CMS
> migration provides an
> > opportunity to move to a whole website redesign.
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
>
>
> --
> Gav...

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

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] svn migration plan

Matthias Seidel
In reply to this post by Peter Kovacs-3
Hi Peter,

Am 29.07.19 um 00:39 schrieb Peter Kovacs:
> A different suggestion we use the git commit count. The command is:
>
> |git rev-list --all --count It will deliver something that looks similar
> to the svn number we already use. All the Best Peter |

How would such a simple count point to a specific commit/revision?

Regards,

   Matthias

>
> On 29.07.19 00:17, Matthias Seidel wrote:
>> Hi Marcus,
>>
>> Am 28.07.19 um 23:12 schrieb Marcus:
>>> Am 28.07.19 um 20:29 schrieb Matthias Seidel:
>>>> Am 28.07.19 um 20:12 schrieb Marcus:
>>>>> Am 27.07.19 um 13:45 schrieb Matthias Seidel:
>>>>>> Am 23.07.19 um 11:08 schrieb Matthias Seidel:
>>>>>>> Am 21.07.19 um 12:27 schrieb Peter Kovacs:
>>> Hi Matthias,
>>>
>>>>>>>> back to the initial discussion.
>>>>>>> Obviously you didn't read my mail until the end...
>>>>>>>> I have created the request. Simply requesting that trunc, branch and
>>>>>>>> tags are moved. All other folders should remain as is.
>>>>>>>>
>>>>>>>> I hope this suits everyone.
>>>>>>> Do we have the necessary code changes ready?
>>>>>>>
>>>>>>> We use the SVN revision in our About dialog, and for creating the
>>>>>>> source
>>>>>>> builds. This has to be adapted when we switch to git.
>>>>>>> Using the git hash (short or long) instead? This should have been
>>>>>>> discussed...
>>>>>> Given the lack of response, this has yet to be investigated...
>>>>>>
>>>>>> Meanwhile my builds on Windows are now done from git. Additionally
>>>>>> I did
>>>>>> checkout from git on ArcaOS (OS/2) without problems.
>>>>>>
>>>>>> @Marcus:
>>>>>> The switch to git hash (instead of SVN revision) would require some
>>>>>> changes in the logic of our download page. Can you evaluate?
>>>>> I don't see any real dependency between our download webapge and SVN;
>>>>> except with the writen SVN rev. with fixed text on the HTML webpage:
>>>>>
>>>>> https://www.openoffice.org/download/index.html
>>>>>
>>>>> Release: Milestone AOO416m1 | Build ID 9790 | SVN r1844436 | Released
>>>>> 2018-11-18 | Release Notes
>>>>>
>>>>> Can you tell me how a Git hash on our pache servers looks like? If
>>>>> there is no big difference in size, then it should be a problem.
>>>> Exactly! There is a short and a long git hash. Which one we choose
>>>> hasn't been discussed yet. We would have to take either one for new
>>>> builds and leave the SVN revision for the old builds.
>>>>
>>>> I just wanted to make sure that we think about such topics *before* we
>>>> switch.
>>> sure, but please tell me how a Git hash (short and long) looks like.
>>> Then we can judge if it fits.
>> Looking at Damjans last commit:
>> https://github.com/apache/openoffice/commit/779db4a01a7b0297a1573645c842007eab71ab85
>>
>> 779db4a01a7b0297a1573645c842007eab71ab85 is the long hash
>>
>> 779db4a0 would be the short
>>
>> See also:
>>
>> https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection
>>
>> Our git is mirrored from SVN and contains:
>> git-svn-id: https://svn.apache.org/repos/asf/openoffice/trunk@1863883
>>
>> 1863883 is the SVN revision which is taken when building from our git at
>> the moment.
>>
>> I *think* the code is in here:
>> main/solenv/bin/modules/SvnRevision.pm
>>
>> That said, I am far away from being a specialist on this topic. ;-)
>>
>>>>> *But:*
>>>>>
>>>>> The biggest change is for the CMS. Does it support also Git? If not,
>>>>> then we shouldn't change also the website repo to Git as nobody of us
>>>>> (IMHO) can support this change.
>>>> As I understand it Peter only wants to switch trunk, branches and tags
>>>> to Git, not (yet) the CMS (site and ooo-site).
>>> Let's discuss this in the other thread.
>> Which other thread?
>>
>> Matthias
>>
>>> Thanks
>>>
>>> Marcus
>>>
>>>
>>>
>>>>>>> BTW: My latest builds are based on a checkout from git, no problems
>>>>>>> so far.
>>>>>>>
>>>>>>>> Please review:
>>>>>>>>
>>>>>>>> https://issues.apache.org/jira/browse/INFRA-18773
>>>>>>>>
>>>>>>>> On 21.07.19 01:42, Peter Kovacs wrote:
>>>>>>>>> Hi brane,
>>>>>>>>>
>>>>>>>>> The threads are linked in my first post.
>>>>>>>>>
>>>>>>>>> It is for me a workflow thing.
>>>>>>>>> I need a decentral versioning system instead of a central one.
>>>>>>>>> And I want github as public patch interface.
>>>>>>>>> Both do not work with svn.
>>>>>>>>>
>>>>>>>>> I add a reason that I heard at work. Young people do not know svn.
>>>>>>>>> They expect to work with git.
>>>>>>>>> IMHO it is  a dumb argument but in my country the fresh people
>>>>>>>>> from university are dictating a little their working environment.
>>>>>>>>>
>>>>>>>>> Ahh and git has major pains reading OpenOffice svn repo. So I
>>>>>>>>> can't even use git as a client.
>>>>>>>>>
>>>>>>>>> All the best.
>>>>>>>>> Peter
>>>>>>>>>
>>>>>>>>> Am 21. Juli 2019 01:17:32 MESZ schrieb "Branko Čibej"
>>>>>>>>> <[hidden email]>:
>>>>>>>>>> Hi AOO devs,
>>>>>>>>>>
>>>>>>>>>> I just stumbled onto this thread. Coming from subversion.a.o, I'm
>>>>>>>>>> saddened
>>>>>>>>>> to see you've decided to switch to Git. Could someone please
>>>>>>>>>> summarise
>>>>>>>>>> the
>>>>>>>>>> reasons for this decision, or give me a link to the discussion in
>>>>>>>>>> the
>>>>>>>>>> mail
>>>>>>>>>> archives? I'd very much like to know if it was caused by some
>>>>>>>>>> specific
>>>>>>>>>> problem or missing feature in Subversion that we may be able to
>>>>>>>>>> address.
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>


smime.p7s (5K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: [discussion] CMS migration (was: svn migration plan)

Dave Fisher-3
In reply to this post by Raphael Bircher-3
BTW -

A good portion of the site is html as donated in 2011. It is extracted using additional functions in the CMS and then wrapped in the templates.

There is about 9GB content and as the template was developed we hammered the CMS system.

We will need to revisit how we handle NL for the headers. I did the bulk of the work in Dec 2011. No real plans to help until after Apachecon.

Please keep the OpenOffice website in SVN until a Git based framework using new tools is built. Once it is we can do a bulk move which could include html conversions.

Personally, I kind of like the JBake approach used in the Incubator ...

Regards,
Dave

Sent from my iPhone

> On Jul 29, 2019, at 7:33 AM, Raphael Bircher <[hidden email]> wrote:
>
> Hi Gavin
>
> Sounds like a load of work, Especially for the Templates. Does Pelican
> serve HTML and markdown mixed?
>
> Regards Raphael.
>
>> On Mon, Jul 29, 2019 at 10:48 AM Gavin McDonald <[hidden email]> wrote:
>>
>> Hi all,
>>
>>> On Mon, Jul 29, 2019 at 9:18 AM George Karalis <[hidden email]> wrote:
>>>
>>> Hello Peter,
>>>
>>> I have proposed some time ago the move to a static site generator — like
>> Jekyll, Hugo etc. —
>>> as I was redesigning OpenOffice’s front-page. That would greatly help
>> reduce tech diversity
>>> and maintenance as only static html files will be served.
>>>
>>> Most static site generators work with markdown and I believe that content
>> writers won't have
>>> a problem working with markdown. We could also setup an automated build
>> pipeline that
>>> serves the generated site with every commit, i.e. every markdown or
>> template change.
>>
>>
>> Hi George, you have just described almost perfectly Infras replacement for
>> the CMS!
>> Using Pelican and GHFM and Buildbot, you only need to 'edit' a page in
>> Github and that
>> commit will trigger a site rebuild and automatic publish of the site. It is
>> still in testing but
>> almost ready for use. I'll post more details and a docs link when its ready
>> for wider testing.
>>
>> Gav...
>>
>>
>>>
>>>
>>> By the way there's a fully functional redesigned front-page for anyone
>> interested, that time
>>> there was a server migration and it hadn't got much attention. The CMS
>> migration provides an
>>> opportunity to move to a whole website redesign.
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> --
>> Gav...
>
> ---------------------------------------------------------------------
> 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: [discussion] svn migration plan

Peter Kovacs-3
In reply to this post by Matthias Seidel

On 29.07.19 17:18, Matthias Seidel wrote:
> Hi Peter,
>
> Am 29.07.19 um 00:39 schrieb Peter Kovacs:
>> A different suggestion we use the git commit count. The command is:
>>
>> |git rev-list --all --count It will deliver something that looks similar
>> to the svn number we already use. All the Best Peter |
> How would such a simple count point to a specific commit/revision?
>
I checked this,. In theory it should but there are a lots of option how
to count in git.

Which makes this not so optimal as on first glance. But it seems a lot
of people use it to stick to a revision number.

So there seems to be only 2 true options for referencing the commit:

1) We use the short hash.

2) We tag releases automatically at checkin.


Tbh I would rather use the short hash.



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

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] svn migration plan

Marcus (OOo)
In reply to this post by Matthias Seidel
Am 29.07.19 um 00:17 schrieb Matthias Seidel:
> Am 28.07.19 um 23:12 schrieb Marcus:
>> Am 28.07.19 um 20:29 schrieb Matthias Seidel:
>>> Am 28.07.19 um 20:12 schrieb Marcus:
>>>> Am 27.07.19 um 13:45 schrieb Matthias Seidel:
>>>>> Am 23.07.19 um 11:08 schrieb Matthias Seidel:
>>>>>> Am 21.07.19 um 12:27 schrieb Peter Kovacs:

Hi Matthias,

>>>>>>> back to the initial discussion.
>>>>>> Obviously you didn't read my mail until the end...
>>>>>>> I have created the request. Simply requesting that trunc, branch and
>>>>>>> tags are moved. All other folders should remain as is.
>>>>>>>
>>>>>>> I hope this suits everyone.
>>>>>> Do we have the necessary code changes ready?
>>>>>>
>>>>>> We use the SVN revision in our About dialog, and for creating the
>>>>>> source
>>>>>> builds. This has to be adapted when we switch to git.
>>>>>> Using the git hash (short or long) instead? This should have been
>>>>>> discussed...
>>>>>
>>>>> Given the lack of response, this has yet to be investigated...
>>>>>
>>>>> Meanwhile my builds on Windows are now done from git. Additionally
>>>>> I did
>>>>> checkout from git on ArcaOS (OS/2) without problems.
>>>>>
>>>>> @Marcus:
>>>>> The switch to git hash (instead of SVN revision) would require some
>>>>> changes in the logic of our download page. Can you evaluate?
>>>>
>>>> I don't see any real dependency between our download webapge and SVN;
>>>> except with the writen SVN rev. with fixed text on the HTML webpage:
>>>>
>>>> https://www.openoffice.org/download/index.html
>>>>
>>>> Release: Milestone AOO416m1 | Build ID 9790 | SVN r1844436 | Released
>>>> 2018-11-18 | Release Notes
>>>>
>>>> Can you tell me how a Git hash on our pache servers looks like? If
>>>> there is no big difference in size, then it should be a problem.
>>>
>>> Exactly! There is a short and a long git hash. Which one we choose
>>> hasn't been discussed yet. We would have to take either one for new
>>> builds and leave the SVN revision for the old builds.
>>>
>>> I just wanted to make sure that we think about such topics *before* we
>>> switch.
>>
>> sure, but please tell me how a Git hash (short and long) looks like.
>> Then we can judge if it fits.
>
> Looking at Damjans last commit:
> https://github.com/apache/openoffice/commit/779db4a01a7b0297a1573645c842007eab71ab85
>
> 779db4a01a7b0297a1573645c842007eab71ab85 is the long hash
>
> 779db4a0 would be the short

thanks for the examples.

Marcus



> See also:
>
> https://git-scm.com/book/en/v2/Git-Tools-Revision-Selection
>
> Our git is mirrored from SVN and contains:
> git-svn-id: https://svn.apache.org/repos/asf/openoffice/trunk@1863883
>
> 1863883 is the SVN revision which is taken when building from our git at
> the moment.
>
> I *think* the code is in here:
> main/solenv/bin/modules/SvnRevision.pm
>
> That said, I am far away from being a specialist on this topic. ;-)
>
>>
>>>> *But:*
>>>>
>>>> The biggest change is for the CMS. Does it support also Git? If not,
>>>> then we shouldn't change also the website repo to Git as nobody of us
>>>> (IMHO) can support this change.
>>> As I understand it Peter only wants to switch trunk, branches and tags
>>> to Git, not (yet) the CMS (site and ooo-site).
>>
>> Let's discuss this in the other thread.
>
> Which other thread?
>
> Matthias
>
>>
>> Thanks
>>
>> Marcus
>>
>>
>>
>>>>>> BTW: My latest builds are based on a checkout from git, no problems
>>>>>> so far.
>>>>>>
>>>>>>> Please review:
>>>>>>>
>>>>>>> https://issues.apache.org/jira/browse/INFRA-18773
>>>>>>>
>>>>>>> On 21.07.19 01:42, Peter Kovacs wrote:
>>>>>>>> Hi brane,
>>>>>>>>
>>>>>>>> The threads are linked in my first post.
>>>>>>>>
>>>>>>>> It is for me a workflow thing.
>>>>>>>> I need a decentral versioning system instead of a central one.
>>>>>>>> And I want github as public patch interface.
>>>>>>>> Both do not work with svn.
>>>>>>>>
>>>>>>>> I add a reason that I heard at work. Young people do not know svn.
>>>>>>>> They expect to work with git.
>>>>>>>> IMHO it is  a dumb argument but in my country the fresh people
>>>>>>>> from university are dictating a little their working environment.
>>>>>>>>
>>>>>>>> Ahh and git has major pains reading OpenOffice svn repo. So I
>>>>>>>> can't even use git as a client.
>>>>>>>>
>>>>>>>> All the best.
>>>>>>>> Peter
>>>>>>>>
>>>>>>>> Am 21. Juli 2019 01:17:32 MESZ schrieb "Branko Čibej"
>>>>>>>> <[hidden email]>:
>>>>>>>>> Hi AOO devs,
>>>>>>>>>
>>>>>>>>> I just stumbled onto this thread. Coming from subversion.a.o, I'm
>>>>>>>>> saddened
>>>>>>>>> to see you've decided to switch to Git. Could someone please
>>>>>>>>> summarise
>>>>>>>>> the
>>>>>>>>> reasons for this decision, or give me a link to the discussion in
>>>>>>>>> the
>>>>>>>>> mail
>>>>>>>>> archives? I'd very much like to know if it was caused by some
>>>>>>>>> specific
>>>>>>>>> problem or missing feature in Subversion that we may be able to
>>>>>>>>> address.


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

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] CMS migration (was: svn migration plan)

Peter Kovacs-3
In reply to this post by George Karalis
Welcome back George,


yes I have not forgotten your work. I do hope you continue. I am really
happy on your post.

I liked your proposal for the new design. I would really like to see
that they move into our "production".

The only thing is that in my opinion the static side generator does not
fit to the 2 wikis, to bugzilla and to our maybe hopefully soon
returning OpenGrok instance.

What I would opt for that we are able to move all written content into
one single cms that also works like a wiki. However it is more important
that we move away from the old cms.

So if you guys think we should go for a page gen then lets go on this
journey.


I am in full support for a redesign. I usually get lost in our
materials. I would so much like to see a improvement on our material. I
also tried to motivate new people but I did not manage to accompany them
enough. So I am really sad it did not work.


All the best

Peter


On 29.07.19 10:17, George Karalis wrote:

> Hello Peter,
>
> I have proposed some time ago the move to a static site generator — like Jekyll, Hugo etc. —
> as I was redesigning OpenOffice’s front-page. That would greatly help reduce tech diversity
> and maintenance as only static html files will be served.
>
> Most static site generators work with markdown and I believe that content writers won't have
> a problem working with markdown. We could also setup an automated build pipeline that
> serves the generated site with every commit, i.e. every markdown or template change.
>
> By the way there's a fully functional redesigned front-page for anyone interested, that time
> there was a server migration and it hadn't got much attention. The CMS migration provides an
> opportunity to move to a whole website redesign.
> ---------------------------------------------------------------------
> 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: [discussion] CMS migration

Marcus (OOo)
In reply to this post by Peter Kovacs-3
Am 29.07.19 um 00:53 schrieb Peter Kovacs:

> On 28.07.19 23:10, Marcus wrote:
>> Am 28.07.19 um 21:31 schrieb Peter Kovacs:
>>> Cms will be shut down soon. The question is how we deal with this.
>>> Info is in the chat protocol in my original post.
>>
>> OK, then we will have a big problem in order to serve our website pages.
>>
>> Marcus
>>
> There are no deadlines yet. Just whishes on time frame. There is current
> a loose target at Infra in 3 month. Lets say november. If we manage to
> switch at december we will still be fine.
>
> Infra offers an incompatible replacement suite. Maybe there will be
> migration scripts helping us with the migration.
>
> I would like more to move to a easy to use cms system that might help us
> to reduce tech diversity and maintenance. I am quite fond of neo (1)
>
> Neo looks interesting since it promises a easy to use front end, multi
> language setup of content and the ability to integrate other sites and
> resources, while technical relative "easy" maintenance.
>
> Both Ideas sound like promising ways. with pro and cons. I am open for
> more ways.

I hate to be the bad guy. However, there is another point that we need
to take into account which is very important:

As we haven't much people that can do such a big migration step, we
really need to go the easy way.

So, when the Infra team has finished their substitution and it has no
big obstacles (from our point of view), then we should take this.

Marcus


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

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] CMS migration

Marcus (OOo)
In reply to this post by Gavin McDonald-3
Am 29.07.19 um 10:48 schrieb Gavin McDonald:

> On Mon, Jul 29, 2019 at 9:18 AM George Karalis <[hidden email]> wrote:
>>
>> I have proposed some time ago the move to a static site generator — like
> Jekyll, Hugo etc. —
>> as I was redesigning OpenOffice’s front-page. That would greatly help
> reduce tech diversity
>> and maintenance as only static html files will be served.
>>
>> Most static site generators work with markdown and I believe that content
> writers won't have
>> a problem working with markdown. We could also setup an automated build
> pipeline that
>> serves the generated site with every commit, i.e. every markdown or
> template change.
>
> Hi George, you have just described almost perfectly Infras replacement for
> the CMS!
> Using Pelican and GHFM and Buildbot, you only need to 'edit' a page in
> Github and that
> commit will trigger a site rebuild and automatic publish of the site. It is
> still in testing but
> almost ready for use. I'll post more details and a docs link when its ready
> for wider testing.

that sounds very good.

Yes, please give us a note when it's finished (or ready for a serious
beta test) and how to use it. Then we can test a bit.

Thanks

Marcus



>> By the way there's a fully functional redesigned front-page for anyone
> interested, that time
>> there was a server migration and it hadn't got much attention. The CMS
> migration provides an
>> opportunity to move to a whole website redesign.

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

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] CMS migration

Peter Kovacs-3

On 29.07.19 21:06, Marcus wrote:

>
> that sounds very good.
>
> Yes, please give us a note when it's finished (or ready for a serious
> beta test) and how to use it. Then we can test a bit.
>
> Thanks
>
> Marcus
>
>
The infra page is already on the site. I would opt if we want to go this
rout that we start now. Even if it is not completly done.



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

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] CMS migration

George Karalis
Hi all,

Just so you know, whatever you decide am willing to help with the migration

> On 29 Jul 2019, at 22:08, Peter Kovacs <[hidden email]> wrote:
>
>
> On 29.07.19 21:06, Marcus wrote:
>>
>> that sounds very good.
>>
>> Yes, please give us a note when it's finished (or ready for a serious
>> beta test) and how to use it. Then we can test a bit.
>>
>> Thanks
>>
>> Marcus
>>
>>
> The infra page is already on the site. I would opt if we want to go this
> rout that we start now. Even if it is not completly done.
>
>
>
> ---------------------------------------------------------------------
> 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: [discussion] CMS migration

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


> On Jul 29, 2019, at 12:08 PM, Peter Kovacs <[hidden email]> wrote:
>
>
> On 29.07.19 21:06, Marcus wrote:
>>
>> that sounds very good.
>>
>> Yes, please give us a note when it's finished (or ready for a serious
>> beta test) and how to use it. Then we can test a bit.

Please proceed with small examples and test with other languages. The whole of OpenOffice.org is large - aka 9GB. There are decisions to make as we go along.

Someone needs to make a roadmap for OpenOffice.org. Someone needs to understand how the current CMS version ACTUALLY works. I’ll answer questions, but I’m not looking at it until after Apachecon.

Regards,
Dave

>>
>> Thanks
>>
>> Marcus
>>
>>
> The infra page is already on the site. I would opt if we want to go this
> rout that we start now. Even if it is not completly done.
>
>
>
> ---------------------------------------------------------------------
> 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: [discussion] CMS migration

Peter Kovacs-3

On 29.07.19 21:11, Dave Fisher wrote:
>
> Please proceed with small examples and test with other languages. The whole of OpenOffice.org is large - aka 9GB. There are decisions to make as we go along.
>
> Someone needs to make a roadmap for OpenOffice.org. Someone needs to understand how the current CMS version ACTUALLY works. I’ll answer questions, but I’m not looking at it until after Apachecon.
>
> Regards,
> Dave

I had a quick look at the content. I think we do not need to migrate
everything. We should think about reducing the content.

So we could try to identify the most important Pages, that are still
useful and then make a switch, taking offline everything else, but keep
the SVN as archive. If there is interest in the material that we did not
migrate we could add a migration request page.


then we could focus on the most important stuff. replace those with
something new. Make the switch, and then continue migrating while the
infra switches off the old CMS infra structure.

@Gav would that be something we can technically do?

@all do you think such an approach would save work? not that we end up
in still migrate a lot of the content?


@all

Maybe it would be nice to make a openoffice.org memorial. publishing a
freezed version of what is online today. It is maybe a stupid Idea, but
looking through all the stuff, it feels like moving through old times.


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: [discussion] CMS migration

Jörg Schmidt-2
Hello,

A fundamental question first:
The "CMS migration" won't touch the wiki content? Right?

(i mean: wiki.openoffice.org)


> From: Peter Kovacs [mailto:[hidden email]]
> Sent: Tuesday, July 30, 2019 7:58 AM
> To: [hidden email]; Gavin McDonald
> Subject: Re: [discussion] CMS migration

> I had a quick look at the content. I think we do not need to migrate
> everything. We should think about reducing the content.
>
> So we could try to identify the most important Pages, that are still
> useful and then make a switch, taking offline everything
> else, but keep
> the SVN as archive. If there is interest in the material that
> we did not
> migrate we could add a migration request page.

Sorry, but:
What you are proposing here is an extremely large amount of work, _work that needs to be done carefully_.

If we make mistakes, the loss of information will be a disaster. Not necessarily for the project, but for millions of users.
For example, there are (probably) tens of thousands of websites that link to pages from openoffice.org. Our goal must be to maintain or redirect these link targets.


I don't understand:
Why is migration necessary at all?
I don't like the fact that programmers here spend time with this discussion (and possibly later with the migration), because the (unfortunately) few programmers we have should concentrate fully on the further development of the program.


> @all
>
> Maybe it would be nice to make a openoffice.org memorial. publishing a
> freezed version of what is online today. It is maybe a stupid
> Idea, but
> looking through all the stuff, it feels like moving through old times.

No, that's not a stupid idea. I explicitly support this idea, less as a memorial but rather as an archive and backup.



greetings,
Jörg



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

Reply | Threaded
Open this post in threaded view
|

Re: [discussion] CMS migration

Peter Kovacs-3

On 30.07.19 23:32, Jörg Schmidt wrote:
> Hello,
>
> A fundamental question first:
> The "CMS migration" won't touch the wiki content? Right?
>
> (i mean: wiki.openoffice.org)
Not in the focus in this discussion. Personally I would like to. But
this is a huge amount of work too. And not something we should target now.

>> I had a quick look at the content. I think we do not need to migrate
>> everything. We should think about reducing the content.
>>
>> So we could try to identify the most important Pages, that are still
>> useful and then make a switch, taking offline everything
>> else, but keep
>> the SVN as archive. If there is interest in the material that
>> we did not
>> migrate we could add a migration request page.
> Sorry, but:
> What you are proposing here is an extremely large amount of work, _work that needs to be done carefully_.
I think we are all clear on this. Thats why I try to chop it into
smaller parts so we can work sometimes on it. And have some sort of
natural selection.
>
> If we make mistakes, the loss of information will be a disaster. Not necessarily for the project, but for millions of users.
> For example, there are (probably) tens of thousands of websites that link to pages from openoffice.org. Our goal must be to maintain or redirect these link targets.
If we want to stay alive we need to be able to break eggs. So if we have
room to do this it is fine, if not it is bad. Imho the freezed version
for openoffice.org might counter your concern.
>
>
> I don't understand:
> Why is migration necessary at all?
> I don't like the fact that programmers here spend time with this discussion (and possibly later with the migration), because the (unfortunately) few programmers we have should concentrate fully on the further development of the program.
The Software that drives our CMs is at end of live. We need replace it
with something that is still alive.
>
>> @all
>>
>> Maybe it would be nice to make a openoffice.org memorial. publishing a
>> freezed version of what is online today. It is maybe a stupid
>> Idea, but
>> looking through all the stuff, it feels like moving through old times.
> No, that's not a stupid idea. I explicitly support this idea, less as a memorial but rather as an archive and backup.
thanks Jörg. Archieve or memorial are both fine for me. And useing
openoffice.org might be also good for this.

>
>
>
> greetings,
> Jörg
>
>
>
> ---------------------------------------------------------------------
> 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]

1234