On 8/24/2012 11:19 AM, Joe Schaefer wrote:
Really, all this fuss over the LABELLING of
a file being distributed does not add value
to either the org, the podling, or the users
of the software. Nowhere is it written that
you CANNOT DISTRIBUTE BINARIES, however it
has always been clear that they are provided
for the convenience of our users, not as part
of an "official" release. That however does
not mean that things like release announcements
cannot refer users to those binaries, it simply
means those announcements need to reference the
sources as "the thing that was formally voted on
and approved by the ASF".
Thus...
Binaries created /from /the Official Release?
________________________________
From: Dave Fisher <dave2w...@comcast.net>
To: general@incubator.apache.org
Sent: Friday, August 24, 2012 1:56 PM
Subject: Re: [VOTE] Apache OpenOffice Community Graduation Vote
On Aug 24, 2012, at 10:09 AM, Rob Weir wrote:
On Fri, Aug 24, 2012 at 12:45 PM, Rob Weir <robw...@apache.org> wrote:
On Fri, Aug 24, 2012 at 12:32 PM, Marvin Humphrey
<mar...@rectangular.com> wrote:
Returning to this topic after an intermission...
On Tue, Aug 21, 2012 at 6:18 AM, Bertrand Delacretaz
<bdelacre...@apache.org> wrote:
On Tue, Aug 21, 2012 at 11:54 AM, Jürgen Schmidt <jogischm...@gmail.com> wrote:
...As one of the active developers I would have a serious problem if we as
project couldn't provide binary releases for our users. And I thought
the ASF is a serious enough institution that can ensure to deliver
binaries of these very popular end user oriented software and can of
course protect the very valuable brand OpenOffice that the ASF now owns
as well...
As has been repeatedly mentioned in this thread and elsewhere, at the
moment ASF releases consist of source code, not binaries.
My impression from this discussion is that many podling contributors are
dismayed by this policy, and that there is an element within the PPMC which
remains convinced that it is actually up to individual PMCs within the ASF to
set policy as to whether binaries are official or not.
If there actually is an ASF-wide Policy concerning binaries then I
would expect that:
1) It would come from the ASF Board, or from a Legal Affairs, not as
individual opinions on the IPMC list
2) It would be documented someplace, as other important ASF policies
are documented
And 2a) Actually state the constraints of the policy, i.e., what is
allowed or disallowed by the policy. Merely inventing a label like
"convenience" or "unofficial" gives absolutely zero direction to
PMC's. It is just a label. Consider what the IPMC's Release Guide
gives with regards to the source artifact. It is labeled "canonical",
but that level is backed up with requirements, e.g., that every
release must include it, that it must be signed, etc. Similarly,
podling releases are not merely labeled "podling releases", but policy
defines requirements, e.g., a disclaimer, a required IPMC vote, etc.
I hope I am not being too pedantic here. But I would like to have a
policy defined here so any PMC can determine whether they are in
compliance. But so far I just hear strongly held opinions that amount
to applying labels, but not mandating or forbidden any actions with
regards to artifacts that bear these labels.
Consider: If some IPMC members declared loudly that "It is ASF policy
that binary artifacts are 'Umbabuga'", what exactly would you expect a
Podling to do, given that Umbabuga is an undefined term with no policy
mandated or forbidden actions?
There is a seductive appeal to reaching consensus on a label. But it
avoids the hard part of policy development, the useful part: reaching
consensus on constraints to actions.
The AOO PPMC was asked to take this discussion along with digital signature
issue to legal-discuss to get advice. Whether or not this becomes guidance for
AOO or official foundation wide policy is ultimately up to the Board and the
Membership.
Regards,
Dave
3) That the policies is applied not only to AOO, but to other podlings
and to TLP's as well.
Until that happens, I hear only opinions. But opinions, even widely
held opinions, even Roy opinions, are not the same as policy.
-Rob
OTOH I don't think anybody said the ASF will never allow projects to
distribute binaries - but people who want to do that need to get
together (*) and come up with a proposal that's compatible with the
ASF's goals and constraints, so that a clear policy can be set.
I'm concerned that such an effort may not be completed, and that once the
podling graduates, AOO binaries will once again be advertised as official,
placing the project in conflict with ASF-wide policy. It may be that some
within the newly formed PMC will speak out in favor of the ASF status quo, but
as their position will likely be inexpedient and unpopular, it may be
difficult to prevail.
Of course I don't know how things will play out, but it seems to me that
reactions from podling contributors have ranged from discouraged to skeptical
to antagonistic and that there is limited enthusisasm for working within the ASF
on this matter.
Gaming out this pessimistic scenario, what would it look like if the Board
were forced to clamp down on a rebellious AOO PMC to enforce ASF policy
regarding binary releases?
If we believe that we are adequately prepared for such circumstances, then I
think that's good enough and that fully resolving the issue of binary
releases prior to AOO's graduation is not required.
Marvin Humphrey
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org
