[PATCH] D56819: Document toolchain update policy

[Hubert Tong via Phabricator via llvm-commits]

hubert.reinterpretcast marked an inline comment as done.
hubert.reinterpretcast added inline comments.


================
Comment at: docs/DeveloperPolicy.rst:677
+  * Update the :doc:`coding standards<CodingStandards>` to explicitly allow the
+    new features we've now unlocked.
+
----------------
jfb wrote:
> hubert.reinterpretcast wrote:
> > jfb wrote:
> > > hubert.reinterpretcast wrote:
> > > > The suggested wording implies that consensus for updating version requirements for some generic toolchains is consensus to update the set of language features to "whatever falls out of the support provided by those toolchain versions". I think that this step in the proposed process should instead be to identify the features that are now available by the minimum versions of the popular toolchains, and begin a discussion on what features we will start using.
> > > An earlier point says:
> > > 
> > > > * An RFC is sent to the `llvm-dev mailing list <http://lists.llvm.org/mailman/listinfo/llvm-dev>`_
> > > >
> > > >    - Detail upsides of the version increase (e.g. allow LLVM to use newer C++
> > > >      language or library features; avoid miscompiles in particular compiler
> > > >      versions, etc).
> > > >    - Detail downsides on important platforms (e.g. Ubuntu LTS status).
> > > 
> > > If you think that wording is unclear, please provide concrete alternatives.
> > Motivations for a version increase should not be confused with the results of a version increase. If a non-motivating feature is "unlocked" by the version increase, for example, that feature would not necessarily have been mentioned prior to reaching this step. I do not see why such a feature then automatically becomes "fair game".
> > 
> > An explicit discussion of the language support necessary allows users of compilers other than the "popular toolchains" to evaluate the requirements and communicate with their vendors.
> That's a pretty adversarial reading of the policy... I've clarified the wording to avoid that pitfall.
Thanks; this addresses the point I raised.


================
Comment at: docs/DeveloperPolicy.rst:670
+
+  * Ensure that at least one LLVM release has had this soft-error. Not all
+    developers compile LLVM tip-of-tree. These release-bound developers should
----------------
I believe we should be clear as to whether this means one release cycle where the soft-error has been present since the last release branched, or if we mean that the soft-error made it into one release branch (no matter how late the soft-error was added).

For example: If the soft-error is added late in the development cycle of a release (say, to 10.0 in December), does the proposed process imply that top-of-tree can have the hard-error by next January with a soft-error only added over the holiday season?


================
Comment at: docs/DeveloperPolicy.rst:674
+
+  * Turn the soft-error into a hard-error after said LLVM release has branched.
+
----------------
This does mean that release-bound developers (who do not look at top-of-tree, release candidates, or the mailing list) will, on discovering that they might not be able to move to the next release (thanks to the warning), find that top-of-tree has already been unusable for them for around 2-3 months (or whatever amount of time it took for the release to ship after being branched from trunk). Which is to say that the warning truly is just telling them, and not really asking them.


Repository:
  rL LLVM

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D56819/new/

https://reviews.llvm.org/D56819