Making it easier to contribute patches

  • Greg Haskins

    Greg Haskins - 2011-01-26

    Have you guys considered either adding a mailing list, or better yet, using something like github for the code repository?  FYI: submitting patches via the SF issue tracker is somewhat cumbersome and has poor visibility for reviewers once submitted.

    NBD if you maintain status-quo.  I can adapt.  Just thought I would throw this out there

  • Tobias Schlager

    Tobias Schlager - 2011-01-26

    Thanks for the proposal, I agree the SF tracker system is not really comfortable to use.

    Unfortunately, we initially decided to host the project on SF because the original project was also hosted at SF (and we thought that users could find the new project more easily at this location). Now that we've made that decission we suffer from the drawbacks like slow svn speed, complicated tracker system, etc.

    We talked about moving the project to github a while ago in the team… without conclusion. Moving an existing project is always ugly. The distel emacs mode is a good example for that. It was initially hosted at SF, then moved to google code and is now hosted on github (as far as I now). Thats pretty confusing, especially if you're using a checked out SVN version that at some point simply doesn't get updates any more.

    Since we really appreciate every contribution made, we would really like to make it easier to contribute. A mailing list could be a good compromise but I am sure there's more opinions on that subject.

  • Greg Haskins

    Greg Haskins - 2011-01-26

    Ah, yes, that is a good point about invalidating the URL.  I suppose that anyone doing active development could be made aware one way or the other, but I digress.  I can see how this is undesirable.

    Here is a proposal:  I am not sure if you guys are git./github fans or not.  Since you are obviously Erlang hackers, I figure there is always a chance, so here I go:

    As you may know, git/github use doesnt have to be mutually exclusive to the SF maintained SVN tree.  Git actually works quite easily with an SVN upstream via git-svn (it is in fact exactly how I am working with the maven-erlang-plugin codebase).  So one thing that could be done is to have one or more commiters maintain a parallel git tree (say, "lindenbaum/maven-erlang-plugin" on github, and that tree could be the advertised mechanism with which non-commiters should submit patches.  Keeping github up to date could easily be automated as a cron-job, or equivalent.  Therefore, the only extra burden on the commiters would be when a pull request comes in, but they will have _some_ kind of burden related to patch submission anyway.  I would argue that using something like githubs pull mechanism and git is probably less work than dealing with SF's issue-tracker system.

    Anyway, im just brainstorming here.  I will respect whatever decision you guys make.  Thanks for making a great project.  It was exactly what I was looking for.



Log in to post a comment.