You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Carl Marcum <cm...@apache.org> on 2016/04/03 15:34:55 UTC
procedure for going from RC to release
I'm looking for the procedure for how the approved RC files are released.
Are the artifacts and signatures copied to new names or recreated and
signed?
I know where they go but not how the names are changed.
Thanks,
Carl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: procedure for going from RC to release
Posted by Carl Marcum <cm...@apache.org>.
On 04/03/2016 06:17 PM, Marcus wrote:
> Am 04/03/2016 09:42 PM, schrieb Andrea Pescetti:
>> Carl Marcum wrote:
>>> I was looking at how some other projects handled "extras" things like
>>> this.
>>
>> Other projects designed their trees in a different way.
>>
>>> I found Maven uses sub-folders under release/maven for plugins,
>>> plugin-tools, etc, that don't go into their main release folder. [1].
>>
>> Well, here the issue is: we have assumed so far that the OpenOffice
>> project releases, well, OpenOffice. This will still be true, but about
>> one user in ten millions will want the NetBeans plugin. We can't make
>> things more complex for the other 99,99999% of users due to this.
>>
>> So for example, one thing we can't do is to partition (now) our
>> "openoffice" tree into "releases" (for the "real" releases) and
>> "devtools". If we had known this years ago, it would have made sense
>> even with the large difference in numbers.
>>
>> In other words: I would consider
>> https://dist.apache.org/repos/dist/release/openoffice
>> to be taken. There will be no "releases" subfolder created in it, to
>> avoid large management costs for something 99,99999% of users won't use.
>> Either we go for the dirty solution you advocate, where we mix release
>> numbers and the "devtools" folder (which I don't like, but this is also
>> not worth a long discussion honestly), or you place the plugin sources
>> in some existing place.
>>
>>> Should we use something like a devtools subfolder under
>>> release/openoffice so they don't have to be redone for each maintenance
>>> release of AOO or end up with multiples in each AOO release?
>>
>> Multiple? You will want to look up the distinction between dist and
>> archive. If you don't find the relevant documentation, just ask and I'll
>> dig it up from the website.
>>
>>> https://dist.apache.org/repos/dist/release/openoffice/devtools/
>>
>> I don't know how going for the "dirty" solution will affect scripts. It
>> will surely result in misaligned trees in dist/ and SourceForge but this
>> is not particularly problematic. If I recall correctly the download page
>> options are populated via JS, but in turn that JS is probably generated
>> (by Marcus?) based on some tree inspection; so this would need a check
>> too, to ensure the extra "devtools" directory doesn't get in the way.
>>
>> On the other hand, the extra "devtools" folder will be ugly, but it will
>> provide a container for all releases that are not related to our "main"
>> product.
>>
>> We could at least agree that http://www.openoffice.org/download/ won't
>> change at all with the plugin release, right?
>
> of course. As you wrote correctly 99% of our users will not use the
> plugin. And the remaining 1% are no users but devs. And these people
> will use it directly from Netbeans anyway. ;-)
>
> So, I would see releasing the plugin as a part of the open source
> promise: Everybody can have a look into the source code to see what is
> going on - if they like to do it.
>
> Sure, I can implement also this pckage into the JS download scriping
> and provide something on the download page. However, I really doubt
> that it is worth the effort. ;-)
>
> OK seriously, Carl:
> - You can do whatever you see fit to release the source package
> regarding filenames, directory structure or where to put it in the
> tree on SourceForge. It will not influence the other AOO download
> behavior.
> Adding it in the "source/" dir along with the other files is OK. Or
> create a new "devtools/" dir.
>
> - When you have some documentation ready or just in mind, don't forget
> to mention this source package incl. a link. Then we can proof that it
> is available as open source.
>
> - As far as I've understood, the important part is the binary at
> Netbeans.org, right? Then we should keep the effort on openoffice.org
> as low as possible as it is just for 1%.
>
> - And, finally, when we see that something was done wrong. OK, then
> let's fix it at the lastest with the next plugin release.
>
> My 2 ct.
>
> Marcus
>
>
Hi Marcus,
Yes all these are source only. The binaries for the netbeans integration
will be from netbeans.org and the bootstrap-connector and groovy UNO are
Maven repo.
Thanks,
Carl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: procedure for going from RC to release
Posted by Marcus <ma...@wtnet.de>.
Am 04/03/2016 09:42 PM, schrieb Andrea Pescetti:
> Carl Marcum wrote:
>> I was looking at how some other projects handled "extras" things like
>> this.
>
> Other projects designed their trees in a different way.
>
>> I found Maven uses sub-folders under release/maven for plugins,
>> plugin-tools, etc, that don't go into their main release folder. [1].
>
> Well, here the issue is: we have assumed so far that the OpenOffice
> project releases, well, OpenOffice. This will still be true, but about
> one user in ten millions will want the NetBeans plugin. We can't make
> things more complex for the other 99,99999% of users due to this.
>
> So for example, one thing we can't do is to partition (now) our
> "openoffice" tree into "releases" (for the "real" releases) and
> "devtools". If we had known this years ago, it would have made sense
> even with the large difference in numbers.
>
> In other words: I would consider
> https://dist.apache.org/repos/dist/release/openoffice
> to be taken. There will be no "releases" subfolder created in it, to
> avoid large management costs for something 99,99999% of users won't use.
> Either we go for the dirty solution you advocate, where we mix release
> numbers and the "devtools" folder (which I don't like, but this is also
> not worth a long discussion honestly), or you place the plugin sources
> in some existing place.
>
>> Should we use something like a devtools subfolder under
>> release/openoffice so they don't have to be redone for each maintenance
>> release of AOO or end up with multiples in each AOO release?
>
> Multiple? You will want to look up the distinction between dist and
> archive. If you don't find the relevant documentation, just ask and I'll
> dig it up from the website.
>
>> https://dist.apache.org/repos/dist/release/openoffice/devtools/
>
> I don't know how going for the "dirty" solution will affect scripts. It
> will surely result in misaligned trees in dist/ and SourceForge but this
> is not particularly problematic. If I recall correctly the download page
> options are populated via JS, but in turn that JS is probably generated
> (by Marcus?) based on some tree inspection; so this would need a check
> too, to ensure the extra "devtools" directory doesn't get in the way.
>
> On the other hand, the extra "devtools" folder will be ugly, but it will
> provide a container for all releases that are not related to our "main"
> product.
>
> We could at least agree that http://www.openoffice.org/download/ won't
> change at all with the plugin release, right?
of course. As you wrote correctly 99% of our users will not use the
plugin. And the remaining 1% are no users but devs. And these people
will use it directly from Netbeans anyway. ;-)
So, I would see releasing the plugin as a part of the open source
promise: Everybody can have a look into the source code to see what is
going on - if they like to do it.
Sure, I can implement also this pckage into the JS download scriping and
provide something on the download page. However, I really doubt that it
is worth the effort. ;-)
OK seriously, Carl:
- You can do whatever you see fit to release the source package
regarding filenames, directory structure or where to put it in the tree
on SourceForge. It will not influence the other AOO download behavior.
Adding it in the "source/" dir along with the other files is OK. Or
create a new "devtools/" dir.
- When you have some documentation ready or just in mind, don't forget
to mention this source package incl. a link. Then we can proof that it
is available as open source.
- As far as I've understood, the important part is the binary at
Netbeans.org, right? Then we should keep the effort on openoffice.org as
low as possible as it is just for 1%.
- And, finally, when we see that something was done wrong. OK, then
let's fix it at the lastest with the next plugin release.
My 2 ct.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: procedure for going from RC to release
Posted by Carl Marcum <cm...@apache.org>.
On 04/03/2016 04:25 PM, Andrea Pescetti wrote:
> Carl Marcum wrote:
>> I hope you don't take my suggestion for disagreement.
>
> Of course not. Let's simply find together the right way to publish
> this source package in the tree. As I wrote, I am OK with adding
> devtools/ provided this doesn't break the JS generation for download
> page. I see no other significant drawbacks.
>
> Regards,
> Andrea.
>
Hopefully someone can determine if this will or not.
I have a few different tools I would like to release and don't want to
dilute the main release folder if it's not necessary.
If there is a problem with this devtools sub-folder or I don't have
confirmation that it will not be, I will do as you suggested.
Thanks for your help,
Carl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: procedure for going from RC to release
Posted by Andrea Pescetti <pe...@apache.org>.
Carl Marcum wrote:
> I hope you don't take my suggestion for disagreement.
Of course not. Let's simply find together the right way to publish this
source package in the tree. As I wrote, I am OK with adding devtools/
provided this doesn't break the JS generation for download page. I see
no other significant drawbacks.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: procedure for going from RC to release
Posted by Marcus <ma...@wtnet.de>.
Am 04/03/2016 10:10 PM, schrieb Carl Marcum:
> On 04/03/2016 03:42 PM, Andrea Pescetti wrote:
>> Carl Marcum wrote:
>>> I was looking at how some other projects handled "extras" things like
>>> this.
>>
>> Other projects designed their trees in a different way.
>>
>>> I found Maven uses sub-folders under release/maven for plugins,
>>> plugin-tools, etc, that don't go into their main release folder. [1].
>>
>> Well, here the issue is: we have assumed so far that the OpenOffice
>> project releases, well, OpenOffice. This will still be true, but about
>> one user in ten millions will want the NetBeans plugin. We can't make
>> things more complex for the other 99,99999% of users due to this.
>>
>> So for example, one thing we can't do is to partition (now) our
>> "openoffice" tree into "releases" (for the "real" releases) and
>> "devtools". If we had known this years ago, it would have made sense
>> even with the large difference in numbers.
>>
>> In other words: I would consider
>> https://dist.apache.org/repos/dist/release/openoffice
>> to be taken. There will be no "releases" subfolder created in it, to
>> avoid large management costs for something 99,99999% of users won't
>> use. Either we go for the dirty solution you advocate, where we mix
>> release numbers and the "devtools" folder (which I don't like, but
>> this is also not worth a long discussion honestly), or you place the
>> plugin sources in some existing place.
>>
>>> Should we use something like a devtools subfolder under
>>> release/openoffice so they don't have to be redone for each maintenance
>>> release of AOO or end up with multiples in each AOO release?
>>
>> Multiple? You will want to look up the distinction between dist and
>> archive. If you don't find the relevant documentation, just ask and
>> I'll dig it up from the website.
>>
>>> https://dist.apache.org/repos/dist/release/openoffice/devtools/
>>
>> I don't know how going for the "dirty" solution will affect scripts.
>> It will surely result in misaligned trees in dist/ and SourceForge but
>> this is not particularly problematic. If I recall correctly the
>> download page options are populated via JS, but in turn that JS is
>> probably generated (by Marcus?) based on some tree inspection; so this
>> would need a check too, to ensure the extra "devtools" directory
>> doesn't get in the way.
>>
>> On the other hand, the extra "devtools" folder will be ugly, but it
>> will provide a container for all releases that are not related to our
>> "main" product.
>>
>> We could at least agree that http://www.openoffice.org/download/ won't
>> change at all with the plugin release, right?
>>
>> Regards,
>> Andrea.
>>
>
> Andrea,
>
> I hope you don't take my suggestion for disagreement.
>
> I was not the one who pushed for these to be official releases. I am
> just trying to make sure they don't confuse or interfere.
and that's great. So, thanks for asking these things. This shows us that
you care about other things that maybe could be influenced by your work.
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: procedure for going from RC to release
Posted by Carl Marcum <cm...@apache.org>.
On 04/03/2016 03:42 PM, Andrea Pescetti wrote:
> Carl Marcum wrote:
>> I was looking at how some other projects handled "extras" things like
>> this.
>
> Other projects designed their trees in a different way.
>
>> I found Maven uses sub-folders under release/maven for plugins,
>> plugin-tools, etc, that don't go into their main release folder. [1].
>
> Well, here the issue is: we have assumed so far that the OpenOffice
> project releases, well, OpenOffice. This will still be true, but about
> one user in ten millions will want the NetBeans plugin. We can't make
> things more complex for the other 99,99999% of users due to this.
>
> So for example, one thing we can't do is to partition (now) our
> "openoffice" tree into "releases" (for the "real" releases) and
> "devtools". If we had known this years ago, it would have made sense
> even with the large difference in numbers.
>
> In other words: I would consider
> https://dist.apache.org/repos/dist/release/openoffice
> to be taken. There will be no "releases" subfolder created in it, to
> avoid large management costs for something 99,99999% of users won't
> use. Either we go for the dirty solution you advocate, where we mix
> release numbers and the "devtools" folder (which I don't like, but
> this is also not worth a long discussion honestly), or you place the
> plugin sources in some existing place.
>
>> Should we use something like a devtools subfolder under
>> release/openoffice so they don't have to be redone for each maintenance
>> release of AOO or end up with multiples in each AOO release?
>
> Multiple? You will want to look up the distinction between dist and
> archive. If you don't find the relevant documentation, just ask and
> I'll dig it up from the website.
>
>> https://dist.apache.org/repos/dist/release/openoffice/devtools/
>
> I don't know how going for the "dirty" solution will affect scripts.
> It will surely result in misaligned trees in dist/ and SourceForge but
> this is not particularly problematic. If I recall correctly the
> download page options are populated via JS, but in turn that JS is
> probably generated (by Marcus?) based on some tree inspection; so this
> would need a check too, to ensure the extra "devtools" directory
> doesn't get in the way.
>
> On the other hand, the extra "devtools" folder will be ugly, but it
> will provide a container for all releases that are not related to our
> "main" product.
>
> We could at least agree that http://www.openoffice.org/download/ won't
> change at all with the plugin release, right?
>
> Regards,
> Andrea.
>
Andrea,
I hope you don't take my suggestion for disagreement.
I was not the one who pushed for these to be official releases. I am
just trying to make sure they don't confuse or interfere.
Best regards,
Carl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: procedure for going from RC to release
Posted by Andrea Pescetti <pe...@apache.org>.
Carl Marcum wrote:
> I was looking at how some other projects handled "extras" things like this.
Other projects designed their trees in a different way.
> I found Maven uses sub-folders under release/maven for plugins,
> plugin-tools, etc, that don't go into their main release folder. [1].
Well, here the issue is: we have assumed so far that the OpenOffice
project releases, well, OpenOffice. This will still be true, but about
one user in ten millions will want the NetBeans plugin. We can't make
things more complex for the other 99,99999% of users due to this.
So for example, one thing we can't do is to partition (now) our
"openoffice" tree into "releases" (for the "real" releases) and
"devtools". If we had known this years ago, it would have made sense
even with the large difference in numbers.
In other words: I would consider
https://dist.apache.org/repos/dist/release/openoffice
to be taken. There will be no "releases" subfolder created in it, to
avoid large management costs for something 99,99999% of users won't use.
Either we go for the dirty solution you advocate, where we mix release
numbers and the "devtools" folder (which I don't like, but this is also
not worth a long discussion honestly), or you place the plugin sources
in some existing place.
> Should we use something like a devtools subfolder under
> release/openoffice so they don't have to be redone for each maintenance
> release of AOO or end up with multiples in each AOO release?
Multiple? You will want to look up the distinction between dist and
archive. If you don't find the relevant documentation, just ask and I'll
dig it up from the website.
> https://dist.apache.org/repos/dist/release/openoffice/devtools/
I don't know how going for the "dirty" solution will affect scripts. It
will surely result in misaligned trees in dist/ and SourceForge but this
is not particularly problematic. If I recall correctly the download page
options are populated via JS, but in turn that JS is probably generated
(by Marcus?) based on some tree inspection; so this would need a check
too, to ensure the extra "devtools" directory doesn't get in the way.
On the other hand, the extra "devtools" folder will be ugly, but it will
provide a container for all releases that are not related to our "main"
product.
We could at least agree that http://www.openoffice.org/download/ won't
change at all with the plugin release, right?
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: procedure for going from RC to release
Posted by Carl Marcum <cm...@apache.org>.
On 04/03/2016 11:49 AM, Andrea Pescetti wrote:
> On 03/04/2016 Marcus wrote:
>> Am 04/03/2016 03:34 PM, schrieb Carl Marcum:
>>> Are the artifacts and signatures copied to new names or recreated
>>> and signed?
>
> They are moved, using svn move.
>
>> If it's for the NetBeans plugin you can look at the name structure above
>> for the AOO files. Maybe it's possible to adopt it completely or do some
>> changes where it makes sense.
>
> For the "real" OpenOffice release there is nothing to discuss. Files
> are uploaded to the staging area and from there to dist.
>
> For this "extra" Netbeans plugin release (in the meantime I have taken
> a look at the sources and I found it is much more complex than what I
> thought, so it's reasonable to attempt a proper release) I suggest
> that we add one source-only file to the existing folders.
>
> Specifically (this is extremely important so please ask again for any
> doubts, or you will break a lot of technical assumptions):
>
> 1) You upload the RC (one source file, with hashes/signatures) in a
> new subdirectory of https://dist.apache.org/repos/dist/dev/openoffice/
> (say,
> https://dist.apache.org/repos/dist/dev/openoffice/netbeans-plugin-412-RC1-r1800000
> ); and you call the file something like
> netbeans-plugin-r1800000.tar.gz, reflecting the SVN revision it comes
> from.
>
> 2) After a successful vote, the one file you placed there (accompanied
> by its hashes/signatures) is moved (using svn move) to dist. The
> target directory to use is this one:
> https://dist.apache.org/repos/dist/release/openoffice/4.1.2/source/ ;
> please do not create anything else, the plugin sources will live in
> the source directory of the matching (or closest in time) OpenOffice
> release.
>
> As discussed, binaries for the Netbeans plugin are not released on the
> ASF infrastructure, so after approval you are free to build and sign
> them according to the rules needed on NetBeans.org; and no copy of
> them will be preserved on dist.
>
> Regards,
> Andrea.
>
Hi Andrea,
Thanks for the very detailed answer.
I was looking at how some other projects handled "extras" things like this.
I found Maven uses sub-folders under release/maven for plugins,
plugin-tools, etc, that don't go into their main release folder. [1].
Their plugins are source only because they are distributed via Maven Repos.
Should we use something like a devtools subfolder under
release/openoffice so they don't have to be redone for each maintenance
release of AOO or end up with multiples in each AOO release? Something
like :
https://dist.apache.org/repos/dist/release/openoffice/devtools/
[1] https://dist.apache.org/repos/dist/release/maven/plugins/
Thanks,
Carl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: procedure for going from RC to release
Posted by Andrea Pescetti <pe...@apache.org>.
On 03/04/2016 Marcus wrote:
> Am 04/03/2016 03:34 PM, schrieb Carl Marcum:
>> Are the artifacts and signatures copied to new names or recreated and signed?
They are moved, using svn move.
> If it's for the NetBeans plugin you can look at the name structure above
> for the AOO files. Maybe it's possible to adopt it completely or do some
> changes where it makes sense.
For the "real" OpenOffice release there is nothing to discuss. Files are
uploaded to the staging area and from there to dist.
For this "extra" Netbeans plugin release (in the meantime I have taken a
look at the sources and I found it is much more complex than what I
thought, so it's reasonable to attempt a proper release) I suggest that
we add one source-only file to the existing folders.
Specifically (this is extremely important so please ask again for any
doubts, or you will break a lot of technical assumptions):
1) You upload the RC (one source file, with hashes/signatures) in a new
subdirectory of https://dist.apache.org/repos/dist/dev/openoffice/ (say,
https://dist.apache.org/repos/dist/dev/openoffice/netbeans-plugin-412-RC1-r1800000
); and you call the file something like netbeans-plugin-r1800000.tar.gz,
reflecting the SVN revision it comes from.
2) After a successful vote, the one file you placed there (accompanied
by its hashes/signatures) is moved (using svn move) to dist. The target
directory to use is this one:
https://dist.apache.org/repos/dist/release/openoffice/4.1.2/source/ ;
please do not create anything else, the plugin sources will live in the
source directory of the matching (or closest in time) OpenOffice release.
As discussed, binaries for the Netbeans plugin are not released on the
ASF infrastructure, so after approval you are free to build and sign
them according to the rules needed on NetBeans.org; and no copy of them
will be preserved on dist.
Regards,
Andrea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: procedure for going from RC to release
Posted by Marcus <ma...@wtnet.de>.
Am 04/03/2016 03:34 PM, schrieb Carl Marcum:
> I'm looking for the procedure for how the approved RC files are released.
are you looking for the general release process for AOO? Or for the
Netbeans plugin you are creating?
> Are the artifacts and signatures copied to new names or recreated and
> signed?
The installation files are not renamed. The RCs have already the
release-able name structure:
Apache_OpenOffice_<version_number>_<platform>_<arch>_<install_type>_<language_id>.<file_extension>
Example:
Apache_OpenOffice_4.1.2_Linux_x86-64_install-rpm_de.tar.gz
For a complete overview have a look at the storage location at
SourceForge.net:
https://sourceforge.net/projects/openofficeorg.mirror/files/<version_number>/<binaries_or_source_files>/<language_id>/
Example:
https://sourceforge.net/projects/openofficeorg.mirror/files/4.1.2/binaries/de/
> I know where they go but not how the names are changed.
If it's for the NetBeans plugin you can look at the name structure above
for the AOO files. Maybe it's possible to adopt it completely or do some
changes where it makes sense.
HTH
Marcus
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
Re: procedure for going from RC to release
Posted by Carl Marcum <cm...@apache.org>.
On 04/03/2016 11:41 AM, Dennis E. Hamilton wrote:
> The RC artifact that is approved as a release is the artifact that is released.
>
> If you check the last RC for AOO 4.1.2 at <https://dist.apache.org/repos/dist/dev/openoffice/> you'll see that the folder has the RC name, tied to the source tree. In that folder, the files are all identified by the release those files are a candidate for, not by the RC.
>
> - Dennis
>
>
Somehow I missed that part.
Thanks,
Carl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org
RE: procedure for going from RC to release
Posted by "Dennis E. Hamilton" <de...@acm.org>.
The RC artifact that is approved as a release is the artifact that is released.
If you check the last RC for AOO 4.1.2 at <https://dist.apache.org/repos/dist/dev/openoffice/> you'll see that the folder has the RC name, tied to the source tree. In that folder, the files are all identified by the release those files are a candidate for, not by the RC.
- Dennis
> -----Original Message-----
> From: Carl Marcum [mailto:cmarcum@apache.org]
> Sent: Sunday, April 3, 2016 06:35
> To: dev@openoffice.apache.org
> Subject: procedure for going from RC to release
>
> I'm looking for the procedure for how the approved RC files are
> released.
>
> Are the artifacts and signatures copied to new names or recreated and
> signed?
>
> I know where they go but not how the names are changed.
>
> Thanks,
> Carl
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@openoffice.apache.org
For additional commands, e-mail: dev-help@openoffice.apache.org