[OpenID board] OpenID on Google Code
Martin Atkins
mart at degeneration.co.uk
Thu Apr 9 00:36:49 UTC 2009
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 <mart at degeneration.co.uk
> <mailto:mart at degeneration.co.uk>> 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
> board at openid.net
> http://openid.net/mailman/listinfo/board
More information about the board
mailing list