[OpenID board] OpenID on Google Code

Martin Atkins mart at degeneration.co.uk
Mon Mar 30 22:27:41 UTC 2009


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.

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.

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

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.

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.

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




More information about the board mailing list