[OpenID board] OpenID on Google Code
David Recordon
david at sixapart.com
Thu Apr 9 17:56:56 UTC 2009
I think it would be fine if you continue doing this for Perl while the
PHP and Python libraries move into a shared project on either Google
Code or GitHub (each has their advantages). If anything, I'd
encourage the Perl repository to join this shared project while
leaving bug tracking and releases on CPAN and discussion on the openid-
perl mailing list.
--David
On Apr 8, 2009, at 5:36 PM, Martin Atkins wrote:
>
> 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
>
> _______________________________________________
> board mailing list
> board at openid.net
> http://openid.net/mailman/listinfo/board
More information about the board
mailing list