www-legal-discuss mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jim Jagielski <...@jaguNET.com>
Subject Re: Continuous release review
Date Thu, 29 May 2014 16:10:21 GMT
Here is the underlying issue.

Recall that for Apache, what is of main concern is a healthy
and viable community around a project, which implies a
healthy and viable PMC.

Now early on, what got us first started was when the old
NCSA web server was dropped, cold, when Rob went to work
on Netscape. There was no community (of developers) around
it. So a bootstrapped community came together, with the
promise that no other users (community) would be hit
how we were.

The way to ensure that was to build up a community of personally
invested and engagement people around a project. The development
and the release of a codebase was a *communal* action, and we
wanted to ensure that, since we were all doing this in our
"spare" time, as volunteers, that a project could survive the
inevitable ebb-and-flow of developer free time. So as long
as there were 3 people, engaged in a projects, that seemed
enough. It was the "magic" number to get patches committed
and the number required to "bless" a release.

Taken in this light, it should be obvious that a release is
the primary communal action of the PMC. It is the last stage
before a codebase is released to the public for us; a release
is when the License "kicks in" and it's when the developers,
the ASF and the RM takes on legal liability.

So the merits of requiring at least 3 PMC members to approve
a release are:

  1. Ensures that we still have 3 *active* and *engaged* people,
     since it takes some level of effort to do so.
  2. Makes the release a *personal* action by the PMC.
  3. Serves as a final, hands-on "QA" check before something
     is released.
  4. Emphasizes that a project and codebase is a personal
     and communal artifact, which helps ensure that a
     community grows and develops around the project.

All within the ASF there is a dual concentration on the
community and the individual thereof. Merit, for example, is
individual and based on a lot of metrics, not just lines-of-
code-written, for example. Our concern over healthy, viable,
self-sustaining communities affect all aspects of our processes.
And our successes "prove" the validity of those processes.

I guess a simpler way of explaining it would be to compare
the differences between mass-produced beer and hand-crafted

On May 29, 2014, at 11:48 AM, Alex Harui <aharui@adobe.com> wrote:

> (Trying to reel this thread back into productivity)
> Apache is supposed to be a meritocracy where issues are discussed on the
> merits.  Short answers of just "No" without justification doesn't help,
> nor does telling someone they are pounding their head in the sand.
> Also, can we table the discussion of how we might change these
> requirements, or at least, fork it to a new thread?   I imagine changing
> these requirements will take a long time, and I am more interested in
> understanding what we can do under the current rules.
> So Jim, please explain to me, a new member, what are the "merits" of
> requiring that PMC members download, build, and test?  Is it just
> statistical probability that some platform or machine-specific issue might
> get found before release?
> What does it mean to "test"?  Can it be a simple smoke test, or testing of
> some simple application against the built sources?
> Can these steps be done automatically and just generate a report for
> review or is there some value to having to manually execute these steps?
> Thanks,
> -Alex
> On 5/29/14 8:31 AM, "Emmanuel Lécharny" <elecharny@gmail.com> wrote:
>> Le 29/05/2014 16:04, Jim Jagielski a écrit :
>>> FWIW, my response could be:
>>>  You can pound your head in the sand, expecting that every release
>>>  does not need to be downladed, compiled, tested by every PMC member
>>>  casting a +1, or simply accept the idea that, yes, an automated and
>>>  potentially buggy CI process is no substitute for a healthy, engaged
>>>  and responsible PMC.
>>> See how I did that?
>> Sure.
>> But I can check a CI script, when I can't be on every PMC's back to
>> double check that they are doing their homeworks.
>> Anticpiating your answer, yes, I know, *if* I do the chekcs myself, I
>> will be able to know that X Y or Z is not fulfilling his/her duty. And
>> now what ? Should I tell them to either comply, or stop casting a vote ?
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
>> For additional commands, e-mail: legal-discuss-help@apache.org
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
> For additional commands, e-mail: legal-discuss-help@apache.org

To unsubscribe, e-mail: legal-discuss-unsubscribe@apache.org
For additional commands, e-mail: legal-discuss-help@apache.org

View raw message