No subject


Wed Mar 4 18:19:19 UTC 2009


openidenabled.com" =97 but openid.net/code or openid.googlecode.com (perhap=
s
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=
e
> 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=
AN
> bug tracker, which is where Perl developers ought to expect to find and f=
ile
> 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=
t
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=
wn
> 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=
ID
> 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=
ave
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=
le
to get into the code and to report issues and have them get fixed.



More information about the board mailing list