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

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 22 Jan 2013, at 16:35, Alain Frisch <alain@xxxxxxxxx> 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