incubator-heraldry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Leung <>
Subject Re: mailing list participation (was: Re: Getting Updated JanRain Code In)
Date Wed, 31 Jan 2007 08:38:36 GMT
Hash: SHA1

On Jan 30, 2007, at 8:48 PM, Kevin Turner wrote:

> So I agree, this is a very valid concern.  If it's hard for developers
> to remember to post discussions from IRC to a mailing list, how  
> hard is
> it going to be to get the discussions that happen over the cubicle  
> wall
> to be posted there?  Ted, you told me you faced a lot of these same
> issues when joining the Xerces-J project.  Were there any specific
> practices you adopted to make sure things made it to the list?

One thing that I can suggest is that for cases where you would write  
an engineering level spec is that you post that to the list, or that  
you post proposals for feature implementations to the list.   The  
Apache voting system allows you to proceed with a proposal if no one  
objects within reasonable timeframe (72 hours at most).   At first,  
there won't likely be much participation, but by putting out these  
kinds of details, you'll help people to get familiar with how things  
work and see where there are opportunities to help.

I'd definitely suggest that every Heraldry committer read Karl  
Fogel's "Producing Open Source Software" (available online at <http://>) which is a hugely practical guide full of great  
wisdom about how open source communities ought to operate.  Karl is a  
member of the Subversion project, which is governed in a fairly  
Apache style fashion.   I wish that we had this book when we did the  
XML4J -> Xerces transition.

> By far the best practice I've seen for making sure both that code
> modifications are reviewed and the decisions are well-documented is
> UQDS[1], which is a review-then-commit system that makes heavy use of
> branches and issue tracking.  We've sort of defaulted to a lazy
> commit-then-review process here at Heraldry, but I wouldn't mind  
> taking
> another look at that.
> (I just ask that we let patches that were authored by committers
> _before_ any such policy change be grandfathered in.  We'll have  
> enough
> fun adapting to any review-then-commit system as it is, without trying
> to impose it on patches that were written to a different set of
> expectations, and it's not like we're going to do serious damage to  
> the
> codebase if we let a few more commits through while we figure it out.)

As I said to Jonathan, I think that there is a way forward here, but  
let's see what the rest of the community thinks.  Also, a review then  
commit (RTC) model is not essential.  Many projects at Apache switch  
back and forth from a commit then review (CTR) model during general  
development and then go to RTC when they are about to do a  
release.    We could definitely use Jira as a support mechanism for  
RTC if that is how people would like to work.   There is some freedom  
here while remaining in the spirit of the Apache Way.

Version: GnuPG v1.4.5 (Darwin)


View raw message