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.

Thanks,
Carl



I think if the plugin is hosted at NetBeans.org as it has
been in the past, there is no need at all for a vote. A
plugin like this seems very similar to an extension in some
respects.

On the other hand, since it is NOT an extension per se,
should plugins of this nature be included in the Apache
OpenOffice SDK even though it is specific to NetBeans?
This is part of our distribution that is included in our
release vote. Maybe the SDK would be a good place for this
plugin.

Thoughts?

when the plugin needs to be placed on Netbeans.org to work at all, then IMHO it doesn't make sense to place it somewhere else - also not additionally.

To keep the source in our SVN and to put the binary where it should be is a good solution.

Marcus

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

Reply via email to