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