[OpenID board] OpenID on Google Code

Chris Messina chris.messina at gmail.com
Sun Apr 5 19:19:38 UTC 2009


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-board/attachments/20090405/d0208c15/attachment-0001.htm>


More information about the board mailing list