<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">This protocol is tricky to get right.  But I think that the ideas sketched in Section 6.1 come close.  (For completeness, here is the <a href="https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst">current draft plan.)</a></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">First, we should make explicit in every proposal what library changes (if any) there are, and to which libraries.  All by itself that will be helpful.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Second. the ghc-experimental library provides authors with more options than we had in the past:<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ul><li>They can propose changes to base, and accept the additional constraints of discussing with the CLC; including any changes that subsequently prove to be necessary or desirable<br></li><li>Or, in many cases, they can deliver their proposal through ghc-experimental, which CLC is quite content for the GHC CS to curate.</li></ul><div>Third, we envisage that the shepherd will explicitly invite the CLC to express a non-binding opinion about any proposal modifying base.   That greatly lessens the risk of a proposal being accepted that the CLC is unhappy with.  No one wins if that happens!<br></div><div><br></div><div>The "non-binding" bit is important: the devil is sometimes in the details.  But remember that acceptance of a GHC proposal is *also* non-binding.  We explicitly say that if the implementation adds too much complexity, or shows up new issues that were not discussed when the proposal was accepted, then we may not land it.  Acceptance is a decision in principle.</div><div><br></div><div>(Side note.  I don't think we should be legalistic about this, but if CLC does not voice any objection to changes to base explicitly called out in the proposal, then it would be very unusual for them to subsequently reject outright a CLC proposal to implement those same changes.  Let's jump that bridge if we come to it; I don't think we will!)</div><div><br></div><div>So fourth, the protocol does envisage that, as part of the implementation process, the implementor will make a CLC proposal.  It should be no more than a copy/paste of the relevant section from the proposal, but it'll be at the point of "I firmly intend to implement this proposal, so it is worth requesting CLC bandwidth to discuss the detailed specifics of the API changes".  <br></div><div><br></div><div>This all makes sense to me.  I hope it does to you all, as members of the GHC SC. Please say if not.  I'm keen to get this tied up so we can publicise it.<br></div><div><br></div><div>I would be happy to elaborate Section 6.1, to make it more clear and specific, if anyone has some draft text they would like to propose.</div><div><br></div><div>Simon<br></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 9 Jul 2023 at 05:53, Vladislav <<a href="mailto:vlad.z.4096@gmail.com">vlad.z.4096@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id="m_8964872964724930765geary-body" dir="auto"><div>This proposal has just popped up in another discussion, and its implications dawned on me.</div><div><br></div><div>I see two major issues with the proposal in its current form:</div><div><br></div><div>1. Proposal authors shouldn't need to interact with two committees instead of one. It is generally fine to have coordination between committees, so I can imagine a system where GHC SC cannot approve a proposal on its own and must contact CLC when a proposal touches base. Proposal authors mustn't be bothered with the intricacies of this process, they need to write a single document, submit it on a single platform, and then either have it accepted or rejected, whether by GHC SC alone or by a joint GHC SC + CLC committee.</div><div><br></div><div>2. Proposal implementors need a single source of truth for the accepted changes. If the proposal document has been marked accepted, it means that it's ready for implementation. Now, I have no problem whatsoever with involving CLC before a proposal is accepted, but once it's done, it's done. It's quite important to be able to point potential contributors to a document that describes the changes we want to see in GHC and its libraries, and it can't be that parts of this document are actually accepted and parts of it are kind-of-accepted-but-non-binding-and-another-proposal-on-another-platform-is-pending.</div><div><br></div><div>So I agree with the general idea that it's important to get CLC involved, but for the sake of proposal authors and proposal implementors, this should be a committee-to-committee interaction, not a person-to-two-committees interaction; and acceptance of a proposal needs to be a single atomic operation instead of having kind-of-accepted documents floating around in the ghc-proposals repo.</div><div><br></div><div>Vlad</div></div><div id="m_8964872964724930765geary-quote" dir="auto"><br>On jeu., juin 29 2023 at 09:49:09 +01:00:00, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:<br><blockquote type="cite"><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">  make the GHC proposal in conjunction with a CLC proposal and
 land them in GHC together. Streamlining this process would be good <br></div></blockquote><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">That is absolutely an option, yes.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 29 Jun 2023 at 08:27, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>The link in the email is broken BTW, is there any updated URL?</div><div><br></div><div>Just based on the summary in the email, what immediately springs to mind is that adding functions to ghc-experimental and then moving them to base implies an extra migration that clients have to do in the future (would the APIs in ghc-experimental be deprecated first? For how long? etc.). It probably makes sense only to do this for additions of fairly large new APIs, and for smaller changes we should probably shortcut the process and make the GHC proposal in conjunction with a CLC proposal and land them in GHC together. Streamlining this process would be good. Maybe the actual proposal already says a lot of this?</div><div><br></div><div>Cheers</div><div>Simon</div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 15 Jun 2023 at 10:04, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com" target="_blank">simon.peytonjones@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">Dear GHC Steering Committee</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Over the last few weeks, Ben Gamari and I have been discussing with Andrew and Julian from the Core Libraries Committee how to make the Core Libraries Committee and the GHC developers work together more fluidly; and that includes the GHC Steering Committee.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">We now have a <a href="https://github.com/Ericson2314/tech-proposals/blob/ghc-base-libraries/proposals/accepted/050-ghc-base-libraries.rst" target="_blank">fairly well fleshed out proposal here.</a></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">I hope you like it.  As far as this committee is concerned there are two particular points of note</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><ol><li>We propose a new package, <b>ghc-experimental</b>, which depends on <b>base</b>.  Many GHC proposals involve defining new types and functions.  The idea is that these would initially be in <b>ghc-experimental</b>.  After they stabilise and become widely adopted, the author (or anyone else) can make a CLC proposal to move them to <b>base</b>, which has much stronger stability guarantees.</li><li>Section 5.1 suggests a mechanism to involve CLC members in proposals that involve new functions and types, at an earlier stage.  Some involve <i>changing </i>existing types and functions.  It is clearly unproductive for us to debate such things at length, and only <i>then </i>to land it on the CLC.<br><br>Section 5.1 also suggests that proposals should explicitly (in a separate section) call out</li></ol><ul style="margin-left:40px"><li>What new types and functions it defines</li><li>What existing types and functions are changed.<br></li></ul></div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px">We should add that to our template.</div><div class="gmail_default" style="font-family:tahoma,sans-serif;margin-left:40px"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><div>At the moment we are just sharing the proposal with relevant stakeholders (yourselves, CLC, stack folk, cabal folk etc), so that we can polish any rough edges before making it public.</div><div><br></div><div>So, any views?  Personally I think this is a Big Step Forward.<br></div><div><br></div><div>Simon<br></div><div><br></div></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div></blockquote></div>