No subject

Wed Mar 4 18:19:19 UTC 2009" =97 but or (perhap=
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 becom=
> 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 CP=
> bug tracker, which is where Perl developers ought to expect to find and f=
> 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 wha=
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 o=
> 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 Open=
> Foundation doesn't (directly) do library development.

Agreed. However, the Foundation has a responsibility to make using OpenID
easier =97 for developers and users alike. I don't want the Foundation to h=
a role in maintaining the libraries, but I do think that it needs to be
aware of what's going on with the libraries =97 and how easy it is for peop=
to get into the code and to report issues and have them get fixed.

More information about the board mailing list