incubator-heraldry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kevin Turner <>
Subject mailing list participation (was: Re: Getting Updated JanRain Code In)
Date Wed, 31 Jan 2007 04:48:24 GMT
On Tue, 2007-01-30 at 18:17 -0800, Ted Leung wrote:
> What I am still not convinced about is whether or not we are actually  
> going to see any development discussions on this list.   David, I've  
> heard you interpreting Kevin/JanRain's actions, but I haven't heard  
> anyone from Janrain - and there are 7 Heraldry committers from  
> JanRain, not just Kevin - explicitly say that they are also moving  
> the development discussions to the heraldry lists.

The one concrete thing I can offer is a commitment to using the Heraldry
bug tracker, which I think _will_ help as that's where a notable portion
of communication at this stage of development is happening.  I've got
twenty or thirty open tickets for libraries/python/openid/trunk in my
old tracker, and it's probably worthwhile for me to move a fair share of
those over to JIRA (by hand, if necessary) just to seed the system.

The reason I haven't been more optimistic about mailing list involvement
isn't because I think it's unimportant -- it's because I know it can be
*hard*.  I'm thinking here mostly of one of my earlier experiences with
open source development, back in the day when I was actively involved
with the GIMP, and unlike us they already had a decentralized team and
pretty much all of the communication happening in written form.  But it
was written on IRC, not the mailing list, and it was pretty much
impossible for anyone who wasn't following IRC all the time to know why
development decisions were made.

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?

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.)


 - Kevin

1. UQDS,

View raw message