I won't try to speak for all library developers, but as far as the Perl
libraries go I currently:
* Post the code to a repository on code.sixapart.com. It lives in a Six
Apart repository for historical reasons, but we can get external
developers commit access if necessary. (I was committing there long
before I worked at 6A.)
* Track bugs on the CPAN bugtracker.
* Post releases on CPAN.
* Encourage discussion on the openid-perl Google Group. (It's a pretty
quiet list, but I do watch it.)
This is what Perl developers generally expect. I've no objection to OIDF
mirroring the tarballs or, ideally, linking to them on CPAN, but I
wouldn't want to see secondary bug trackers and source code repositories
being created because that's liable to cause confusion in my opinion,
and I'd prefer to keep the Perl-library-related discussion separate so
that it doesn't get lost amongst questions relating to other libraries.
Chris Messina wrote:
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
_______________________________________________
board mailing list
[email protected]
http://openid.net/mailman/listinfo/board
