Re: [OT] ApacheCon

2016-03-20 Thread Patricia Shanahan

On 3/20/2016 10:02 AM, Carl Marcum wrote:

On 03/16/2016 08:23 PM, Patricia Shanahan wrote:

Are any of you planning to attend the North America ApacheCon? I have
not yet decided whether to go.

Patricia

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



I would have liked to attend but my TAC application wasn't successful.


TAC was apparently faced with an unusually large number of high quality 
applications, and had to tighten their criteria, even with some extra 
money. :-(



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



RE: Can we add the value "N/A" to the Target Milestone field

2016-03-20 Thread Dennis E. Hamilton
Thanks for the "None" Target, Marcus.

> -Original Message-
> From: Marcus [mailto:marcus.m...@wtnet.de]
> Sent: Sunday, March 20, 2016 15:38
> To: dev@openoffice.apache.org
> Cc: q...@openoffice.apache.org
> Subject: Re: Can we add the value "N/A" to the Target Milestone field
> 
> Am 03/20/2016 09:08 PM, schrieb Kay Schenk:
> > We seem to have a number of issues in BZ that are now listed
> > as Resolved/Fixed but don't seem to pertain to an actual
> > upcoming release.
> >
> > Examples:
> > https://bz.apache.org/ooo/show_bug.cgi?id=126652
> > https://bz.apache.org/ooo/show_bug.cgi?id=126828
> >
> > Can we add something like "N/A" or the like to our Target
> > Milestone field rather than the default "--" so we know
> > these should never be considered for a release?
> 
> sounds reasonable. I've added an "None" to the list of available
> milestones for many products (the application modules and related
> things).
> 
> Marcus
> 
> 
> -
> To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: qa-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

2016-03-20 Thread Patricia Shanahan

+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: [CWiki] Account Whitelisting

2016-03-20 Thread Keith N. McKenna
Candaises Williams wrote:
> Username: Candaises C. Williams
> Real Name: Candaises C. WIlliams
> 
Candaises;
Have you created that account on the cwiki yet? The procedure for the
cwiki is that you create the account by filling out the form at
https://cwiki.apache.org/confluence/signup.action. Once that is done you
send the request to white-list the account to the list and one of the
admins will white-list the account.

Regards
Keith N. McKenna



signature.asc
Description: OpenPGP digital signature


RE: Can we add the value "N/A" to the Target Milestone field

2016-03-20 Thread Dennis E. Hamilton
I want to clarify this.

I think the problem might be that "Resolved - Fixed" is being used incorrectly. 
As far as I know, there are many cases where this resolution is used where one 
of "Resolved - Not an Issue" (though not too often), "Resolved - 
Irreproducible", "Resolved - Won't Fix", or "Resolved - Obsolete" should be 
used.

Is that what you are seeing, Kay?

In those cases, it is preferable to change the resolution.

> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Sunday, March 20, 2016 14:09
> To: q...@openoffice.apache.org; dev@openoffice.apache.org
> Subject: Re: Can we add the value "N/A" to the Target Milestone field
> 
> Kay Schenk wrote:
> > We seem to have a number of issues in BZ that are now listed
> > as Resolved/Fixed but don't seem to pertain to an actual
> > upcoming release.
> 
> Everything that was marked RESOLVED FIXED will be in 4.2.0. So 4.2.0 is
> a perfectly valid value for these cases.
> 
> Just to be clear: 4.1.2 was a maintenance release and issues had to be
> approved as release blockers in that case. 4.2.0 will be a normal
> release, made from trunk, so everything that is on trunk (untile a
> certain moment when we will decide to branch) will be into it
> automatically. So the target is 4.2.0 in those cases.
> 
> Regards,
>Andrea.
> 
> -
> To unsubscribe, e-mail: qa-unsubscr...@openoffice.apache.org
> For additional commands, e-mail: qa-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

2016-03-20 Thread Marcus

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.

 ,
along with

 .

 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


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

Re: Can we add the value "N/A" to the Target Milestone field

2016-03-20 Thread Marcus

Am 03/20/2016 09:08 PM, schrieb Kay Schenk:

We seem to have a number of issues in BZ that are now listed
as Resolved/Fixed but don't seem to pertain to an actual
upcoming release.

Examples:
https://bz.apache.org/ooo/show_bug.cgi?id=126652
https://bz.apache.org/ooo/show_bug.cgi?id=126828

Can we add something like "N/A" or the like to our Target
Milestone field rather than the default "--" so we know
these should never be considered for a release?


sounds reasonable. I've added an "None" to the list of available 
milestones for many products (the application modules and related things).


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

2016-03-20 Thread Dennis E. Hamilton
+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

2016-03-20 Thread Carl Marcum

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.

 ,
along with

 .

 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



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

Re: Can we add the value "N/A" to the Target Milestone field

2016-03-20 Thread Andrea Pescetti

Kay Schenk wrote:

We seem to have a number of issues in BZ that are now listed
as Resolved/Fixed but don't seem to pertain to an actual
upcoming release.


Everything that was marked RESOLVED FIXED will be in 4.2.0. So 4.2.0 is 
a perfectly valid value for these cases.


Just to be clear: 4.1.2 was a maintenance release and issues had to be 
approved as release blockers in that case. 4.2.0 will be a normal 
release, made from trunk, so everything that is on trunk (untile a 
certain moment when we will decide to branch) will be into it 
automatically. So the target is 4.2.0 in those cases.


Regards,
  Andrea.

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



Can we add the value "N/A" to the Target Milestone field

2016-03-20 Thread Kay Schenk
To our BZ admins.

We seem to have a number of issues in BZ that are now listed
as Resolved/Fixed but don't seem to pertain to an actual
upcoming release.

Examples:
https://bz.apache.org/ooo/show_bug.cgi?id=126652
https://bz.apache.org/ooo/show_bug.cgi?id=126828

Can we add something like "N/A" or the like to our Target
Milestone field rather than the default "--" so we know
these should never be considered for a release?

Thanks.
-- 

MzK

"Time spent with cats is never wasted."
   -- Sigmund Freud

-
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

2016-03-20 Thread 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.
>>
>> ,
>> along with
>>
>> .
>>
>> 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
>>
>> 
>> 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 

Re: [OT] ApacheCon

2016-03-20 Thread Carl Marcum

On 03/16/2016 08:23 PM, Patricia Shanahan wrote:
Are any of you planning to attend the North America ApacheCon? I have 
not yet decided whether to go.


Patricia

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



I would have liked to attend but my TAC application wasn't successful.


-
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

2016-03-20 Thread Carl Marcum



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.

, along with

.

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
 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 at Netbeans.org.


4. The artifact is built with the NetBeans IDE which 

RE: Releasing the Apache OpenOffice API plugin for NetBeans

2016-03-20 Thread Dennis E. Hamilton
[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.

   , along with 

   .

   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 
    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: [OT] ApacheCon

2016-03-20 Thread Dennis E. Hamilton


> -Original Message-
> From: Andrea Pescetti [mailto:pesce...@apache.org]
> Sent: Sunday, March 20, 2016 06:41
> To: dev@openoffice.apache.org
> Subject: Re: [OT] ApacheCon
> 
> On 17/03/2016 Dennis E. Hamilton wrote:
> > I thought about it, since the travel part is easy.
> > I decided to avoid the expense of the conference and accomodations and
> stay home though.
> 
> ApacheCon would be a quite appropriate usage of our travel funds. If the
> reason for you not to attend ApacheCon is the expense (and if you can
> travel easily to it) I suggest that we look into using the travel funds.
> The fact that we never used them so far is more a mistake than a
> virtuous example.
> 
> It is useful to meet with the Board and with Infra, for example. I can
> surely say that if I hadn't attended ApacheCon in early October 2015 we
> wouldn't have had OpenOffice 4.1.2 released later that month, since we
> needed to do some work sitting together with Infra.
> 
> If access to conference is the problem, I still believe that the
> entrance fee is high for a volunteer, but there are significant
> discounts for committers and also options for attending only part of the
> conference. We can surely cover a presence at ApacheCon (if not a full
> attendance).
[orcmid] 

If there will be an exhibition area or other place where there might be an ASF 
booth or tables, I might be able to enter the conference as an Exhibitor, in 
the same manner as at OSCON for the past two years.

That usually provides access to attending individuals, board members, and 
meetings that are separate from the sessions but at the venue.

I don't know how that works in the case of ApacheCon.

 - Dennis
> 
> 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: [OT] ApacheCon

2016-03-20 Thread Andrea Pescetti

On 17/03/2016 Dennis E. Hamilton wrote:

I thought about it, since the travel part is easy.
I decided to avoid the expense of the conference and accomodations and stay 
home though.


ApacheCon would be a quite appropriate usage of our travel funds. If the 
reason for you not to attend ApacheCon is the expense (and if you can 
travel easily to it) I suggest that we look into using the travel funds. 
The fact that we never used them so far is more a mistake than a 
virtuous example.


It is useful to meet with the Board and with Infra, for example. I can 
surely say that if I hadn't attended ApacheCon in early October 2015 we 
wouldn't have had OpenOffice 4.1.2 released later that month, since we 
needed to do some work sitting together with Infra.


If access to conference is the problem, I still believe that the 
entrance fee is high for a volunteer, but there are significant 
discounts for committers and also options for attending only part of the 
conference. We can surely cover a presence at ApacheCon (if not a full 
attendance).


Regards,
  Andrea.

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



Re: AOO Governance (was RE: Next release and gbuild)

2016-03-20 Thread donaldupre .
Not only it is possible to compel, it is imperative for a viable project.
As Stalin once said, "When there's a person, there's a problem." :)
Lack of management hierarchy just can't work in the long run.
The history of OpenOffice also shows its peak was when an organization with
a clear command structure developed it.
Lazy consensus is in fact the manner to operate because fluid is lazy...
Accomplishments depend not only on the capacity, capability, and
willingness of contributors, but mainly on the way they are being guided
and steered.

On Thu, Mar 17, 2016 at 6:02 PM, Dennis E. Hamilton  wrote:

> Technically, we do not have a management hierarchy on Apache projects,
> although there are some rather limited governance roles.  There can be
> self-organizing *informal* teams that are basically people working together
> for some common within-project purpose and those are fluid and definitely
> self-generated.  There is no holacracy.  It is important for onlookers to
> understand there is no executive and there is no *command* structure.  It
> is not possible to compel anything.
>
> There is a form of status with regard to privileges, in that committers
> are trusted to review and approve the submissions of other contributors and
> can do more without oversight (while review is always possible).  There is
> also a limited form of governance invested in members of the Project
> Management Committee (PMC) which have binding votes on release candidates
> and on procedural and personnel matters such as inviting contributors to
> become committers and to become members of the PMC.  This is all striving
> toward sustainability of the project.
>
> Effort happens here *only* if someone steps in and operates in a
> consensus-seeking manner.  What is accomplished depends on the capacity,
> capability, and willingness of such contributors.  The sustainability of
> the project depends in part on how contributed effort leads to the
> cultivation and preparation of additional contributors so that capacity is
> continually renewed.
>
> Finally, there is a form of oversight, in that the project is accountable
> to the foundation for operating in accordance with the foundation bylaws
> and other principles and practices employed across Apache projects.  The
> Chair of the PMC is ratified by the Board of the Foundation and is an
> Officer of the Foundation (i.e., Apache Software Foundation Vice President
> for Apache OpenOffice).  The Chair is accountable to the Board while in all
> other respects being just another member of the PMC.
>
> For Apache OpenOffice, there is more about this form of operation at <
> https://s.apache.org/mSVG>.
>
> For an indication of the status of the project over time, the AOO
> quarterly reports to the Board included in approved Board minutes are
> extracted and collected for historical convenience at <
> https://svn.apache.org/repos/asf/openoffice/pmc/BoardReportsArchive>.
> The latest accepted quarterly report is maintained at <
> https://s.apache.org/iH9U>.
>
> The next report (for the January-March quarter) will be submitted to the
> April 20, 2016, meeting of the ASF Board.  It will be added to the history
> after subsequent approval of the minutes of that meeting. (The complete ASF
> Board Minutes that are the authoritative source of the extracts can be
> found via .)
>
>  - Dennis
>
> > -Original Message-
> > From: donaldupre . [mailto:donaldu...@gmail.com]
> > Sent: Thursday, March 17, 2016 00:11
> > To: dev@openoffice.apache.org
> > Subject: Re: Next release and gbuild
> >
> > On Tue, Mar 15, 2016 at 8:46 PM, Pedro Giffuni  wrote:
> >
> > > Either someone steps in or we just have a team of people do things.
> > >
> >
> > Holacracy is not a good idea.
>
>
> -
> 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

2016-03-20 Thread Marcus

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: Next release and gbuild

2016-03-20 Thread Pedro Giffuni



On 03/15/16 13:46, Pedro Giffuni wrote:

Hello;

I have been noticing damjan's great advance in merging the gbuild stuff.



It would be rather interesting to compare the buildworld timing.

Is it faster to build with gbuild? Perhaps the buildbot may give us a 
hint but we may not know exactly as I think gbuild adds some more tests 
(not sure).


The FreeBSD buildbot continues stuck when fetching tarballs, BTW :(.

Pedro.

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



Re: AOO Governance (was RE: Next release and gbuild)

2016-03-20 Thread donaldupre .
On Fri, Mar 18, 2016 at 4:18 PM, Patricia Shanahan  wrote:

> When I was working I gave up some of my freedom to do what I wanted in
> exchange for being paid to do what other people told me.
>
> We all do...


> I retired when I had accumulated enough investments that the financial
> improvement from the money Sun was paying me no longer outweighed the
> benefit of being able to decide for myself what to do with my time. My
> 10 a.m. horseback riding lesson this morning will be far higher priority
> than OpenOffice debug.
>
> I do not see being a "Release Manager" as carrying any authority at all
> over others. I might need to persuade, suggest, beg, and plead, but I
> would not expect to be able to compel, not even to the limited extent I
> could when I was a project leader in industry.
>
> This is not the place for a philosophical debate, let's agree to disagree
:)
I hope a good release manager / keeper of the release checklist will be
found soon.


> If the term "Release Manager" is creating an idea of a job something
> like being a manager in industry, maybe we need a more realistic term
> such as "Keeper of the Release Checklist".
>
> Patricia


Re: Releasing the Apache OpenOffice API plugin for NetBeans

2016-03-20 Thread 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.


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

2016-03-20 Thread Rory O'Farrell
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

2016-03-20 Thread Marcus

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