[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