From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id C14857EF1E for ; Tue, 19 Jul 2016 19:29:05 +0200 (CEST) IronPort-PHdr: 9a23:HSTxpxKWYTUrxWOCP9mcpTZWNBhigK39O0sv0rFitYgUIvrxwZ3uMQTl6Ol3ixeRBMOAuqoC1rOd6vi6EUU7or+5+EgYd5JNUxJXwe43pCcHRPC/NEvgMfTxZDY7FskRHHVs/nW8LFQHUJ2mPw6anHS+4HYoFwnlMkItf6KuS9aU0p38jrjos7ToICxwzAKnZr1zKBjk5S7wjeIxxbVYF6Aq1xHSqWFJcekFjUlhJFaUggqurpzopM0r221qtvkg789NV7nhN+R9FOQATWduD2dg1cr3vByLZwKV4HwNGjEHlQZBBgLM9hf9T7/+tyL7sqx23yzMbuPsSrVhdz2o9aZgRVfMhW8pOiUi+WfLwphehahBoRms4Thy9IDZe5qcMuZWf6XHfNpcS3AXDZUZbDBIHo7pN9hHNOEGJ+sN6tCl/1Y= Authentication-Results: mail3-smtp-sop.national.inria.fr; spf=None smtp.pra=Fabrice.Le_fessant@inria.fr; spf=Pass smtp.mailfrom=fabrissimo@gmail.com; spf=None smtp.helo=postmaster@mail-wm0-f47.google.com Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of Fabrice.Le_fessant@inria.fr) identity=pra; client-ip=74.125.82.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="Fabrice.Le_fessant@inria.fr"; x-conformance=sidf_compatible Received-SPF: Pass (mail3-smtp-sop.national.inria.fr: domain of fabrissimo@gmail.com designates 74.125.82.47 as permitted sender) identity=mailfrom; client-ip=74.125.82.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="fabrissimo@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-wm0-f47.google.com) identity=helo; client-ip=74.125.82.47; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="fabrissimo@gmail.com"; x-sender="postmaster@mail-wm0-f47.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0AGAgCyYo5Xfy9SfUpdhAgNfKxShxaHIIcpOxEBAQEBAQEBAREBAQkLCwkfMYIyBAESAYITAQQBEhFWBQsLCzcCAiEBEgEFARwGEyKHdAMPCA6hDoEyPjGLO4laDYQeDAEkEIpngkOEfoJaBZhwNIYThjGCHoI5jH6IJYY6MIEPNIIrHIFMPDKIJQEBAQ X-IPAS-Result: A0AGAgCyYo5Xfy9SfUpdhAgNfKxShxaHIIcpOxEBAQEBAQEBAREBAQkLCwkfMYIyBAESAYITAQQBEhFWBQsLCzcCAiEBEgEFARwGEyKHdAMPCA6hDoEyPjGLO4laDYQeDAEkEIpngkOEfoJaBZhwNIYThjGCHoI5jH6IJYY6MIEPNIIrHIFMPDKIJQEBAQ X-IronPort-AV: E=Sophos;i="5.28,390,1464645600"; d="scan'208,217";a="185256261" Received: from mail-wm0-f47.google.com ([74.125.82.47]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/AES128-GCM-SHA256; 19 Jul 2016 19:29:04 +0200 Received: by mail-wm0-f47.google.com with SMTP id f65so146466660wmi.0 for ; Tue, 19 Jul 2016 10:29:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9x/xEcyt7I3QjoXPcLeoC3mg5kiaLhTbJxqXixSFUys=; b=FpwNN61REcoqlnlnfIdgyzZgCg0FhJZk7c4NvjrdHCCwDbhWpO5SdUQzQ7SyVkpXVs EEinOzQr5xeTdCgX2WMbRlAavGsOj6BBnGhIK//DsEx0md6AVqKLecidoeXyjzMeeV0B nYyFdNuhSy5CvlKpOfMWgfIcgaAz+dbokJCiq8We0pajazsKvr3CLn95CWYkCgjRZxza omCPRLatVRcZxnb0/58kDNuTnmIKkFRjx4a5Zv6qrxRx1VD5aCmq6nkGmZjvfNb4HFTZ ACnLTd+TEOvs6BW9G/J///m53uSt0CWEq5RXxh50lJX8F0L9PkZlAyv8q+LH3kYP7SAP nNrw== X-Gm-Message-State: ALyK8tJUGNIUu5E1PzpUK8HcrjQ0fA7IB2mR7OAEzPcFjndjChQTmDzVjZGTLjmQz8drssRooCSI+fbQZLqm+g== X-Received: by 10.28.55.21 with SMTP id e21mr5941342wma.80.1468949344376; Tue, 19 Jul 2016 10:29:04 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Fabrice Le Fessant Date: Tue, 19 Jul 2016 17:28:54 +0000 Message-ID: To: Yotam Barnoy Cc: Ocaml Mailing List Content-Type: multipart/alternative; boundary=001a1143bf2cdd5c920538006b1e Subject: Re: [Caml-list] Recent hooks design and general github PR issues --001a1143bf2cdd5c920538006b1e Content-Type: text/plain; charset=UTF-8 On Tue, Jul 19, 2016 at 6:24 PM Yotam Barnoy wrote: > See the comments at the bottom of > https://github.com/ocaml/ocaml/pull/668 by avsm and gasche I replied to Gabriel, who was asking for a different API, that could be done, but is not my intent (OCamlPro needs what I implemented, not what he was discussing, so if somebody else wants to contribute the complementary approach, he is welcome), and Anil just said he didn't see the benefit of the interception hooks, which is (1) only one part of the PR (cplugins can be used to do other things, such as have a more portable version of OCamlPro's Memory Profiler) and (2) there are several examples on github.com/OCamlPro/ocp-cplugins that show that the restriction to the stdlib provides already interesting use cases. > See also Shinwell's concerns at the bottom of > https://github.com/ocaml/ocaml/pull/647 Mark was commenting on the maintainability of ppx at Jane Street, not about the maintainability of the ppx code inside the compiler. The discussion was diverging from the actual subject of the PR at that point. > . And note that since they are on separate PRs, they most likely did not > see each others' comments, which is a problem. > I don't understand that part: there is no link between the two PRs, one is about plugins in the runtime, the other one about plugins in the compiler, which have completely different use cases and cost/benefits. > 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. I think it is quite common in the core team, especially before a code freeze. Check all the closed/merged PRs with the black tag "Spacetime prerequisite" for an easy example. The current process is to have at least one code review by another core developer and no strong objection by another core developer. I think it is a good trade-off between fast evolution while keeping good code quality. Finally, about the maintainability, I think having plugins both in the runtime and the compiler will help externalizing some code from the distribution, thus decreasing the maintenance cost of the distribution, while allowing external contributors to extend the runtime and compiler through OPAM packages. Best regards, --Fabrice --001a1143bf2cdd5c920538006b1e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Jul 19= , 2016 at 6:24 PM Yotam Barnoy <yotambarnoy@gmail.com> wrote:
See the comments at the bottom of
https://github.com/ocaml/ocaml/pull/668 by avsm and gasch= e

I replied to Gabriel, who was asking for = a different API, that could be done, but is not my intent (OCamlPro needs w= hat I implemented, not what he was discussing, so if somebody else wants to= contribute the complementary approach, he is welcome), and Anil just said = he didn't see the benefit of the interception hooks, which is (1) only = one part of the PR (cplugins can be used to do other things, such as have a= more portable version of OCamlPro's Memory Profiler) and (2) there are= several examples on gi= thub.com/OCamlPro/ocp-cplugins that show that the restriction to the st= dlib provides already interesting use cases.
=C2=A0
See also Shinwell's concerns at the bottom of
https://github.com/ocaml/ocaml/pull/647
=
Mark was commenting on the maintainability of ppx at Jane St= reet, not about the maintainability of the ppx code inside the compiler. Th= e discussion was diverging from the actual subject of the PR at that point.=
=C2=A0
. And note that since they are=C2=A0on separate PRs, they= most likely did not see each others' comments,=C2=A0which is a problem= .

I don't understand that part: the= re is no link between the two PRs, one is about plugins in the runtime, the= other one about plugins in the compiler, which have completely different u= se cases and cost/benefits.
=C2=A0
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.

I think it is quite= common in the core team, especially before a code freeze. Check all the cl= osed/merged PRs with the black tag "Spacetime prerequisite" for a= n easy example. The current process is to have at least one code review by = another core developer and no strong objection by another core developer. I= think it is a good trade-off between fast evolution while keeping good cod= e quality.

Finally, about the maintainability, I t= hink having plugins both in the runtime and the compiler will help external= izing some code from the distribution, thus decreasing the maintenance cost= of the distribution, while allowing external contributors to extend the ru= ntime and compiler through OPAM packages.

Best reg= ards,
--Fabrice


=C2=A0
--001a1143bf2cdd5c920538006b1e--