Re: Releasing the Apache OpenOffice API plugin for NetBeans
oh sorry I just realized this discussion was from 4 years ago! it seemed more recent at first. I see there is a wiki page for Groovy https://wiki.openoffice.org/wiki/Groovy_UNO_Extension , and I saw now a reference to Carl's github repo https://github.com/cbmarcum/guno-extension . -- John On Fri, Nov 6, 2020 at 3:48 PM John D'Orazio < john.dora...@cappellaniauniroma3.org> wrote: > I've touched up the wiki page in the past week or so, as I've been using > the Netbeans plugin on more recent versions of Netbeans. > > I believe Patricia was asking about the wiki for the Groovy / Gradle > tests? Is there any information on how to proceed in testing the Groovy / > Gradle implementation? > > On Mon, Mar 28, 2016 at 12:58 PM Carl Marcum wrote: > >> On 03/27/2016 10:59 PM, Patricia Shanahan wrote: >> > On 3/27/2016 3:53 PM, Carl Marcum wrote: >> >> On 03/27/2016 05:01 PM, Patricia Shanahan wrote: >> >>> On 3/27/2016 12:26 PM, Andrea Pescetti wrote: >> >>> ... >> When we have three PMC members willing to commit to voting (at due >> time) >> on the NetBeans plugin, this discussion will make sense. Otherwise we >> are wasting our time. >> >>> >> >>> I generally have at least one Windows box with Netbeans installed, so >> >>> I should be able to participate. >> >> >> >> That great, You will need v. 8.1 >> > >> > Got v. 8.1 installed. >> > >> > I would like to attempt a build and test from what you now have. Is >> > there a Wiki how-to page? If not, should we be constructing one? >> > >> > Patricia >> > >> Hi Patricia, >> >> Thanks for working on this. >> >> The wiki page is here [1] the source is here [2]. >> >> Open in NetBeans, it's a NetBeans project. >> RMB on project and "Create NBM" >> >> You can then install the NBM file into NetBeans and test. >> >> The version may not have been bumped yet. Sorry I don't have time to >> check. >> >> The wiki page could use some love. I haven't had a chance to document >> the build. >> >> >> [1] https://wiki.openoffice.org/wiki/OpenOffice_NetBeans_Integration >> [2] >> >> https://svn.apache.org/repos/asf/openoffice/devtools/netbeansintegration/trunk/ >> >> Thanks, >> Carl >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org >> For additional commands, e-mail: dev-h...@openoffice.apache.org >> >> > > -- > John > >
Re: Releasing the Apache OpenOffice API plugin for NetBeans
I've touched up the wiki page in the past week or so, as I've been using the Netbeans plugin on more recent versions of Netbeans. I believe Patricia was asking about the wiki for the Groovy / Gradle tests? Is there any information on how to proceed in testing the Groovy / Gradle implementation? On Mon, Mar 28, 2016 at 12:58 PM Carl Marcum wrote: > On 03/27/2016 10:59 PM, Patricia Shanahan wrote: > > On 3/27/2016 3:53 PM, Carl Marcum wrote: > >> On 03/27/2016 05:01 PM, Patricia Shanahan wrote: > >>> On 3/27/2016 12:26 PM, Andrea Pescetti wrote: > >>> ... > When we have three PMC members willing to commit to voting (at due > time) > on the NetBeans plugin, this discussion will make sense. Otherwise we > are wasting our time. > >>> > >>> I generally have at least one Windows box with Netbeans installed, so > >>> I should be able to participate. > >> > >> That great, You will need v. 8.1 > > > > Got v. 8.1 installed. > > > > I would like to attempt a build and test from what you now have. Is > > there a Wiki how-to page? If not, should we be constructing one? > > > > Patricia > > > Hi Patricia, > > Thanks for working on this. > > The wiki page is here [1] the source is here [2]. > > Open in NetBeans, it's a NetBeans project. > RMB on project and "Create NBM" > > You can then install the NBM file into NetBeans and test. > > The version may not have been bumped yet. Sorry I don't have time to > check. > > The wiki page could use some love. I haven't had a chance to document > the build. > > > [1] https://wiki.openoffice.org/wiki/OpenOffice_NetBeans_Integration > [2] > > https://svn.apache.org/repos/asf/openoffice/devtools/netbeansintegration/trunk/ > > Thanks, > Carl > > - > To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org > For additional commands, e-mail: dev-h...@openoffice.apache.org > > -- John
Re: Releasing the Apache OpenOffice API plugin for NetBeans
On 03/27/2016 10:59 PM, Patricia Shanahan wrote: On 3/27/2016 3:53 PM, Carl Marcum wrote: On 03/27/2016 05:01 PM, Patricia Shanahan wrote: On 3/27/2016 12:26 PM, Andrea Pescetti wrote: ... When we have three PMC members willing to commit to voting (at due time) on the NetBeans plugin, this discussion will make sense. Otherwise we are wasting our time. I generally have at least one Windows box with Netbeans installed, so I should be able to participate. That great, You will need v. 8.1 Got v. 8.1 installed. I would like to attempt a build and test from what you now have. Is there a Wiki how-to page? If not, should we be constructing one? Patricia Hi Patricia, Thanks for working on this. The wiki page is here [1] the source is here [2]. Open in NetBeans, it's a NetBeans project. RMB on project and "Create NBM" You can then install the NBM file into NetBeans and test. The version may not have been bumped yet. Sorry I don't have time to check. The wiki page could use some love. I haven't had a chance to document the build. [1] https://wiki.openoffice.org/wiki/OpenOffice_NetBeans_Integration [2] https://svn.apache.org/repos/asf/openoffice/devtools/netbeansintegration/trunk/ Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Releasing the Apache OpenOffice API plugin for NetBeans
On 3/27/2016 3:53 PM, Carl Marcum wrote: On 03/27/2016 05:01 PM, Patricia Shanahan wrote: On 3/27/2016 12:26 PM, Andrea Pescetti wrote: ... When we have three PMC members willing to commit to voting (at due time) on the NetBeans plugin, this discussion will make sense. Otherwise we are wasting our time. I generally have at least one Windows box with Netbeans installed, so I should be able to participate. That great, You will need v. 8.1 Got v. 8.1 installed. I would like to attempt a build and test from what you now have. Is there a Wiki how-to page? If not, should we be constructing one? Patricia - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Releasing the Apache OpenOffice API plugin for NetBeans
On 03/27/2016 05:01 PM, Patricia Shanahan wrote: On 3/27/2016 12:26 PM, Andrea Pescetti wrote: ... When we have three PMC members willing to commit to voting (at due time) on the NetBeans plugin, this discussion will make sense. Otherwise we are wasting our time. I generally have at least one Windows box with Netbeans installed, so I should be able to participate. That great, You will need v. 8.1 Insufficient PMC members is a problem in its own right, but I don't think it changes the release policy at all. One possible solution to consider in the long term to splitting out some of this type of thing from the OpenOffice project. As a separate project it would be much less scary, and might attract more developers, and PMC members, with the specific skills. I think this particular plugin belongs here. Its sole purpose is to generate AOO extension code and is dependent on the UNO API's. As a separate project it doesn't have the necessary activity to stay at Apache nor does it require it as it is fairly mature for what it is intended for. However one could argue there is functionality that could be added. Bringing it back later if needed would be more difficult due to code IP issues. I would agree my recent efforts on Gradle integration and Groovy UNO would be better candidates to spin-off. However if we ever add Apache Groovy as a macro language (hopefully my next endeavor) and want to include that in the code base and not as an extension, it would be dependent on an outside project instead of under our control. Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Releasing the Apache OpenOffice API plugin for NetBeans
On 3/27/2016 12:26 PM, Andrea Pescetti wrote: ... When we have three PMC members willing to commit to voting (at due time) on the NetBeans plugin, this discussion will make sense. Otherwise we are wasting our time. I generally have at least one Windows box with Netbeans installed, so I should be able to participate. Insufficient PMC members is a problem in its own right, but I don't think it changes the release policy at all. One possible solution to consider in the long term to splitting out some of this type of thing from the OpenOffice project. As a separate project it would be much less scary, and might attract more developers, and PMC members, with the specific skills. Patricia - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Releasing the Apache OpenOffice API plugin for NetBeans
+1 on the three PMC members > -Original Message- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Sunday, March 27, 2016 12:26 > To: dev@openoffice.apache.org > Subject: Re: Releasing the Apache OpenOffice API plugin for NetBeans > > Dennis E. Hamilton wrote: > >> From: Andrea Pescetti > >> On 27/03/2016 Patricia Shanahan wrote: > >>> http://www.apache.org/dev/release.html. > >> Then all of us are violating the policy every time we update the > >> website. > > [orcmid] > > That is not the case for *any* Apache Project web site or the web site > for Apache itself. > > The ASF is very clear about open-source software releases and what > that means. > > It was clearly ironic, just to show that reading the words on that page > ("Releases are, by definition, anything that is published beyond the > group that owns it") without a grain of salt one could conclude that a > website fix is a release. Of course, a website fix is NOT a release. And > there is no reason to write it on the Releases page, since people have a > brain. > > > It doesn't matter what the domain of use of the software is, it > > matters that it is software made freely available as a public good. > > When we have three PMC members willing to commit to voting (at due time) > on the NetBeans plugin, this discussion will make sense. Otherwise we > are wasting our time. > > Note that if we go this way we will have to handle the previous > "release" by Carl appropriately too. But I don't want to open too many > discussions. Let's find the three PMC members willing to be involved > first. Once we have them, everything becomes easier. > > Regards, >Andrea. > > - > 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: Releasing the Apache OpenOffice API plugin for NetBeans
Dennis E. Hamilton wrote: From: Andrea Pescetti On 27/03/2016 Patricia Shanahan wrote: http://www.apache.org/dev/release.html. Then all of us are violating the policy every time we update the website. [orcmid] That is not the case for *any* Apache Project web site or the web site for Apache itself. The ASF is very clear about open-source software releases and what that means. It was clearly ironic, just to show that reading the words on that page ("Releases are, by definition, anything that is published beyond the group that owns it") without a grain of salt one could conclude that a website fix is a release. Of course, a website fix is NOT a release. And there is no reason to write it on the Releases page, since people have a brain. It doesn't matter what the domain of use of the software is, it matters that it is software made freely available as a public good. When we have three PMC members willing to commit to voting (at due time) on the NetBeans plugin, this discussion will make sense. Otherwise we are wasting our time. Note that if we go this way we will have to handle the previous "release" by Carl appropriately too. But I don't want to open too many discussions. Let's find the three PMC members willing to be involved first. Once we have them, everything becomes easier. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Releasing the Apache OpenOffice API plugin for NetBeans
> -Original Message- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Sunday, March 27, 2016 09:46 > To: dev@openoffice.apache.org > Subject: Re: Releasing the Apache OpenOffice API plugin for NetBeans > > On 27/03/2016 Patricia Shanahan wrote: > > On 3/26/2016 10:37 AM, Andrea Pescetti wrote: > >> 3) We recognize that http://svn.apache.org/viewvc/openoffice/ has > >> different areas, and that not all of them should be subject to the > same > >> policy. Just like I don't call a release vote when I change a web > page > >> (the full site is hosted under that tree, so technically I am making > a > >> "website release" every time I update a page), we could recognize > that > >> everything in devtools/ is just a set of tools that we can make > >> available with lazy consensus and no need for a formal release. This > is > >> my favorite option. > > This option does not appear to me to conform to > > http://www.apache.org/dev/release.html. > > Then all of us are violating the policy every time we update the > website. [orcmid] That is not the case for *any* Apache Project web site or the web site for Apache itself. The ASF is very clear about open-source software releases and what that means. Please. We are talking about software releases made available to the public and the duties the Foundation places on such releases with regard to intellectual property, licenses, and notifications. It doesn't matter what the domain of use of the software is, it matters that it is software made freely available as a public good. [ ... ] - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Releasing the Apache OpenOffice API plugin for NetBeans
On 27/03/2016 Patricia Shanahan wrote: On 3/26/2016 10:37 AM, Andrea Pescetti wrote: 3) We recognize that http://svn.apache.org/viewvc/openoffice/ has different areas, and that not all of them should be subject to the same policy. Just like I don't call a release vote when I change a web page (the full site is hosted under that tree, so technically I am making a "website release" every time I update a page), we could recognize that everything in devtools/ is just a set of tools that we can make available with lazy consensus and no need for a formal release. This is my favorite option. This option does not appear to me to conform to http://www.apache.org/dev/release.html. Then all of us are violating the policy every time we update the website. It's a matter of interpreting things correctly. Trunk, branches, tags are for sure subject to the standard release policy. The website is for sure not subject to it (no human with a grain of salt can imagine a release vote for a typo fix on a web page, right?). The rest is... well, in between. That suggests that a good enough justification for a deviation could get "prior, explicit board approval". How about asking the board for approval? We can ask the board for advice, why not. But my recommendation is: get three PMC members to commit to voting on this release before we explore the "real release" option. Once we know that at least three PMC members will vote, then this discussion make sense. There will be quite a few arrangements to do since (for example) we don't want to break our release tree layout, which was the subject of endless discussions in the past, but if three PMC members are available and willing to do a formal release we have the basic steps done. And actually... if we have three volunteers then we can get it done even without asking the Board! I thought about examples but I can't find anything similar. Solr is released by Lucene, see https://dist.apache.org/repos/dist/release/lucene/ but those are real end-user software packages in themselves, while here we are discussing a development tool. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Releasing the Apache OpenOffice API plugin for NetBeans
On 03/26/2016 05:58 PM, Dennis E. Hamilton wrote: -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Saturday, March 26, 2016 10:38 To: dev@openoffice.apache.org Subject: Re: Releasing the Apache OpenOffice API plugin for NetBeans On 20/03/2016 Patricia Shanahan wrote: The issue is whether it is ASF distributed software, for which ASF trademarks can appropriately be used. I think it is and should continue to be ASF distributed software. [ ... ] 2) We go for the full release vote, but this is a serious process, much more than what is needed for this tool. If one really wants to do it right, you need a release manager, binding votes, sources in dist/, GPG signing the way the ASF wants it, old sources preserved in the ASF archives... [orcmid] I'm puzzled about one thing. There are small Apache projects. I suspect there are more small ones than large ones. Yet, making releases does not seem to be that burdensome to those projects. They have it work and they satisfy the Apache requirements for releases and the integrity of Apache-released code. I think the biggest issue with these devtools in general for the project is that it's not AOO core code. Almost all of us use AOO or we wouldn't be here. Only a few use this NetBeans tool and fewer still (me) use the newer tools I have been working on for Gradle and Groovy which I hope will change once people see value in them. I have no issue going through the release process with these tools as long as enough people don't mind the verification process. The UNO Tools work strikes me as a commendable way of spinning out useful releases on the same cadence as small projects manage. (It is also a small case that sort of demonstrates the process and how it is achievable.) Agreed. Now it is a bit of a problem that this has been a one-committer effort, and it would be great if supported by more contributors. Having some community building around this component of AOO would be valuable. Actually there have been solid contributions by others as far as the NetBeans plugin is concerned. The most resent being the Japanese message bundles for AOO branding which is the purpose of this release discussion. Spanish and Italian contributions have also been made. With that, the release process should become systematic and sustainability would also be addressed. Isn't that worth looking into? I think there is a strong case for these tools to be properly released and will put them forward as I have time. Providing tools for extension developers only helps our ecosystem. As more extension developers use the new tools I think more people will find a way to contribute as I did. On a similar topic I posted a [DISCUSS] email [1] looking for help trying out the Groovy UNO API extension and haven't got any takers. [HELPWANTED] may have been a better subject. I would like to get a vote ready for that one soon but I was hoping a few people would test it first if anybody has a few spare cycles :) [1] http://mail-archives.apache.org/mod_mbox/openoffice-dev/201603.mbox/%3C56E60EF7.4040304%40apache.org%3E Thanks, Carl - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Releasing the Apache OpenOffice API plugin for NetBeans
On 3/26/2016 2:58 PM, Dennis E. Hamilton wrote: -Original Message- From: Andrea Pescetti [mailto:pesce...@apache.org] Sent: Saturday, March 26, 2016 10:38 To: dev@openoffice.apache.org Subject: Re: Releasing the Apache OpenOffice API plugin for NetBeans On 20/03/2016 Patricia Shanahan wrote: The issue is whether it is ASF distributed software, for which ASF trademarks can appropriately be used. I think it is and should continue to be ASF distributed software. [ ... ] 2) We go for the full release vote, but this is a serious process, much more than what is needed for this tool. If one really wants to do it right, you need a release manager, binding votes, sources in dist/, GPG signing the way the ASF wants it, old sources preserved in the ASF archives... [orcmid] I'm puzzled about one thing. There are small Apache projects. I suspect there are more small ones than large ones. Yet, making releases does not seem to be that burdensome to those projects. They have it work and they satisfy the Apache requirements for releases and the integrity of Apache-released code. The UNO Tools work strikes me as a commendable way of spinning out useful releases on the same cadence as small projects manage. (It is also a small case that sort of demonstrates the process and how it is achievable.) Now it is a bit of a problem that this has been a one-committer effort, and it would be great if supported by more contributors. Having some community building around this component of AOO would be valuable. With that, the release process should become systematic and sustainability would also be addressed. Isn't that worth looking into? +1 We need to train release managers, myself included. It makes sense to me to practice on smaller, simpler releases before doing a full AOO release. Patricia - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Releasing the Apache OpenOffice API plugin for NetBeans
On 3/26/2016 10:37 AM, Andrea Pescetti wrote: On 20/03/2016 Patricia Shanahan wrote: The issue is whether it is ASF distributed software, for which ASF trademarks can appropriately be used. I think it is and should continue to be ASF distributed software. ... 3) We recognize that http://svn.apache.org/viewvc/openoffice/ has different areas, and that not all of them should be subject to the same policy. Just like I don't call a release vote when I change a web page (the full site is hosted under that tree, so technically I am making a "website release" every time I update a page), we could recognize that everything in devtools/ is just a set of tools that we can make available with lazy consensus and no need for a formal release. This is my favorite option. ... This option does not appear to me to conform to http://www.apache.org/dev/release.html. The policy does say: "Deviations from this policy may have an adverse effect on the legal shield's effectiveness, or the insurance premiums Apache pays to protect officers and directors, so are strongly discouraged without prior, explicit board approval. Do note however that organizationally we prefer robust, reviewable decision-making over efficient decision-making, so if you are thinking of proposing an alternative process for the board to consider, be sure your targets reflect this." That suggests that a good enough justification for a deviation could get "prior, explicit board approval". How about asking the board for approval? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
RE: Releasing the Apache OpenOffice API plugin for NetBeans
> -Original Message- > From: Andrea Pescetti [mailto:pesce...@apache.org] > Sent: Saturday, March 26, 2016 10:38 > To: dev@openoffice.apache.org > Subject: Re: Releasing the Apache OpenOffice API plugin for NetBeans > > On 20/03/2016 Patricia Shanahan wrote: > > The issue is whether it is ASF distributed software, for which ASF > > trademarks can appropriately be used. I think it is and should > continue > > to be ASF distributed software. > [ ... ] > 2) We go for the full release vote, but this is a serious process, much > more than what is needed for this tool. If one really wants to do it > right, you need a release manager, binding votes, sources in dist/, GPG > signing the way the ASF wants it, old sources preserved in the ASF > archives... [orcmid] I'm puzzled about one thing. There are small Apache projects. I suspect there are more small ones than large ones. Yet, making releases does not seem to be that burdensome to those projects. They have it work and they satisfy the Apache requirements for releases and the integrity of Apache-released code. The UNO Tools work strikes me as a commendable way of spinning out useful releases on the same cadence as small projects manage. (It is also a small case that sort of demonstrates the process and how it is achievable.) Now it is a bit of a problem that this has been a one-committer effort, and it would be great if supported by more contributors. Having some community building around this component of AOO would be valuable. With that, the release process should become systematic and sustainability would also be addressed. Isn't that worth looking into? - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Releasing the Apache OpenOffice API plugin for NetBeans
On 20/03/2016 Patricia Shanahan wrote: The issue is whether it is ASF distributed software, for which ASF trademarks can appropriately be used. I think it is and should continue to be ASF distributed software. So far we've adopted another approach: it is a development tool meant to ease OpenOffice development, but it is 100% unrelated to the "real" OpenOffice source code. And we've let Carl release it (in the sense of making it available on netbeans.org) under lazy consensus. I see four options: 1) Carl moves his sources to Github, Gitlab, Sourceforge, you name it, and he does his releases from there. This is a Netbeans plugins focused on the OpenOffice API, so I'm not even sure we have a say about the trademarks, but a lazy consensus would settle it. I don't like this option since moving stuff out of the project is bad in general. 2) We go for the full release vote, but this is a serious process, much more than what is needed for this tool. If one really wants to do it right, you need a release manager, binding votes, sources in dist/, GPG signing the way the ASF wants it, old sources preserved in the ASF archives... 3) We recognize that http://svn.apache.org/viewvc/openoffice/ has different areas, and that not all of them should be subject to the same policy. Just like I don't call a release vote when I change a web page (the full site is hosted under that tree, so technically I am making a "website release" every time I update a page), we could recognize that everything in devtools/ is just a set of tools that we can make available with lazy consensus and no need for a formal release. This is my favorite option. 4) When we make a "real" OpenOffice release, we include the devtools (or some devtools) source in it, so that the whole set has the blessing of the project. This could work too, at least in the long term. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Releasing the Apache OpenOffice API plugin for NetBeans
+1 also. The issue is whether it is ASF distributed software, for which ASF trademarks can appropriately be used. I think it is and should continue to be ASF distributed software. Releasing the source, on an ASF server, with a PMC release vote, is required for ASF distributed software. Derived artifacts can also be made available other ways, and that may be the way most users get the software. See the number of downloads of AOO installation files from SourceForge. Patricia On 3/20/2016 3:25 PM, Dennis E. Hamilton wrote: +1 I think exploring that source being at ASF and the artifact be elsewhere is a good idea. -Original Message- From: Carl Marcum [mailto:cmar...@apache.org] Sent: Sunday, March 20, 2016 09:49 To: dev@openoffice.apache.org Subject: Re: Releasing the Apache OpenOffice API plugin for NetBeans [ ... ] I do prefer this is from the project and if it needs a vote that's okay I can put together instructions. I just didn't want take people away from other tasks unless that's the way we want it done. A few issues I'm not sure how to handle as an official ASF release in this case. 1. You can host the .NBM artifact somewhere besides NetBeans.org but the plugin page I referenced would become nothing more than an advertisement and not count downloads, comments, votes, etc. For those features and for the NetBeans IDE updater mechanism to work it must be hosted at NetBeans.org. Maybe hosted at ASF and Netbeans would count? 2. The artifact is binary only with no source. 3. The artifact must be Java keytool signed and not PGP. At least the one hosted at Netbeans.org. 4. The artifact is built with the NetBeans IDE which PMC members would need to install. Maybe we can come up with an acceptable procedure where the source is zipped and PGP signed and becomes the release hosted at ASF and a NetBeans.org compatible artifact is created from it to satisfy both requirements. 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 - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Releasing the Apache OpenOffice API plugin for NetBeans
Am 03/20/2016 08:18 PM, schrieb Kay Schenk: On 03/20/2016 09:48 AM, Carl Marcum wrote: On 03/20/2016 10:54 AM, Dennis E. Hamilton wrote: [BCC to the PMC] > From the Chair, If this is considered an Apache release and identified as provided by the Apache OpenOffice project, then the Apache release requirements must be satisfied. I know of no records on the AOO project obtaining an exception for this case from the Foundation. If there are any, please make known where that information is preserved. There is no difficulty with the formalities other than requiring patience and ensuring that certain requirements on release packaging are satisfied. The recent difficulty is not having enough PMC members who were able to satisfy the binding vote requirement. So long as there are, as there seem to be now, this can go forward the same as the previous release that Carl escorted through the process. One step that would be useful to take is having some identification of the UNO Tools version releases that progresses separately from the Apache OpenOffice main product release cadence. It would be very useful and practical to have a naming of files and versioning in the source-code release [candidates] that is distinct from the AOO version progression in some manner, since only some of these will be bundled in the AOO releases of full OpenOffice. I imagine with practice, the delivery of the UNO Tools and facilitation of their use by others will become straightforward. There was already discussion of ASF release policies on a related thread. Here is the relevant policy and practice material. <http://www.apache.org/dev/release-publishing.html>, along with <http://apache.org/dev/release.html>. Note that any committer (with a registered PGP signature) can pull together a release, although it is the PMC that is responsible for assuring its acceptability and approval. Acceptability is also in specific, narrow terms. See the rules for voting on releases and what those who vote approval are required to have done. Read from <http://apache.org/dev/release.html#approving-a-release> down to just before the Release Distribution topic. The Apache OpenOffice project does not have autonomy on this matter. A key responsibility of the PMC is assuring that the release process and its integrity are achieved and sustained. It happens that the ability of a PMC to accomplish releases in this manner is an indicator of the project's viability. If the Apache OpenOffice Project Management Committee words and procedurally-approves a narrow, specific request for an exception with regard to the UNO Tools of Apache OpenOffice, it can be taken to Apache legal and elsewhere where review and approval at the Foundation level is required. - Dennis -Original Message- From: Marcus [mailto:marcus.m...@wtnet.de] Sent: Sunday, March 20, 2016 04:31 To: dev@openoffice.apache.org Subject: Re: Releasing the Apache OpenOffice API plugin for NetBeans Am 03/20/2016 11:29 AM, schrieb Andrea Pescetti: On 20/03/2016 Marcus wrote: Am 03/18/2016 12:19 AM, schrieb Carl Marcum: Do we need to treat the submission of plugin artifacts for availability at NetBeans.org and through their update mechanism as official project releases requiring a vote? ... @all: Is there anything that would speak against that Carl is going on with this procedure from the past? I suggest that we continue as in the past. The NetBeans plugin is not related, code-wise, to the OpenOffice "main" releases at all, and we can just let Carl maintain it with lazy consensus as usual, with no need for a formal release. that's good. It's also my impression that we don't need any more formal way. @Rory: Sorry, it seems I should have point out my opinion more visible. ;-) Marcus I do prefer this is from the project and if it needs a vote that's okay I can put together instructions. I just didn't want take people away from other tasks unless that's the way we want it done. A few issues I'm not sure how to handle as an official ASF release in this case. 1. You can host the .NBM artifact somewhere besides NetBeans.org but the plugin page I referenced would become nothing more than an advertisement and not count downloads, comments, votes, etc. For those features and for the NetBeans IDE updater mechanism to work it must be hosted at NetBeans.org. Maybe hosted at ASF and Netbeans would count? 2. The artifact is binary only with no source. 3. The artifact must be Java keytool signed and not PGP. At least the one hosted at Netbeans.org. 4. The artifact is built with the NetBeans IDE which PMC members would need to install. Maybe we can come up with an acceptable procedure where the source is zipped and PGP signed and becomes the release hosted at ASF and a NetBeans.org compatible artifact is created from it to satisfy both requirements. Tha
RE: Releasing the Apache OpenOffice API plugin for NetBeans
+1 I think exploring that source being at ASF and the artifact be elsewhere is a good idea. > -Original Message- > From: Carl Marcum [mailto:cmar...@apache.org] > Sent: Sunday, March 20, 2016 09:49 > To: dev@openoffice.apache.org > Subject: Re: Releasing the Apache OpenOffice API plugin for NetBeans [ ... ] > I do prefer this is from the project and if it needs a vote that's okay > I can put together instructions. > > I just didn't want take people away from other tasks unless that's the > way we want it done. > > A few issues I'm not sure how to handle as an official ASF release in > this case. > > 1. You can host the .NBM artifact somewhere besides NetBeans.org but the > plugin page I referenced would become nothing more than an advertisement > and not count downloads, comments, votes, etc. For those features and > for the NetBeans IDE updater mechanism to work it must be hosted at > NetBeans.org. > Maybe hosted at ASF and Netbeans would count? > > 2. The artifact is binary only with no source. > > 3. The artifact must be Java keytool signed and not PGP. At least the > one hosted at Netbeans.org. > > 4. The artifact is built with the NetBeans IDE which PMC members would > need to install. > > Maybe we can come up with an acceptable procedure where the source is > zipped and PGP signed and becomes the release hosted at ASF and a > NetBeans.org compatible artifact is created from it to satisfy both > requirements. > > 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: Releasing the Apache OpenOffice API plugin for NetBeans
On 03/20/2016 03:18 PM, Kay Schenk wrote: On 03/20/2016 09:48 AM, Carl Marcum wrote: On 03/20/2016 10:54 AM, Dennis E. Hamilton wrote: [BCC to the PMC] >From the Chair, If this is considered an Apache release and identified as provided by the Apache OpenOffice project, then the Apache release requirements must be satisfied. I know of no records on the AOO project obtaining an exception for this case from the Foundation. If there are any, please make known where that information is preserved. There is no difficulty with the formalities other than requiring patience and ensuring that certain requirements on release packaging are satisfied. The recent difficulty is not having enough PMC members who were able to satisfy the binding vote requirement. So long as there are, as there seem to be now, this can go forward the same as the previous release that Carl escorted through the process. One step that would be useful to take is having some identification of the UNO Tools version releases that progresses separately from the Apache OpenOffice main product release cadence. It would be very useful and practical to have a naming of files and versioning in the source-code release [candidates] that is distinct from the AOO version progression in some manner, since only some of these will be bundled in the AOO releases of full OpenOffice. I imagine with practice, the delivery of the UNO Tools and facilitation of their use by others will become straightforward. There was already discussion of ASF release policies on a related thread. Here is the relevant policy and practice material. <http://www.apache.org/dev/release-publishing.html>, along with <http://apache.org/dev/release.html>. Note that any committer (with a registered PGP signature) can pull together a release, although it is the PMC that is responsible for assuring its acceptability and approval. Acceptability is also in specific, narrow terms. See the rules for voting on releases and what those who vote approval are required to have done. Read from <http://apache.org/dev/release.html#approving-a-release> down to just before the Release Distribution topic. The Apache OpenOffice project does not have autonomy on this matter. A key responsibility of the PMC is assuring that the release process and its integrity are achieved and sustained. It happens that the ability of a PMC to accomplish releases in this manner is an indicator of the project's viability. If the Apache OpenOffice Project Management Committee words and procedurally-approves a narrow, specific request for an exception with regard to the UNO Tools of Apache OpenOffice, it can be taken to Apache legal and elsewhere where review and approval at the Foundation level is required. - Dennis -Original Message- From: Marcus [mailto:marcus.m...@wtnet.de] Sent: Sunday, March 20, 2016 04:31 To: dev@openoffice.apache.org Subject: Re: Releasing the Apache OpenOffice API plugin for NetBeans Am 03/20/2016 11:29 AM, schrieb Andrea Pescetti: On 20/03/2016 Marcus wrote: Am 03/18/2016 12:19 AM, schrieb Carl Marcum: Do we need to treat the submission of plugin artifacts for availability at NetBeans.org and through their update mechanism as official project releases requiring a vote? ... @all: Is there anything that would speak against that Carl is going on with this procedure from the past? I suggest that we continue as in the past. The NetBeans plugin is not related, code-wise, to the OpenOffice "main" releases at all, and we can just let Carl maintain it with lazy consensus as usual, with no need for a formal release. that's good. It's also my impression that we don't need any more formal way. @Rory: Sorry, it seems I should have point out my opinion more visible. ;-) Marcus I do prefer this is from the project and if it needs a vote that's okay I can put together instructions. I just didn't want take people away from other tasks unless that's the way we want it done. A few issues I'm not sure how to handle as an official ASF release in this case. 1. You can host the .NBM artifact somewhere besides NetBeans.org but the plugin page I referenced would become nothing more than an advertisement and not count downloads, comments, votes, etc. For those features and for the NetBeans IDE updater mechanism to work it must be hosted at NetBeans.org. Maybe hosted at ASF and Netbeans would count? 2. The artifact is binary only with no source. 3. The artifact must be Java keytool signed and not PGP. At least the one hosted at Netbeans.org. 4. The artifact is built with the NetBeans IDE which PMC members would need to install. Maybe we can come up with an acceptable procedure where the source is zipped and PGP signed and becomes the release hosted at ASF and a NetBeans.org compatible artifact is created from it to satisfy both requirements. Th
Re: Releasing the Apache OpenOffice API plugin for NetBeans
On 03/20/2016 09:48 AM, Carl Marcum wrote: > > > On 03/20/2016 10:54 AM, Dennis E. Hamilton wrote: >> [BCC to the PMC] >> >> >From the Chair, >> >> If this is considered an Apache release and identified as >> provided by the Apache OpenOffice project, then the Apache >> release requirements must be satisfied. >> >> I know of no records on the AOO project obtaining an >> exception for this case from the Foundation. If there are >> any, please make known where that information is preserved. >> >> There is no difficulty with the formalities other than >> requiring patience and ensuring that certain requirements >> on release packaging are satisfied. The recent difficulty >> is not having enough PMC members who were able to satisfy >> the binding vote requirement. So long as there are, as >> there seem to be now, this can go forward the same as the >> previous release that Carl escorted through the process. >> >> One step that would be useful to take is having some >> identification of the UNO Tools version releases that >> progresses separately from the Apache OpenOffice main >> product release cadence. It would be very useful and >> practical to have a naming of files and versioning in the >> source-code release [candidates] that is distinct from the >> AOO version progression in some manner, since only some of >> these will be bundled in the AOO releases of full >> OpenOffice. I imagine with practice, the delivery of the >> UNO Tools and facilitation of their use by others will >> become straightforward. >> >> There was already discussion of ASF release policies on a >> related thread. Here is the relevant policy and practice >> material. >> >> <http://www.apache.org/dev/release-publishing.html>, >> along with >> >> <http://apache.org/dev/release.html>. >> >> Note that any committer (with a registered PGP >> signature) can pull >> together a release, although it is the PMC that is >> responsible for >> assuring its acceptability and approval. >> Acceptability is also in >> specific, narrow terms. See the rules for voting on >> releases and >> what those who vote approval are required to have >> done. Read from >> >> <http://apache.org/dev/release.html#approving-a-release> >> down to >> just before the Release Distribution topic. >> >> The Apache OpenOffice project does not have autonomy on >> this matter. A key responsibility of the PMC is assuring >> that the release process and its integrity are achieved >> and sustained. It happens that the ability of a PMC to >> accomplish releases in this manner is an indicator of the >> project's viability. >> >> If the Apache OpenOffice Project Management Committee >> words and procedurally-approves a narrow, specific request >> for an exception with regard to the UNO Tools of Apache >> OpenOffice, it can be taken to Apache legal and elsewhere >> where review and approval at the Foundation level is >> required. >> >> - Dennis >> >>> -Original Message- >>> From: Marcus [mailto:marcus.m...@wtnet.de] >>> Sent: Sunday, March 20, 2016 04:31 >>> To: dev@openoffice.apache.org >>> Subject: Re: Releasing the Apache OpenOffice API plugin >>> for NetBeans >>> >>> Am 03/20/2016 11:29 AM, schrieb Andrea Pescetti: >>>> On 20/03/2016 Marcus wrote: >>>>> Am 03/18/2016 12:19 AM, schrieb Carl Marcum: >>>>>> Do we need to treat the submission of plugin artifacts >>>>>> for >>> availability >>>>>> at NetBeans.org and through their update mechanism as >>>>>> official >>> project >>>>>> releases requiring a vote? ... >>>>> @all: >>>>> Is there anything that would speak against that Carl is >>>>> going on with >>>>> this procedure from the past? >>>> I suggest that we continue as in the past. The NetBeans >>>> plugin is not >>>> related, code-wise, to the OpenOffice "main" releases at >>>> all, and we >>> can >>>> just let Carl maintain it with lazy consensus as usual, >>>> with no need >>> for >>>> a formal release. >>> that's good. It's also my impression that we don't need >>> any more formal >>> way. >>> >>> @Rory: >>> Sorry, it
Re: Releasing the Apache OpenOffice API plugin for NetBeans
On 03/20/2016 10:54 AM, Dennis E. Hamilton wrote: [BCC to the PMC] >From the Chair, If this is considered an Apache release and identified as provided by the Apache OpenOffice project, then the Apache release requirements must be satisfied. I know of no records on the AOO project obtaining an exception for this case from the Foundation. If there are any, please make known where that information is preserved. There is no difficulty with the formalities other than requiring patience and ensuring that certain requirements on release packaging are satisfied. The recent difficulty is not having enough PMC members who were able to satisfy the binding vote requirement. So long as there are, as there seem to be now, this can go forward the same as the previous release that Carl escorted through the process. One step that would be useful to take is having some identification of the UNO Tools version releases that progresses separately from the Apache OpenOffice main product release cadence. It would be very useful and practical to have a naming of files and versioning in the source-code release [candidates] that is distinct from the AOO version progression in some manner, since only some of these will be bundled in the AOO releases of full OpenOffice. I imagine with practice, the delivery of the UNO Tools and facilitation of their use by others will become straightforward. There was already discussion of ASF release policies on a related thread. Here is the relevant policy and practice material. <http://www.apache.org/dev/release-publishing.html>, along with <http://apache.org/dev/release.html>. Note that any committer (with a registered PGP signature) can pull together a release, although it is the PMC that is responsible for assuring its acceptability and approval. Acceptability is also in specific, narrow terms. See the rules for voting on releases and what those who vote approval are required to have done. Read from <http://apache.org/dev/release.html#approving-a-release> down to just before the Release Distribution topic. The Apache OpenOffice project does not have autonomy on this matter. A key responsibility of the PMC is assuring that the release process and its integrity are achieved and sustained. It happens that the ability of a PMC to accomplish releases in this manner is an indicator of the project's viability. If the Apache OpenOffice Project Management Committee words and procedurally-approves a narrow, specific request for an exception with regard to the UNO Tools of Apache OpenOffice, it can be taken to Apache legal and elsewhere where review and approval at the Foundation level is required. - Dennis -Original Message- From: Marcus [mailto:marcus.m...@wtnet.de] Sent: Sunday, March 20, 2016 04:31 To: dev@openoffice.apache.org Subject: Re: Releasing the Apache OpenOffice API plugin for NetBeans Am 03/20/2016 11:29 AM, schrieb Andrea Pescetti: On 20/03/2016 Marcus wrote: Am 03/18/2016 12:19 AM, schrieb Carl Marcum: Do we need to treat the submission of plugin artifacts for availability at NetBeans.org and through their update mechanism as official project releases requiring a vote? ... @all: Is there anything that would speak against that Carl is going on with this procedure from the past? I suggest that we continue as in the past. The NetBeans plugin is not related, code-wise, to the OpenOffice "main" releases at all, and we can just let Carl maintain it with lazy consensus as usual, with no need for a formal release. that's good. It's also my impression that we don't need any more formal way. @Rory: Sorry, it seems I should have point out my opinion more visible. ;-) Marcus - 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 I do prefer this is from the project and if it needs a vote that's okay I can put together instructions. I just didn't want take people away from other tasks unless that's the way we want it done. A few issues I'm not sure how to handle as an official ASF release in this case. 1. You can host the .NBM artifact somewhere besides NetBeans.org but the plugin page I referenced would become nothing more than an advertisement and not count downloads, comments, votes, etc. For those features and for the NetBeans IDE updater mechanism to work it must be hosted at NetBeans.org. Maybe hosted at ASF and Netbeans would count? 2. The artifact is binary only with no source. 3. The artifact must be Java keytool signed and not PGP. At least the one hosted
RE: Releasing the Apache OpenOffice API plugin for NetBeans
[BCC to the PMC] >From the Chair, If this is considered an Apache release and identified as provided by the Apache OpenOffice project, then the Apache release requirements must be satisfied. I know of no records on the AOO project obtaining an exception for this case from the Foundation. If there are any, please make known where that information is preserved. There is no difficulty with the formalities other than requiring patience and ensuring that certain requirements on release packaging are satisfied. The recent difficulty is not having enough PMC members who were able to satisfy the binding vote requirement. So long as there are, as there seem to be now, this can go forward the same as the previous release that Carl escorted through the process. One step that would be useful to take is having some identification of the UNO Tools version releases that progresses separately from the Apache OpenOffice main product release cadence. It would be very useful and practical to have a naming of files and versioning in the source-code release [candidates] that is distinct from the AOO version progression in some manner, since only some of these will be bundled in the AOO releases of full OpenOffice. I imagine with practice, the delivery of the UNO Tools and facilitation of their use by others will become straightforward. There was already discussion of ASF release policies on a related thread. Here is the relevant policy and practice material. <http://www.apache.org/dev/release-publishing.html>, along with <http://apache.org/dev/release.html>. Note that any committer (with a registered PGP signature) can pull together a release, although it is the PMC that is responsible for assuring its acceptability and approval. Acceptability is also in specific, narrow terms. See the rules for voting on releases and what those who vote approval are required to have done. Read from <http://apache.org/dev/release.html#approving-a-release> down to just before the Release Distribution topic. The Apache OpenOffice project does not have autonomy on this matter. A key responsibility of the PMC is assuring that the release process and its integrity are achieved and sustained. It happens that the ability of a PMC to accomplish releases in this manner is an indicator of the project's viability. If the Apache OpenOffice Project Management Committee words and procedurally-approves a narrow, specific request for an exception with regard to the UNO Tools of Apache OpenOffice, it can be taken to Apache legal and elsewhere where review and approval at the Foundation level is required. - Dennis > -Original Message- > From: Marcus [mailto:marcus.m...@wtnet.de] > Sent: Sunday, March 20, 2016 04:31 > To: dev@openoffice.apache.org > Subject: Re: Releasing the Apache OpenOffice API plugin for NetBeans > > Am 03/20/2016 11:29 AM, schrieb Andrea Pescetti: > > On 20/03/2016 Marcus wrote: > >> Am 03/18/2016 12:19 AM, schrieb Carl Marcum: > >>> Do we need to treat the submission of plugin artifacts for > availability > >>> at NetBeans.org and through their update mechanism as official > project > >>> releases requiring a vote? ... > >> @all: > >> Is there anything that would speak against that Carl is going on with > >> this procedure from the past? > > > > I suggest that we continue as in the past. The NetBeans plugin is not > > related, code-wise, to the OpenOffice "main" releases at all, and we > can > > just let Carl maintain it with lazy consensus as usual, with no need > for > > a formal release. > > that's good. It's also my impression that we don't need any more formal > way. > > @Rory: > Sorry, it seems I should have point out my opinion more visible. ;-) > > Marcus > > - > 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: Releasing the Apache OpenOffice API plugin for NetBeans
Am 03/20/2016 11:29 AM, schrieb Andrea Pescetti: On 20/03/2016 Marcus wrote: Am 03/18/2016 12:19 AM, schrieb Carl Marcum: Do we need to treat the submission of plugin artifacts for availability at NetBeans.org and through their update mechanism as official project releases requiring a vote? ... @all: Is there anything that would speak against that Carl is going on with this procedure from the past? I suggest that we continue as in the past. The NetBeans plugin is not related, code-wise, to the OpenOffice "main" releases at all, and we can just let Carl maintain it with lazy consensus as usual, with no need for a formal release. that's good. It's also my impression that we don't need any more formal way. @Rory: Sorry, it seems I should have point out my opinion more visible. ;-) Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Releasing the Apache OpenOffice API plugin for NetBeans
On 20/03/2016 Marcus wrote: Am 03/18/2016 12:19 AM, schrieb Carl Marcum: Do we need to treat the submission of plugin artifacts for availability at NetBeans.org and through their update mechanism as official project releases requiring a vote? ... @all: Is there anything that would speak against that Carl is going on with this procedure from the past? I suggest that we continue as in the past. The NetBeans plugin is not related, code-wise, to the OpenOffice "main" releases at all, and we can just let Carl maintain it with lazy consensus as usual, with no need for a formal release. Regards, Andrea. - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Releasing the Apache OpenOffice API plugin for NetBeans
On Sun, 20 Mar 2016 10:04:43 +0100 Marcus wrote: > Am 03/18/2016 12:19 AM, schrieb Carl Marcum: > > Do we need to treat the submission of plugin artifacts for availability > > at NetBeans.org and through their update mechanism as official project > > releases requiring a vote? > > > > If so, what would the verification procedure look like? > > > > We had the first Japanese language update for our Apache branding > > contributed recently and I would like to create an update. > > > > In recent years these artifacts have been built and signed by me and > > submitted using lazy consensus and I have tagged SVN afterward. > > > > You can view the NetBeans page here [1]. > > > > [1] http://plugins.netbeans.org/plugin/57917/apache-openoffice-api-plugin > > @all: > Is there anything that would speak against that Carl is going on with > this procedure from the past? > > Marcus I am completely happy for members with a proven record in a particular area to upgrade or otherwise improve that area without going through complicated formalities. I trust to their goodwill and expertise to co-operate should it prove that such changes are later found to be undesirable. There is a need for protocols, but it seems to me that there is too much bureaucracy, leading to too much hot air discussion and too little action, in "the Apache way". -- Rory O'Farrell - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org
Re: Releasing the Apache OpenOffice API plugin for NetBeans
Am 03/18/2016 12:19 AM, schrieb Carl Marcum: Do we need to treat the submission of plugin artifacts for availability at NetBeans.org and through their update mechanism as official project releases requiring a vote? If so, what would the verification procedure look like? We had the first Japanese language update for our Apache branding contributed recently and I would like to create an update. In recent years these artifacts have been built and signed by me and submitted using lazy consensus and I have tagged SVN afterward. You can view the NetBeans page here [1]. [1] http://plugins.netbeans.org/plugin/57917/apache-openoffice-api-plugin @all: Is there anything that would speak against that Carl is going on with this procedure from the past? Marcus - To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org For additional commands, e-mail: dev-h...@openoffice.apache.org