Re: procedure for going from RC to release

2016-04-04 Thread Carl Marcum 

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,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




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

Re: procedure for going from RC to release

2016-04-03 Thread 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

2016-04-03 Thread 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

2016-04-03 Thread 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

2016-04-03 Thread 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

2016-04-03 Thread 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

2016-04-03 Thread 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

2016-04-03 Thread 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

Re: procedure for going from RC to release

2016-04-03 Thread 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: procedure for going from RC to release

2016-04-03 Thread 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

2016-04-03 Thread 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

2016-04-03 Thread 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