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

[Gabriel Scherer <gabriel.scherer@gmail.com>]

During the last "why no ocaml on github" thread, I had a discussion
with Jonathan Protzenko, which suggested precisely that we encourage
pull requests on the existing Github mirror as a way to send patches
-- to lower the participation cost for those that are too cool to use
a bug tracker of the previous decade. Adrien's suggestion of using a
mailing-list seems equally interesting (I'm in favor of everything
that can increase community participation to OCaml), but indeed we
should probably make a choice between the several options.

The nice thing with mailing-list is that they have easy-to-browse
archives, that in my experience work more reliably than search stuff
in a github repository (in Batteries we tend to have things scattered
across a web of issues, pull-requests, and commit comments that
cross-reference each other, and I'm not always even sure where I
should write). They're also based on a stable, well-established, *free
software* stack that is there to stay (about Github, a Wise One
remarked that "yesterday the same people were commanding that we host
OCaml on Sourceforge; look where it is now!"). On the other hand,
reacting to a perceived lack of sexiness of Mantis with a
mailing-list... I'm not sure.

I'm not personally afraid of having several places where patches are
proposed (it is de facto already what happens, between the bugtracker,
direct communication/review, people that post a link to a
gitweb/github/gitlab view...), but I would be fine with blessing one
"preferred" place and documenting it where it needs be.

Re. wiki/documentation/whatever, we could take inspiration from the
fine work done in the Cambridge are (
https://github.com/ocamllabs/compiler-hacking ). Let me take this as
an occasion to remind that patches to insert enlightening comment in
the admittedly-not-always-commented-enough compiler and distribution
are welcome, and can be contributed right now.

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