On Mon, Mar 30, 2009 at 6:27 PM, Martin Atkins <[email protected]
<mailto:[email protected]>> wrote:
Chris Messina wrote:
There are probably more things about this, but the major
difference is making openid.googlecode.com
<http://openid.googlecode.com> <http://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.
Having what are essentially forks in Subversion makes me nervous,
just because Subversion is notoriously bad at dealing with forks
and
merging.
Use the right tool for the job; I agree.
Having actual distribution archives all in one place makes a
great
deal of sense, of course. 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.
Yes, I think that's mostly what I want -- that is, a canonical
place to point people to get the latest libraries that will
actually be maintained.
Historically I've found that central code repositories are
maintained better than CMS-managed web pages or wiki pages that are
perceived as untrustworthy... I could be wrong here, but I'm
looking to solve the problem that arises when someone asks "Where
do I get the latest OpenID libraries?" From a marketing/recall
perspective, the answer should not be "openidenabled.com <http://openidenabled.com
>" — but openid.net/code <http://openid.net/code> or
openid.googlecode.com <http://openid.googlecode.com> (perhaps 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 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 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 CPAN bug tracker, which is where Perl developers
ought to expect to find and file 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 what 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 own 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 OpenID Foundation doesn't
(directly)
do library development.
Agreed. However, the Foundation has a responsibility to make using
OpenID easier — for developers and users alike. I don't want the
Foundation to have a role in maintaining the libraries, but I do
think that it needs to be aware of what's going on with the
libraries — and how easy it is for people to get into the code and
to report issues and have them get fixed.
From that perspective, the Foundation is something of a "services
front-end" to the code-maintainers — so that developers can do what
they need to do and the Foundation can play pass interference or
help route interest or getting the code. From a more
philosophical point of view I'm leery of the OpenID
Foundation "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 to get things done, since library
development
has traditionally been autonomous 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 — something that I currently do not
see. I don'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
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 in 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
--
Chris Messina
Citizen-Participant &
Open Web Advocate
factoryjoe.com <http://factoryjoe.com> // diso-project.org <http://diso-project.org
> // vidoop.com <http://vidoop.com>
This email is: [ ] bloggable [X] ask first [ ] private
------------------------------------------------------------------------
_______________________________________________
board mailing list
[email protected]
http://openid.net/mailman/listinfo/board
