Coke: i don't quite trust git-svn, so I have been using git to keep track of my work and then patching it onto a parrot svn repo. this is probably unfounded paranoia and I need to actually get my git-svn workflow working

moritz: i am not quite sure that *I* know how to get git-svn to play nice, but I will try. currently I am using git to organize my work but I end up using "git diff --no-prefix" to generate a patch and just "patch" an up-to-date svn tree and commit directly with svn. but I am starting to feel comfortable with git-svn, so this will change

moritz: as far as I can see, if I try to use git-svn on a repo that was not started with git-svn, nothing works. git-svn just hangs. other people tell me I am crazy and that it should work, but that is what I know right now. I have been meaning to right a test for git-svn, but I haven't gotten around to it...

allison: I think I understand your objection to a single module repository -- would you instead support a single place to *find* modules? In other words, a repository of just module metadata, and including in Parrot the necessary tools to create and upload a metadata file when you are ready to "publish" your spiffy new module (wherever it happens to be hosted), and conversely for users to search against that metadata repo, select a metada

darbelo: can you explain in more detail why you don't want the Parrot people involved in the module publishing game? I would think our deprecation cycle means that we may want to have some non-trivial input into that, if not outright control ...

also a bit worried that discovery will become a difficult to scale operation, in the sense of pounding on github et al to the point they get a bit annoyed at us. I wonder if the various source repos have usable push APIs (I'm not talking RSS, I'm talking something that's efficient machine to machine, and pushed rather than polled)

Otherwise, the module author has to publish a tarball at least, and then they need some place to put it, and running discovery against every company ftp site won't work, so they need some way to notify the discovery engine to look for the new item. Which brings us back to 'make_publish'

japhb: I ussually think of parrot as a low-level, reusable component. I don't expect the parrot devs to care about the distribution of whatever modules run on their vm anymore than I expect the (extreme example) gcc devs to care about the distribution of the various open source projects written in C.

darbelo: Sure, I can see that ... but Parrot is somewhat special in that a large pillar of its motivation is to promote module sharing, between the HLLs (in the case of HLL-coded modules) and from Parrot to the HLLs (in the case of NCI libraries). In the C world, the closest equivalent I can think of are the desktop projects (GNOME, KDE, freedesktop.org), which all have some way of marking a project 'official', marking releases and bundle

japhb: I see that, but what I would expect the modules to have an independant release cycle. The release cycle for the nci wrapper of library FOO should follow the release cycle of library FOO, not that of parrot.

darbelo: Oh sure, I never meant that libraries would follow parrot's release cycle -- I meant that when we cross a deprecation boundary, we need to make it easy for our users to find the version of a module compatible with the version of parrot they have installed.

Usually, I can find the perl package I want with apt, and if I can't, there's always CPAN search. At most two places to look -- but even so, I find myself somehow annoyed when I have to go the CPAN search.

But at $work, where I have to use distros that don't package the world (as Debian tries to), I go nuts trying to find stuff across lots of different RPM repos. In fact, I often find it easier to badger Dag to package something for RPMforge than to go find it myself.

darbelo: I meant, if we federate just the metadata, then Rakudo users don't need to know or care whether they are pulling from a Parrot repo, or from a Perl 6 repo, or a Rakudo-specific repo, or directly from some github project ...

Tene: nope. Usually the stuff I need from CPAN has sufficiently finicky prereqs that a knowledgeable person figuring out library version interactions is helpful -- I'm not really an RPM guy, I can just cargo-cult a SPEC occasionally.

chromatic: Ah OK. Well, I don't see mirrors as something we need to provide, merely that we should support the possibility that a VCS site might be mirrored by a third party, and let the market take it from there.

OK, sounds like some consensus is forming in general. Now for the next level of detail: what tools and standards do we need to provide? I'd say at a minimum we need to standardize metadata format and semantics, and the names (and possibly formats) of any special files such as README, CHANGES, etc. And we (by which I mean the community, not the Parrot core team) need to provide a search server and a web and API interface to it.