From: "François Bobot" <francois.bobot@cea.fr>
To: caml-list@inria.fr
Subject: Re: [Caml-list] Doing compiler patch review with a dedicated mailing-list
Date: Mon, 13 Jan 2014 10:51:23 +0100 [thread overview]
Message-ID: <52D3B71B.40802@cea.fr> (raw)
In-Reply-To: <20140113090444.GA8904@notk.org>
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
next prev parent reply other threads:[~2014-01-13 9:49 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-11 15:23 Adrien Nader
2014-01-11 15:41 ` Simon Cruanes
2014-01-13 9:04 ` Adrien Nader
2014-01-13 9:51 ` François Bobot [this message]
2014-01-13 10:27 ` Gabriel Scherer
2014-01-13 11:14 ` Daniel Bünzli
2014-01-13 13:26 ` Gabriel Scherer
2014-01-13 13:43 ` Thomas Refis
2014-01-13 13:51 ` Gabriel Scherer
2014-01-13 13:57 ` Simon Cruanes
2014-01-13 15:03 ` Török Edwin
2014-01-13 13:58 ` Kakadu
2014-02-17 22:55 ` Richard W.M. Jones
2014-01-13 13:57 ` Daniel Bünzli
2014-01-13 22:30 ` Adrien Nader
2014-01-13 22:39 ` Simon Cruanes
2014-01-13 23:09 ` Adrien Nader
2014-01-14 11:13 ` Gabriel Kerneis
2014-01-14 13:23 ` François Bobot
2014-01-14 13:27 ` Thomas Gazagnaire
2014-01-14 14:06 ` Markus Mottl
2014-01-14 14:12 ` Simon Cruanes
2014-01-14 14:55 ` Amir Chaudhry
2014-01-14 15:09 ` François Bobot
2014-01-14 15:11 ` Anil Madhavapeddy
2014-01-13 16:42 ` Yotam Barnoy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52D3B71B.40802@cea.fr \
--to=francois.bobot@cea.fr \
--cc=caml-list@inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox