<div class="gmail_quote">On Mon, Mar 30, 2009 at 2:40 PM, Martin Atkins <span dir="ltr"><<a href="mailto:mart@degeneration.co.uk">mart@degeneration.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">Will Norris wrote:<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
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.<br>
<br>
</blockquote>
<br></div>
Is there any reason not to just make openid-php for the PHP libraries, along with later openid-python, openid-java, etc?<br>
<br>
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.)<br>
<br>
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.</blockquote>
<div><br></div><div> Let me propose a couple clarifications and motivations here:</div><div><br></div><div>Goals</div><div>1. to develop a broader and more active community around the OpenID libraries</div><div>2. create more transparency and accessibility for the issue queue/known issues list</div>
<div>3. limit the amount of overhead/maintenance necessary to maintain our source control system</div></div>4. provide a one-stop shop for grabbing current libraries via SVN<div>5. use a modern tool for source control with easier user management<br>
</div><div>6. Diversify the number of contributors and project maintainers.</div><div><br></div><div>Notes</div><div>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.<br clear="all">
2. Google has recently made it possible to de-emphasize the Google Code brand (<a href="http://tr.im/gcode_branding">http://tr.im/gcode_branding</a>) meaning that our choice of hosted repository would be less vendor specific</div>
<div>3. Most people still use SVN, even if GIT is becoming more popular.</div><div>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.</div>
<div>5. I might be inclined to put the website into /openid-website or /<a href="http://openid.net">openid.net</a>, but I'd prefer to keep the number of concurrent projects that we have to manage to a minimum.</div><div>
<br></div><div>There are probably more things about this, but the major difference is making <a href="http://openid.googlecode.com">openid.googlecode.com</a> 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.</div>
<div><br></div><div>Chris</div><div><br>-- <br>Chris Messina<br>Citizen-Participant &<br> Open Web Advocate<br><br><a href="http://factoryjoe.com">factoryjoe.com</a> // <a href="http://diso-project.org">diso-project.org</a> // <a href="http://vidoop.com">vidoop.com</a><br>
This email is: [ ] bloggable [X] ask first [ ] private<br>
</div>