incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Husted" <>
Subject Re: [PROPOSAL] Thrift
Date Tue, 05 Feb 2008 16:25:24 GMT
Yes, there is a subtle disjoint or two. :)

Excluding patches that simply modify an existing artifact, we do need
licensing agreements from all individual contributors, regardless of
whether they become ASF committers or members of the podling PMC.
Otherwise, the ASF does not have clear title to the code, and anyone
who uses the code would be endangered.

It is not unusual for us to collect a licensing agreement from a
non-committer before accepting a non-trivial contribution, especially
if it is a new artifact. One reason that ASF projects are successful
is because people trust us to do the right thing when it comes to IP,
even if the right thing is the hard thing.

In order to establish an Apache account for someone, we also need
licensing agreements from the account owner (regardless of whether
they have made a past contribution). Everyone on the initial list of
podling committers will need an Apache account, and therefore must
file a CLA.

One fine point is that the initial list of  podling committers, in
practice, ultimately becomes the list of initial PMC members. Once the
project is up and running, individuals who are only interested in
maintaining one piece of code could be a committer, without
necessarily becoming a PMC member, if that individual was not
interesting in helping with project oversight.

Project karma is usually a "staged release", where someone is first a
contributor, and then a committer, and finally a PMC member. In
practice, moving through all the stages can take someone a year or
longer. Podlings are a special case, since everyone becomes a PMC
member all at once. (Which is why we need multiple mentors.)

Culturally, we tend to offer PMC membership to any committer who
demonstrates a persistent, welcome interest in the project, and we
share code ownership with all committers and  PMC members. Since all
project actions are utterly transparent, sharing code ownership is not
usually a problem, so long as other committers and PMC members
peer-review the commits list. (Trust but verify.)

The key cultural bias is toward collaboration, and her handmaidens,
equality and transparency.

Infrastructure can be a sticky wicket, since there is a bias toward
sharing all resources with all projects, in the same way we share code
with all committers. Before any technology is deployed as a ASF
resource, people want to be sure there is sufficient resources so that
it could be shared with all 50+ projects.

In the past, projects have introduced technologies by "voting with
their feet". For example, people started using JIRA offsite, and
ultimately, we obtained our own JIRA instance. The same thing happened
with Confluence.

Not too long ago, the rule would have been "Any SCM so long as its
CVS". Initially, we ran dual systems, but once most projects
voluntarily migrated, we pulled the CVS plug -- but only after most
projects had already voted with their feet.

It is a hard-and-fast rule that the source code, web site, and mailing
lists have to be kept here, since they are key material assets of the
foundation, and must be under the foundation's direct control. But,
third parties often contribute other technologies to the community
that live elsewhere, like mailing list archives, source code viewers,
continuous build systems, and so forth. svn-git, hosted elsewhere at
first, could be another one of those.

Some projects even have special "zones" here where people can
experiment with new services. (Though I believe that space is becoming

There is someplace to go with git. It's not something that would be
made available on a production ASF server right away. But, it is
something Thrift could pursue once past incubation.

Thrift looks like an interesting product, and I'm looking forward to
trying it with my next project.

HTH, Ted.

On Feb 4, 2008 6:48 PM, Mark Slee <> wrote:
> Well, note that this isn't strictly an IP issue. The issue here was the
> committers list, not the IP of the code. I don't see why all the code
> would need to be written by people on the initial committers list to
> pass IP restrictions.
> These two seem like disjoint issues to me. All code in the codebase
> today has been committed by an approved committer with the consent of
> the people providing the patches, so things should be consistent on the
> IP front.
> Cheers,
> Mark

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message