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
>