Re: procedure for going from RC to release

[Marcus]

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,9% 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,9% 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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: procedure for going from RC to release

[Marcus]

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,9% 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,9% 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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: procedure for going from RC to release

[Carl Marcum]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: procedure for going from RC to release

[Andrea Pescetti]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: procedure for going from RC to release

[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,9% 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,9% 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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: procedure for going from RC to release

[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,9% 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,9% 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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: procedure for going from RC to release

[Carl Marcum]

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-r180 
); and you call the file something like 
netbeans-plugin-r180.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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Using the @ApacheOO Twitter Account

[Dennis E. Hamilton]

The @ApacheOO Twitter account is operated by an individual (the only option for 
free accounts).  A Member of the Project Management Committee operates the 
account.

However, everyone can use it and use its Twitter ID.  

First, subscribing to @ApacheOO on Twitter will provide notices about Apache 
OpenOffice and the ASF.  Notices about extensions and templates are available 
separately, via accounts @aooextensions and @aootemplates.

Secondly, if you are on twitter and have something you want to report about or 
related to Apache OpenOffice, please use "@ApacheOO" in your post.

Finally, all mentions of @ApacheOO are seen by the account operator.  Ones of 
general interest will be retweeted.  Ones that describe problems are often 
retweeted with suggestions that discussion be taken to the users@ list.  This 
has been working and folks do come there and even add Bugzilla issues.

 -- Dennis E. Hamilton
orc...@apache.org
dennis.hamil...@acm.org+1-206-779-9430
https://keybase.io/orcmid  PGP F96E 89FF D456 628A
X.509 certs used and requested for signed e-mail




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: [HELP NEEDED] old Solaris related build issues

[Marcus]

Am 04/03/2016 06:56 PM, schrieb Απόστολος Συρόπουλος:

We have a number of old Solaris related build issues that
could use some testing.

https://bz.apache.org/ooo/show_bug.cgi?id=125361
https://bz.apache.org/ooo/show_bug.cgi?id=125362
https://bz.apache.org/ooo/show_bug.cgi?id=125364
https://bz.apache.org/ooo/show_bug.cgi?id=125365



The main problem of OpenOffice on Solaris is that it still
assumes that one will use SunStudio to compile it. I think
OpenOffice should drop completely its support for this
compiler in favor for GCC. Once, I compiled OpenOffice
with GCC but for some reason it was failing to open
zipped formats (.docx etc). Also, I published all my
pathces and some of them were included in the source
tree. Some of the pacthes mentioned on the links above
are based on the patches I made. Unfortunately, no one
carred to update the code...


one problem of integrating patches is that you need to test them if the 
trunk builds are still OK or if some adjustments are necessary. However, 
AFAIK no developer has a Solaris machine under the desk and therefore 
it's not a good idea to commit fixes when you don't know what the 
results are. ;-)


That's also the reason why the build environment still uses Sun Studio 
and nothing else - instead or additional.


But when you can help us here with builds that would be great.

Marcus

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: [HELP NEEDED] old Solaris related build issues

[Απόστολος Συρόπουλος]

> > We have a number of old Solaris related build issues that
> > could use some testing.
> >
> > https://bz.apache.org/ooo/show_bug.cgi?id=125361
> > https://bz.apache.org/ooo/show_bug.cgi?id=125362
> > https://bz.apache.org/ooo/show_bug.cgi?id=125364
> > https://bz.apache.org/ooo/show_bug.cgi?id=125365
> >

The main problem of OpenOffice on Solaris is that it still 
assumes that one will use SunStudio to compile it. I think
OpenOffice should drop completely its support for this
compiler in favor for GCC. Once, I compiled OpenOffice 
with GCC but for some reason it was failing to open
zipped formats (.docx etc). Also, I published all my
pathces and some of them were included in the source
tree. Some of the pacthes mentioned on the links above
are based on the patches I made. Unfortunately, no one
carred to update the code...

 A.S.
--
Apostolos Syropoulos
Xanthi, Greece

  

Re: Let's fix the Windows build bots

[Damjan Jovanovic]

