incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <rgard...@opendirective.com>
Subject Re: Umbrella projects
Date Mon, 12 Sep 2011 13:18:31 GMT
On 12 September 2011 14:11, Joe Schaefer <joe_schaefer@yahoo.com> wrote:
>
>>________________________________
>>From: Ross Gardler <rgardler@opendirective.com>
>>To: ooo-dev@incubator.apache.org; Joe Schaefer <joe_schaefer@yahoo.com>
>>Sent: Monday, September 12, 2011 9:05 AM
>>Subject: Re: Umbrella projects
>>
>>On 12 September 2011 13:41, Joe Schaefer <joe_schaefer@yahoo.com> wrote:
>>> Well binaries do not require votes, they
>>> are considered a "courtesy service" of the
>>> project.
>>
>>For clarity:
>>
>>An *official* release requires a vote. A binary snapshot release (for
>>example) does not.
>>
>>Usually an official release (which is a source release) is accompanied
>>by a binary release that is a courtesy as Joe says.
>>
>>I think what Joe means here (apologies if I am misrepresenting you
>>Joe) is that if, for example, Apache OO.o 3.4 were released today then
>>a native language *binary* release based on that code could be made
>>tomorrow without a vote.
>
>
> Correct, see http://www.apache.org/dev/release.htmll#what-must-every-release-contain
>
> All "released" binaries must be buildable from voted-upon source packages.

Thanks, so the assumption in this case is that a localization only
includes config file changes. This is quite possibly not the case for
a project like OOo where UI changes are also likely. This is an
assumption I made when using a native language dev list as an example.
Sorry for the confusion.

...

>>[Finally, for the record, I disagree that project decisions (requiring
>>a vote) can be taken anywhere but here.]
>
>
> Traditionally it depends on the scope of the decision.  Subprojects at
> the ASF are free to hold binding votes on their sublists, presuming
> the decision only affects that subproject.

OK, so now we are talking about "delegating decision" and thus my
original observation of "I'm merely letting the community know that
this could become an issue if we don't keep a
careful eye on it. For me the trigger point will be delegation of
decision making responsibilities."

As has been surfaced in other mails in this thread the issue is what
decisions can be responsibly delegated without it having a negative
affect on the project. We can't decide these upfront because we can't
predict them. Instead we need to ensure the people running those
sub-projects are clear on what is generally OK and what is not.

Ross

Mime
View raw message