Re: [Caml-list] Doing compiler patch review with a dedicated mailing-list

[Yotam Barnoy <yotambarnoy@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5984 bytes --]

On Mon, Jan 13, 2014 at 5:27 AM, Gabriel Scherer
<gabriel.scherer@gmail.com>wrote:

> (about Github, a Wise One
> remarked that "yesterday the same people were commanding that we host
> OCaml on Sourceforge; look where it is now!").
>

I'm just going to focus on this comment: I don't see anything wrong with
this. Companies find good developers by using recruiters and headhunters.
Open source projects do so by, among other things, going to the most
popular places for developers to hang out. Back when sourceforge was
popular, it was a great place for people looking to get involved in open
source projects (like myself). The proper view on this in my opinion is,
how many great devs were *not* introduced to ocaml and did *not* join ocaml
development because ocaml wasn't where the people were? Is it worth the
little bit of hassle to get long-time devs to switch their methodologies
for the benefit of getting more developers into the project/language? In my
humble opinion, the answer is absolutely yes.

Regardless, sourceforge's other advantages in its best days were minimal
for an organization that can host its own repository and issue tracker.
Github has a much bigger advantage in that it comes with a whole ecosystem
of tools that make development that much easier. Github is also a much
bigger player at a time when open source software is a much bigger player
in the world: for example, employees are looking to add open source
projects to their resumes, and they're looking mostly on github (Btw I
realize that ocaml has a mirror on github, but consider that a read-only
mirror is not a lively, encouraging environment with which to interact).

My main problem with Mantis is that one misses out on the ability to see
patches automatically applied to code, and to comment on specific parts of
patches. These things are huge productivity boosts and make it much easier
for many people to participate and comment on patches. Also, being able to
fork and then just post a pull request means that I don't have to mess with
managing patch files at all. There's a good reason the world is moving in
this direction.

I understand the trepidation to have all this extra value trapped within
github, but I have a strong hunch that if github starts losing to another,
better competitor, bigger projects will move out first, and tools will be
developed using the github api to extract and duplicate the metadata. In
fact, a quick search turned up several of these kinds of things already,
just because they're easy to build, e.g.
https://github.com/joeyh/github-backup

It's also useful to see how other languages do things. Mono, Scala and
Clojure are all on github. Of the three, Mono and Clojure don't use the
'issues' feature of github, but all three use pull requests (and the rich
features they enable). Clojure uses Jira (which looks extremely powerful
and is free to open source projects) to manage its issues and planning.
Mono uses bugzilla for managing issues, but also allows/uses pull requests.

Regarding the mailing list, my experience from another open source project
suggests that mailing lists are better for discussion of bigger features,
or for pointing out specific patches for review, rather than spreading out
the discussion in multiple places, but I could definitely be wrong about
this.

-Yotam


On Mon, Jan 13, 2014 at 10:51 AM, François Bobot <francois.bobot@cea.fr>
> wrote:
> > On 13/01/2014 10:04, Adrien Nader wrote:
> >>
> >> On Sat, Jan 11, 2014, Simon Cruanes wrote:
> >>>
> >>> Le Sat, 11 Jan 2014, Adrien Nader a écrit :
> >>>>
> >>>> Hi,
> >>>>
> >>>> (and sorry for the mail sent a few minutes ago :) )
> >>>>
> >>>> I'd like to know what people think about having a mailing-list for
> >>>> reviews and tests of patches to the compiler and tools around it.
> >>>>
> >>>> The idea is to do something similar to the kernel mailing-list. I
> mostly
> >>>> like mantis and it is possible to attach files but it becomes fairly
> >>>> unreadable after a while. The audience is also mostly limited to
> people
> >>>> who are subscribed to the bug report. I hope this reduces the work and
> >>>> burden of reviewers and especially commiters.
> >>>>
> >>>> The goal is not to replace patches on mantis and you shouldn't believe
> >>>> this has been blessed by the core development team (nor mentionned to
> >>>> them actually). Instead, I hope this helps do quicker (and smaller?)
> >>>> iteration of patches.
> >>>>
> >
> > I don't know how you generate and _manage_ patches with svn. Indeed the
> > linux kernel developers never used svn with their mailing-list review
> > workflow and developed git for simplifying this workflow.
> >
> > It seems counterproductive to have more than one place for discussing one
> > thing so I think the developers must make a choice:
> > - keeping patch review in mantis
> > - going to a mailing-list review workflow and moving from svn
> > - going to a merge-request workflow on github, specific gitlab instance,
> > bitbuckets, ...
> >
> > The last two points have the benefit to allow to easily comment inside
> the
> > patches.
> >
> > The third point (at least on github) subsume the second point since you
> can
> > answer to github issues or merge-requests by email. You can also ask to
> be
> > notified for every issues or merge-requests of a project.
> >
> > Best,
> >
> > --
> > François
> >
> >
> > --
> > Caml-list mailing list.  Subscription management and archives:
> > https://sympa.inria.fr/sympa/arc/caml-list
> > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> > Bug reports: http://caml.inria.fr/bin/caml-bugs
>
> --
> Caml-list mailing list.  Subscription management and archives:
> https://sympa.inria.fr/sympa/arc/caml-list
> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
> Bug reports: http://caml.inria.fr/bin/caml-bugs
>

[-- Attachment #2: Type: text/html, Size: 7666 bytes --]