I support whatever the current various maintainers of OpenID libraries
think will make their jobs easier, the code easier to find, more up to
date and higher quality. I know a bunch of developers on the PHP and
Python libraries were interested in having a shared code repository
much like the OAuth community has done really successfully. I don't
really have strong opinions if this is on Google Code or GitHub.
--David
On Apr 5, 2009, at 12:19 PM, Chris Messina wrote:
On Mon, Mar 30, 2009 at 6:27 PM, Martin Atkins <[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> 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" — but openid.net/code
or 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 // diso-project.org // vidoop.com
This email is: [ ] bloggable [X] ask first [ ] private
_______________________________________________
board mailing list
[email protected]
http://openid.net/mailman/listinfo/board
_______________________________________________
board mailing list
[email protected]
http://openid.net/mailman/listinfo/board
