No subject


Wed Mar 4 18:19:19 UTC 2009


> "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 t=
o
> get things done, since library development has traditionally been autonom=
ous
> 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 =97 something that I currently do not see.

I don't want the Foundation to get in the middle of code decisions, but I d=
o
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 i=
n
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

--=20
Chris Messina
Citizen-Participant &
 Open Web Advocate

factoryjoe.com // diso-project.org // vidoop.com
This email is:   [ ] bloggable    [X] ask first   [ ] private

--001636284d68b998010466d3a962
Content-Type: text/html; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

<div class=3D"gmail_quote">On Mon, Mar 30, 2009 at 6:27 PM, Martin Atkins <=
span dir=3D"ltr">&lt;<a href=3D"mailto:mart at degeneration.co.uk">mart at degene=
ration.co.uk</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" sty=
le=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
Chris Messina wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<br>
There are probably more things about this, but the major difference is maki=
ng <a href=3D"http://openid.googlecode.com" target=3D"_blank">openid.google=
code.com</a> &lt;<a href=3D"http://openid.googlecode.com" target=3D"_blank"=
>http://openid.googlecode.com</a>&gt; the place to check out the latest ver=
sions of all the libraries. Issue management for each library might be a se=
parate issue to consider, but we do need a place to manage issues for the w=
ebsite.<br>

<br>
</blockquote>
<br>
Having what are essentially forks in Subversion makes me nervous, just beca=
use Subversion is notoriously bad at dealing with forks and merging.<br></b=
lockquote><div><br></div><div>Use the right tool for the job; I agree.</div=
>
<div>=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Having actual =
distribution archives all in one place makes a great deal of sense, of cour=
se. 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.</blockquote>
<div><br></div><div>Yes, I think that&#39;s mostly what I want -- that is, =
a canonical place to point people to get the latest libraries that will act=
ually be maintained.</div><div><br></div><div>Historically I&#39;ve found t=
hat central code repositories are maintained better than CMS-managed web pa=
ges or wiki pages that are perceived as untrustworthy... I could be wrong h=
ere, but I&#39;m looking to solve the problem that arises when someone asks=
 &quot;Where do I get the latest OpenID libraries?&quot; From a marketing/r=
ecall perspective, the answer should not be &quot;<a href=3D"http://openide=
nabled.com">openidenabled.com</a>&quot; =97 but <a href=3D"http://openid.ne=
t/code">openid.net/code</a> or <a href=3D"http://openid.googlecode.com">ope=
nid.googlecode.com</a> (perhaps via a redirect from the .net URL).</div>
<div><br></div><div>=A0</div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">However, it wo=
uld concern me if -- for example -- the repository for the perl libraries t=
hat 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 merg=
e without excessive pain.)<br>
</blockquote><div><br></div><div>Agreed. Perhaps the Google Code OpenID rep=
o should therefore be read-only.</div><div><br></div><div>=A0</div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex;">
I&#39;m also adverse to the idea of centralizing the bug tracking because t=
he Perl libraries already have a bug tracking solution in the form of the C=
PAN bug tracker, which is where Perl developers ought to expect to find and=
 file bugs on CPAN libraries.</blockquote>
<div><br></div><div>Agreed. Writing up documentation on how and where to re=
port bugs/issues for the various libraries would seem like a good idea. Hav=
ing visibility in what are known or outstanding issues is also critical/ess=
ential.</div>
<div>=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">As far as the =
number of concurrent projects to manage goes, I would expect this to be sol=
ved by having the maintainer of each library maintain his own project. Ther=
e&#39;s no reason why the OpenID Foundation needs to have any involvement i=
n the day-to-day running of these projects, because the OpenID Foundation d=
oesn&#39;t (directly) do library development.<br>
</blockquote><div><br></div><div>Agreed. However, the Foundation has a resp=
onsibility to make using OpenID easier =97 for developers and users alike. =
I don&#39;t want the Foundation to have a role in maintaining the libraries=
, but I do think that it needs to be aware of what&#39;s going on with the =
libraries =97 and how easy it is for people to get into the code and to rep=
ort issues and have them get fixed.</div>
<div><br></div><div>From that perspective, the Foundation is something of a=
 &quot;services front-end&quot; to the code-maintainers =97 so that develop=
ers can do what they need to do and the Foundation can play pass interferen=
ce or help route interest or getting the code.=A0</div>
<div>=A0</div><div><br></div><blockquote class=3D"gmail_quote" style=3D"mar=
gin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">From a more ph=
ilosophical point of view I&#39;m leery of the OpenID Foundation &quot;owni=
ng&quot; or &quot;managing&quot; any aspect of the libraries. As I mentione=
d before, it&#39;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&#39;d hate to get into a situation where OIDF is &quo=
t;blessing&quot; 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?)</blockquote>
<div>=A0</div><div>Well, this is all good and well as long as there is a vi=
brant community around the libraries =97 something that I currently do not =
see.=A0</div><div><br></div><div>I don&#39;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 t=
hat means making sure that the work of the maintainers is readily available=
 for other folks to use, then so be it. =A0</div>
</div><br>I also think that the Foundation has some responsibility to make =
sure that the code is being developed transparently, with a public issue tr=
acking and commit log. While these things should be managed by developers, =
there is a need for oversight in these matters that start with the technica=
l but end in the political, and that&#39;s where the Foundation&#39;s role =
comes in.<div>
<br></div><div>I think that we are in general agreement, but I appreciate y=
our perspective on this. My intention is not to move=A0unilaterally=A0but t=
o work to correct/ameliorate some of the omissions that I&#39;ve seen histo=
rically in the OpenID development community.</div>
<div><br></div><div>Chris<br clear=3D"all"><br>-- <br>Chris Messina<br>Citi=
zen-Participant &amp;<br> =A0Open Web Advocate<br><br><a href=3D"http://fac=
toryjoe.com">factoryjoe.com</a> // <a href=3D"http://diso-project.org">diso=
-project.org</a> // <a href=3D"http://vidoop.com">vidoop.com</a><br>
This email is: =A0 [ ] bloggable =A0 =A0[X] ask first =A0 [ ] private<br>
</div>

--001636284d68b998010466d3a962--


More information about the board mailing list