incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "William A. Rowe, Jr." <>
Subject Re: [Vote] Incubating Project Policy
Date Fri, 02 Feb 2007 02:16:44 GMT
James Margaris wrote:
> -1 from me. (If I even have a vote...)

Although only ASF members/Incubator PMC votes are 'counted', yes everyone here
has a voice - we do appreciate everyone's input.  So should every podling.

> If I want to check in some third party code with a proper license, I don't 
> really see the difference between checking it in directly vs. posting it to 
> Jira and then checking it in. Is there some sort of implied waiting period 
> during which people review the Jira patches?

Well, if you post someone elses code to Jira just to circumvent the proposed
policy, you are violating the policy.  Maybe I need to more precisely define
the third party code in question; it's code which the poster to Jira or the
mailing list authored, their self.

> I also don't see why this is a case to protect against. If the policy of the 
> project is to allow third party open source code with a compatible license 
> and the policy is also commit-then-review, what is the issue? It seems this 
> erases the distinction between commit-then-review and review-then-commit.

Well, there are many homes for open source code.  There are few homes which
operate in an ASF-style meritocracy.

This policy essentially says yes, all Incubator code would be commit-by-author
and then review, and commits of external code where the authors don't actually
participate in the project would be review-then-commit.

I don't think this is erasing the distinction though.  The point to ASF projects
is to have the authors participate in the project.  Participating by proxy is
generally unhealthy to building an ASF community.

> It appears to me that the system is basically working. The Heraldry project  
> has some issues, people spotted them, now appropriate action is being taken.
> According to the documentation mentors are supposed to keep their eyes open 
> for these sorts of problems.

Yes, action is being taken.  This proposal is one of my first proposed solutions
to that specific case, but as I was writing the email with respect to Heraldry,
I realized it was a more general case and a more generalized issue.

> I don't see how this addresses the Heraldry problems. If they want to do a
> massive commit of externally developed changes they would now post them as a 
> patch first (or mailing list message) and then commit them instead of just 
> committing them - the end result is the same no? 

No, because the other project folk can put the breaks on overly large patches,
and ask the individual contributors to stop and make the submission something
that's digestible.  They can stop and discuss the wisdom of scope changes or
creeping featurism.  They can decide if the code will be maintained, or if
it's nothing but a code dump.

> To me that is just transferring the problem, now instead of a massive commit 
> of external stuff you get a massive email message with that same externally 
> developed stuff in it. The problem is that a bunch of external development 
> is going on while the mailing list is silent, and this doesn't address that.

Yes - that's another issue.  Permitting commits-by-proxy has partially led to
this situation.  Solve the roots of the issue, then address the immediate
issues at hand.

> I don't think there is any great way to prevent this sort of thing other than 
> make it clear that it won't be tolerated and encouraging vigilance from the 
> project mentors.

If you want to develop the wazzit feature for the wizbang podling, all on your
own, over the next two months and come back with a huge new patch, I wouldn't
debate that.  If Joe comes to the list with the wazzit feature you wrote,
and you are off on some other page, I'd be very doubtful that the wizbang
podling is willing to own your wazzit code.

> What I find a bit disturbing about this Heraldry business and the Kabuki fiasco 
> before it is the lack of any communication out of the project. I would expect 
> explanations from multiple committers, promises to do better, pleas for 
> clarification or something of the sort. Maybe I've missed it but the Heraldry 
> community seems pretty silent.

And you (and any incubator participant) are welcome to engage them on their
mailing list.

I'm looking at the roots of these issues to find some unwritten practices at
httpd server, tomcat and other ASF projects which have helped to sustain and
foster their efforts.

The problem is that the members know what works, and why, and often we have
trouble distilling them into bite-sized nuggets of wisdom.

"Our code is developed within the sphere of our ASF community".  How to turn
that into policies which encourage development on list and discourage the
evolution of code in the shadows where there is no history?  I think that
contributor-by-proxy is a pretty good example of what we want to discourage.


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

View raw message