[OpenID board] OpenID on Google Code

David Recordon david at sixapart.com
Thu Apr 9 00:26:21 UTC 2009


I support whatever the current various maintainers of OpenID libraries  
think will make their jobs easier, the code easier to find, more up to  
date and higher quality.  I know a bunch of developers on the PHP and  
Python libraries were interested in having a shared code repository  
much like the OAuth community has done really successfully.  I don't  
really have strong opinions if this is on Google Code or GitHub.

--David

On Apr 5, 2009, at 12:19 PM, Chris Messina wrote:

> On Mon, Mar 30, 2009 at 6:27 PM, Martin Atkins <mart at degeneration.co.uk 
> > wrote:
> Chris Messina wrote:
>
> There are probably more things about this, but the major difference  
> is making openid.googlecode.com <http://openid.googlecode.com> the  
> place to check out the latest versions of all the libraries. Issue  
> management for each library might be a separate issue to consider,  
> but we do need a place to manage issues for the website.
>
>
> Having what are essentially forks in Subversion makes me nervous,  
> just because Subversion is notoriously bad at dealing with forks and  
> merging.
>
> Use the right tool for the job; I agree.
>
>
> Having actual distribution archives all in one place makes a great  
> deal of sense, of course. I have no objection to that. Whether  
> Google Code is actually necessary at that point is of course  
> debatable, but if nothing else it does provide a facility for  
> hosting release bundles.
>
> Yes, I think that's mostly what I want -- that is, a canonical place  
> to point people to get the latest libraries that will actually be  
> maintained.
>
> Historically I've found that central code repositories are  
> maintained better than CMS-managed web pages or wiki pages that are  
> perceived as untrustworthy... I could be wrong here, but I'm looking  
> to solve the problem that arises when someone asks "Where do I get  
> the latest OpenID libraries?" From a marketing/recall perspective,  
> the answer should not be "openidenabled.com" — but openid.net/code  
> or openid.googlecode.com (perhaps via a redirect from the .net URL).
>
>
> However, it would concern me if -- for example -- the repository for  
> the perl libraries that I maintain were mirrored, just because it  
> would become confusing as to which respository was the correct one  
> to commit to, which one folks should be pulling the latest trunk  
> from, etc. (Separate git repositories are less of an issue because  
> git actually has the tooling necessary to pull and merge without  
> excessive pain.)
>
> Agreed. Perhaps the Google Code OpenID repo should therefore be read- 
> only.
>
>
> I'm also adverse to the idea of centralizing the bug tracking  
> because the Perl libraries already have a bug tracking solution in  
> the form of the CPAN bug tracker, which is where Perl developers  
> ought to expect to find and file bugs on CPAN libraries.
>
> Agreed. Writing up documentation on how and where to report bugs/ 
> issues for the various libraries would seem like a good idea. Having  
> visibility in what are known or outstanding issues is also critical/ 
> essential.
>
>
> As far as the number of concurrent projects to manage goes, I would  
> expect this to be solved by having the maintainer of each library  
> maintain his own project. There's no reason why the OpenID  
> Foundation needs to have any involvement in the day-to-day running  
> of these projects, because the OpenID Foundation doesn't (directly)  
> do library development.
>
> Agreed. However, the Foundation has a responsibility to make using  
> OpenID easier — for developers and users alike. I don't want the  
> Foundation to have a role in maintaining the libraries, but I do  
> think that it needs to be aware of what's going on with the  
> libraries — and how easy it is for people to get into the code and  
> to report issues and have them get fixed.
>
> From that perspective, the Foundation is something of a "services  
> front-end" to the code-maintainers — so that developers can do what  
> they need to do and the Foundation can play pass interference or  
> help route interest or getting the code.
>
>
> From a more philosophical point of view I'm leery of the OpenID  
> Foundation "owning" or "managing" any aspect of the libraries. As I  
> mentioned before, it'd be annoying if library developers had to go  
> through the OIDF board to get things done, since library development  
> has traditionally been autonomous and I'd hate to get into a  
> situation where OIDF is "blessing" certain libraries and hosting  
> them while shunning others. (For example, there are currently at  
> least two Perl OpenID implementations; is OIDF going to host both of  
> them?)
>
> Well, this is all good and well as long as there is a vibrant  
> community around the libraries — something that I currently do not  
> see.
>
> I don't want the Foundation to get in the middle of code decisions,  
> but I do think that we have to do whatever is in our purview to help  
> stoke community participation and involvement. If that means making  
> sure that the work of the maintainers is readily available for other  
> folks to use, then so be it.
>
> I also think that the Foundation has some responsibility to make  
> sure that the code is being developed transparently, with a public  
> issue tracking and commit log. While these things should be managed  
> by developers, there is a need for oversight in these matters that  
> start with the technical but end in the political, and that's where  
> the Foundation's role comes in.
>
> I think that we are in general agreement, but I appreciate your  
> perspective on this. My intention is not to move unilaterally but to  
> work to correct/ameliorate some of the omissions that I've seen  
> historically in the OpenID development community.
>
> Chris
>
> -- 
> Chris Messina
> Citizen-Participant &
>  Open Web Advocate
>
> factoryjoe.com // diso-project.org // vidoop.com
> This email is:   [ ] bloggable    [X] ask first   [ ] private
> _______________________________________________
> board mailing list
> board at openid.net
> http://openid.net/mailman/listinfo/board

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-board/attachments/20090408/de36a059/attachment.htm>


More information about the board mailing list