Re: Opam package publication (was Re: [Caml-list] [ANN] beta-release of OPAM)

[Anil Madhavapeddy <anil@recoil.org>]

On 22 Jan 2013, at 16:35, Alain Frisch <alain@frisch.fr> wrote:

> On 01/19/2013 11:40 AM, Daniel Bünzli wrote:
>> Yes, I know, that was not the point. I was proposing a lighter process for a package to be included in opam's default repository.
>> 
>> As Alain mentioned, the current process is rather involved for package developers --- but I disagree with his idea of an upload web interface.
>> 
>> The idea is that package developers publish repos with their work
> 
> Concretely, I guess that publish a repo means setting up a server somewhere.  I don't think that everyone can easily do that or want to invest so much effort only to submit a single package.
> 
> What's the benefit of the git/github submission workflow?  I don't immediately see how this is easier for people responsible of accepting/rejection packages than, say, something based on an upload interface (or even simpler, an email with an attachment).


Let's think through what an e-mail workflow might look like rather than just throwing it out as a superior alternative to what we use now.  Let's say it goes to an e-mail list, with a few people subscribed to it.  Then, someone adding the package would reply to the list saying that they'll handle it, and have to deal with it immediately and not get distracted.  Next, we have to convert the package into a Git commit with the submitter's name, so that we have a reasonable package history.  Finally, we need a queue of packages to track which ones haven't been replied to, or else risk forgetting packages.  And of course, anyone who wants to be involved has to subscribe to a mailing list, and the only way to find past submissions is by digging through e-mail archives.

Git/Github takes care of all this, to the point where a merge is a single button on the website.  Specifically, it:

- track provenance of updates (so we can go contact whoever introduced a package reliably, assuming their Github ID doesn't change).

- lets people maintain private branches outside of Github, and easily merge against upstream updates.  Citrix are doing this for their internal repositories, which they re-base against OPAM upstream, and then regularly submit their packages to the mainline once they're tested.  I also do this with Mirage.

- a public tracking system with comments to ensure packages don't get lost. I don't particularly fancy having my mailbox fill up with mailed tar-balls.

- an easy-to-use API that lets us run continuous build directly off Github.  I think of this as "Internet threads". A callback from Github wakes up an Lwt thread to do some work on the continuous build server. That's kind of cool :-)

It should be really trivial to build a package uploader using the OPAM extension mechanism I described earlier, and the ocaml-github bindings. If anyone wants to help add this, get in touch with me and I'll walk you through it.  My plate's a bit too full to get to this in the near-term.

-anil