[OpenID board] OpenID on Google Code

Chris Messina chris.messina at gmail.com
Mon Mar 30 22:14:26 UTC 2009


On Mon, Mar 30, 2009 at 2:40 PM, Martin Atkins <mart at degeneration.co.uk>wrote:

> Will Norris wrote:
>>
>>
>> Sorry... I guess I didn't finish explaining about the libraries.  We're
>> starting with the PHP library only.  The code itself is housed at github,
>> and the Google Code project will be used for bug tracking and releases.
>>
>>
> Is there any reason not to just make openid-php for the PHP libraries,
> along with later openid-python, openid-java, etc?
>
> This keeps the library development somewhat decentralized, which I think
> will be useful moving forward as maintainers change, etc. (It would be
> annoying if the Python library maintainer had to go through the board to get
> a new maintainer added to the project, for example.)
>
> Even if it's just bug tracking, I don't really see the advantage of having
> the issues for the PHP library in the same tracker as the issues for the
> Python library, or indeed the OpenID website itself; that'll just make it
> harder to find the bugs that are of interest.


 Let me propose a couple clarifications and motivations here:

Goals
1. to develop a broader and more active community around the OpenID
libraries
2. create more transparency and accessibility for the issue queue/known
issues list
3. limit the amount of overhead/maintenance necessary to maintain our source
control system
4. provide a one-stop shop for grabbing current libraries via SVN5. use a
modern tool for source control with easier user management
6. Diversify the number of contributors and project maintainers.

Notes
1. most development of the libraries should happen in repositories of the
maintainers' choice. That is, if someone wants to use Git (highly
recommended), they should be able to. We'll simply do a checkout to the
/openid Google Code project.
2. Google has recently made it possible to de-emphasize the Google Code
brand (http://tr.im/gcode_branding) meaning that our choice of hosted
repository would be less vendor specific
3. Most people still use SVN, even if GIT is becoming more popular.
4. Language-specific repositories is not a terrible idea (/openid-php) but
having a canonical repository that we can link to that provides access to
the best known working libraries seems useful. We house all the OAuth
libraries under the /oauth Google Code project and haven't had any problems.
Language-specific mailing lists have emerged, however.
5. I might be inclined to put the website into /openid-website or /
openid.net, but I'd prefer to keep the number of concurrent projects that we
have to manage to a minimum.

There are probably more things about this, but the major difference is
making 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.

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/20090330/63d8a5aa/attachment-0002.htm>


More information about the board mailing list