[OpenID board] OpenID on Google Code

Thu Apr 9 00:36:49 UTC 2009

I won't try to speak for all library developers, but as far as the Perl 
libraries go I currently:

* Post the code to a repository on code.sixapart.com. It lives in a Six 
Apart repository for historical reasons, but we can get external 
developers commit access if necessary. (I was committing there long 
before I worked at 6A.)

* Track bugs on the CPAN bugtracker.

* Post releases on CPAN.

* Encourage discussion on the openid-perl Google Group. (It's a pretty 
quiet list, but I do watch it.)

This is what Perl developers generally expect. I've no objection to OIDF 
mirroring the tarballs or, ideally, linking to them on CPAN, but I 
wouldn't want to see secondary bug trackers and source code repositories 
being created because that's liable to cause confusion in my opinion, 
and I'd prefer to keep the Perl-library-related discussion separate so 
that it doesn't get lost amongst questions relating to other libraries.

Chris Messina wrote:
> On Mon, Mar 30, 2009 at 6:27 PM, Martin Atkins <mart at degeneration.co.uk 
> <mailto: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> <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 <http://openidenabled.com>" — but openid.net/code 
> <http://openid.net/code> or openid.googlecode.com 
> <http://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 <http://factoryjoe.com> // diso-project.org 
> <http://diso-project.org> // vidoop.com <http://vidoop.com>
> This email is:   [ ] bloggable    [X] ask first   [ ] private
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> board mailing list
> board at openid.net
> http://openid.net/mailman/listinfo/board