On Mon, Mar 28, 2016 at 10:53 PM, Andrea Pescetti  wrote:
> On 01/02/2016 j.nitschke wrote:
>>
>> But a global haltOnFailure would stop the build at 'svn info' step.
>> About the 'svn info' step, this one stopped working ...
>
>
> And we are back here, it seems. With the HTTPS fixes now in place, all the
> Linux and FreeBSD buildbots completed their build successfully, while the
> Windows one ran build --all but then suddenly stopped almost at the end,
> after delivering sc
>
> https://ci.apache.org/builders/aoo-win7/builds/231/steps/build.pl%20--all/logs/stdio
> command timed out: 2 seconds without output, killing pid 13888
>
> and today it stopped at a very early stage that you had already fixed, the
> "svn info":
>
> https://ci.apache.org/builders/aoo-win7/builds/232/steps/svn%20export/logs/stdio
> Inappropriate ioctl for device
>
> Jochen, Damjan, do you remember how you fixed it back at the time? Or was it
> handled in the chat session with pono Damjan mentions later in this thread
> (which would basically mean that it disappeared magically after a restart
> and some magic by Infra)?

No, the build hanging problem was never fixed. It started
mysteriously, and since I never got access to the Windows build bots
despite asking infra for months and even offering to volunteer, I have
no idea what's wrong or any way to debug it or any other build bot
problem. My own Windows box builds AOO perfectly and always has.

Regards
Damjan

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: procedure for going from RC to release

[Carl Marcum]

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 
 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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Let's fix the Windows build bots

[Jochen Nitschke]

On Mon, 28 Mar 2016 22:53:43 +0200 Andrea Pescetti wrote:
> And we are back here, it seems. With the HTTPS fixes now in place, all
> the Linux and FreeBSD buildbots completed their build successfully,
> while the Windows one ran build --all but then suddenly stopped almost
> at the end, after delivering sc
>
> https://ci.apache.org/builders/aoo-win7/builds/231/steps/build.pl%20--all/logs/stdio
>
> command timed out: 2 seconds without output, killing pid 13888
That's worrisome.
Why does did build step run 15 hours?
Why did sc deliver run over 5 hours?
possible reasons just speculations:
* some Antivirus slows down everything or even locks up some files
(could explain the lock up in the following builds)
* Guess sc deliver is the linking step, this takes very much memory.
   Maybe we hit a memory limit on the machine or it starts to use hard disk.
* Maybe we use just one thread ( to avoid fails due race conditions ).
Would explain total time but not long linking time.
* Maybe the assigned resources for the vm are too limited (io, cpu and
memory) for a build.

Guess to solve these 'maybe's one needs online access during a build.
Who wants to watch the build process for 15hours? :-p

> and today it stopped at a very early stage that you had already fixed,
> the "svn info":
>
> https://ci.apache.org/builders/aoo-win7/builds/232/steps/svn%20export/logs/stdio
>
> Inappropriate ioctl for device
>
That is sadly the usual behaviour. Line of interest is:
> rm: cannot remove
`build/ext_libraries/apr/wntmsci12.pro/misc/build/apr-1.4.5/Makefile.win':
Device or resource busy
This file is locked by some process. IIRC someone said build tries to
restart something and ends up locking this file.

> Jochen, Damjan, do you remember how you fixed it back at the time? Or
> was it handled in the chat session with pono Damjan mentions later in
> this thread (which would basically mean that it disappeared magically
> after a restart and some magic by Infra)?
Afraid it was never really fixed. You need to restart the whole machine
to unlock the apr makefile. So you can start a build.
Then you have to debug the reason for the long build time.

Regards Jochen



signature.asc
Description: OpenPGP digital signature

Re: procedure for going from RC to release

[Andrea Pescetti]

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-r180 
); and you call the file something like netbeans-plugin-r180.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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

RE: procedure for going from RC to release

[Dennis E. Hamilton]

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 
 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:cmar...@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-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: dev-h...@openoffice.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: procedure for going from RC to release

[Marcus]

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_.

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

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

procedure for going from RC to release

[Carl Marcum]

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-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org