incubator-heraldry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dick Hardt <d...@sxip.com>
Subject Re: mailing list participation (was: Re: Getting Updated JanRain Code In)
Date Thu, 01 Feb 2007 02:18:36 GMT
I'm wondering if Apache is the right place for this work. These are  
libraries, and from my experience with the Perl, Python and Tcl  
worlds, libraries tend to be worked on by a very small number of  
people with little overlap.

We put the OpenID4Java and OpenID4Perl over at code.google.com for  
the following reasons:

1) I trust their ability to keep the system up and running and be  
responsive (not trying to state that apache can't do that, but that  
Google does)
2) Simple interface for posting to the list, managing bugs etc.
3) Google continues to add cool new features to code.google.com
4) We think of these as little projects that will likely have a small  
number of developers with little overlap between projects and not  
appropriate for Apache.

I don't want to dissuade the development of a robust Apache project,  
but it does not look good on Apache or OpenID if the project were to  
be shut down. Now might be a good time to move to a hosted project  
location such as Google or SourceForge if it looks like this project  
does not fit the Apache Way.

-- Dick

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

> 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.)
>
> Thanks,
>
>  - Kevin
>
> 1. UQDS,
> http://www.divmod.org/trac/wiki/UltimateQualityDevelopmentSystem


Mime
View raw message