'languages' repository on svn.parrot.org

jerry gay jerry.gay at gmail.com
Fri Feb 27 01:57:14 UTC 2009


On Thu, Feb 26, 2009 at 17:10, Will Coleda <will at coleda.com> wrote:
> On Thu, Feb 26, 2009 at 7:56 PM, Allison Randal <allison at parrot.org> wrote:
>> We have a new 'languages' subversion repository and Trac instance, available
>> for languages targeting Parrot. Most of the languages that haven't already
>> migrated to other repositories will be migrating to this repository.
>
> I would have no problem if languages that hadn't yet been moved were
> simply removed. If they eventually get a maintainer back, an svn copy
> of the last revision they were in can happen then.
>
>> The
>> repository and Trac instance are at:
>>
>>  https://svn.parrot.org/languages
>>  https://trac.parrot.org/languages
>
> What plans then for: http://code.google.com/p/squawk/ ?
>
>> Your username and password for these are always the same as your username
>> and password for Parrot's SVN and Trac, but the permissions are different
>> (that is, you may have ticket management or commit access to 'languages' but
>> not to 'parrot', or vice versa).
>
> Plans for CLA/Copyright/Licensing?
>
>> Each language has it's own 'trunk' and 'branches', so the general way of
>> checking out a language is:
>>
>>  svn co https://svn.parrot.org/languages/punie/trunk punie
>>
>
> Are we going to setup separate commit (or dev) mailing lists for
> languages? Right now language commits are being sent to the parrot
> list (with invalid changeset URLs.)
>
using squawk would have left this can of worms unopened. we're not
specialists at hosting trac repositories for parrot-related projects
(we're still working out the kinks of our own repo migration), and it
seems to me googlecode has solved this problem well enough for us in
the short term.  i'd rather we keep it simple now, and take advantage
of existing free infrastructure, rather than building our own at the
expense of much needed developer-hours.  however, the nature of
volunteer open-source efforts in general is such that there are
neither enough carrots nor enough sticks to manage contributors and
contributions effectively.  certainly, aspects of parrot are indeed
well-managed (most notably the development cadence surrounding our
regular release cycle); still, parrot is no exception to the general
rule.

alas, i'm too far away from the problem right now to determine whether
we're better off finishing this particular job or undoing it.
~jerry


More information about the parrot-dev mailing list