caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Yotam Barnoy <yotambarnoy@gmail.com>
To: Fabrice Le Fessant <Fabrice.Le_fessant@inria.fr>
Cc: Ocaml Mailing List <caml-list@inria.fr>
Subject: Re: [Caml-list] Recent hooks design and general github PR issues
Date: Tue, 19 Jul 2016 12:23:28 -0400	[thread overview]
Message-ID: <CAN6ygOkv6u7PiCxw-mO+D5B7v7wL6jV=Z1QCcZaG9XDktJYR_g@mail.gmail.com> (raw)
In-Reply-To: <CAHvkLrPf2sN+KrNvh+O2m3W916d94VpxmbVLjtRTG=WzXatn+A@mail.gmail.com>

See the comments at the bottom of
https://github.com/ocaml/ocaml/pull/668 by avsm and gasche, which can
be seen as asking question about the whole feature (not just the PR).
See also Shinwell's concerns at the bottom of
https://github.com/ocaml/ocaml/pull/647. And note that since they are
on separate PRs, they most likely did not see each others' comments,
which is a problem.

In general, I think the process has to be refined. As this is all part
of one feature, that feature should be discussed first before any
merging begins. And merging should not be done by the person
suggesting the feature.

-Yotam

On Tue, Jul 19, 2016 at 11:36 AM, Fabrice Le Fessant
<Fabrice.Le_fessant@inria.fr> wrote:
> Hi,
>
>>   several core members trying to voice concerns about the feature in one
>> PR, while other member PRs were simply merged into the tree
>
> Could you be more specific ? I think I have taken the time to discuss all
> these PRs (for 20 days for 2 of them, 13 days for the other one), I have
> modified the PRs to follow the requests that were voiced (for example, by
> removing the default -fPIC) and they were all reviewed by other core
> developers. If you think some concerns have not been taken into account,
> please, tell me.
>
>>  yet I have not seen it or its costs vs benefits being discussed fully in
>> any particular place
>
> Probably because the cost vs benefit is very hard to measure in most PR: the
> benefit might be small for some users, and big for other ones; some features
> might be hard to understand and to use, yet one developer can use them to
> develop a tool that can be used by many users; some features might look of
> little use at the beginning, yet, once they are present, other users might
> find usages that were not foreseen in the PR discussion.
>
> --Fabrice
>
>
> On Tue, Jul 19, 2016 at 5:09 PM Yotam Barnoy <yotambarnoy@gmail.com> wrote:
>>
>> I would like to alert the list to a potential problem with github PRs,
>> and a recent example of such a problem.
>>
>> I've noticed that recently, there has been an insertion of a
>> particular feature into the compiler. This feature involves
>> potentially long-term commitment in terms of maintenance, and yet I
>> have not seen it or its costs vs benefits being discussed fully in any
>> particular place. I'm specifically talking about PRs
>> https://github.com/ocaml/ocaml/pull/648,
>> https://github.com/ocaml/ocaml/pull/668 and
>> https://github.com/ocaml/ocaml/pull/647.
>>
>> The problem with github PRs is that they allow you to insert features
>> piecemeal. This splits up the discussion across multiple PRs, making
>> it very difficult to have a discussion about the feature as a whole,
>> and making it seem like there is consensus when there might not be.
>>
>> As a rule, I recommend that any such large feature spanning multiple
>> PRs first require discussion either on the list or on mantis, to
>> concentrate discussion in one place.
>>
>> It may also be worthwhile to say that except for rare exceptions
>> (mostly bug fixes), PRs should not be merged by the same person who
>> authored them, as this makes the process seem biased and questionable.
>>
>> I don't know if this feature in itself is problematic, but I've seen
>> several core members trying to voice concerns about the feature in one
>> PR, while other member PRs were simply merged into the tree. In my
>> opinion, questions on sub-PRs of a feature should inhibit merging any
>> parts of said feature.
>>
>> This may be a false alert, but I think it is worth clarifying if it is
>> indeed one, and at the very least, the protocol should be set for the
>> future.
>>
>> -Yotam
>>
>> --
>> 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

  reply	other threads:[~2016-07-19 16:23 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-19 15:08 Yotam Barnoy
2016-07-19 15:36 ` Fabrice Le Fessant
2016-07-19 16:23   ` Yotam Barnoy [this message]
2016-07-19 17:28     ` Fabrice Le Fessant
2016-07-19 20:21 ` Alain Frisch
2016-07-21 12:09   ` Goswin von Brederlow
2016-07-21 12:38     ` Fabrice Le Fessant
2016-07-21 13:37       ` Hendrik Boom

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='CAN6ygOkv6u7PiCxw-mO+D5B7v7wL6jV=Z1QCcZaG9XDktJYR_g@mail.gmail.com' \
    --to=yotambarnoy@gmail.com \
    --cc=Fabrice.Le_fessant@inria.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;
as well as URLs for NNTP newsgroup(s).