incubator-heraldry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Leung <twle...@sauria.com>
Subject Re: mailing list participation (was: Re: Getting Updated JanRain Code In)
Date Thu, 01 Feb 2007 08:05:18 GMT
On Jan 31, 2007, at 6:18 PM, Dick Hardt wrote:

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

This is a reasonable question.   If I take a quick look at the left  
side of www.apache.org, I see the following projects which are  
essentially libraries: db, iBatis, Jakarta is full of libraries,  
logging, lucene, santuario, velocity, xalan, and xerces.   So being a  
library is not in any way a blocker.

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

I would hope so, since many of the engineers working on  
code.google.com are Apache members

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

The thing that you don't get from something like Sourceforge or  
Google is the Apache governance system.   What you won't  get is  
what's happening right now, which is that some overseeing body (the  
Apache Board and the Incubator PMC) will intervene if the project is  
not being run in accordance with some set of core principles.   If  
all the Heraldry committers want is public infrastructure, then I'd  
say that Apache is not the right place.   However, I think that the  
identity space is a highly political and potentially lucrative space,  
and that having the Apache governance watching over the development  
of a set of OpenID libraries is a very real and tangible benefit for  
OpenID.    Apache has proven itself as a place where individuals from  
multiple organizations can collaborate on an even playing field.

As far is it reflecting badly on Apache or OpenID if Heraldry is  
terminated, I'd say this.   If Heraldry is shut down, it will be  
neither the first nor the last incubated project to be shut down.    
It would reflect far more poorly on Apache if we were to depart from  
the principles which govern every other project at the foundation.    
At the same time, there are plenty of other open source projects out  
there besides Apache, run with very different governance than  
Apache.  I don't think that there'd be any shame in Heraldry coming  
to the realization that the Apache governance model isn't for them.

Ted

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