[PATCH] D56819: Document toolchain update policy

JF Bastien via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Jan 17 20:27:28 PST 2019


jfb added a subscriber: hans.
jfb added inline comments.


================
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
----------------
hubert.reinterpretcast wrote:
> 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?
That's really up to the release manager, I don't think we need to nail down every single eventuality. In particular, to really figure out the right thing to do we'd need to know when people compile clang branches: do they do so early or late, or only when the branch is deemed "done"? If say a Linux distro only takes the branch once "done", then your point is totally moot. And say they get bit by something, and decide to start compiling them earlier, then whatever policy is now based on outdated facts.

There's so many eventualities that I really don't think we need to decide on a policy. The release manager is smart, let's trust them. @Hans WDYT?


================
Comment at: docs/DeveloperPolicy.rst:674
+
+  * Turn the soft-error into a hard-error after said LLVM release has branched.
+
----------------
hubert.reinterpretcast wrote:
> 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.
Correct.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D56819





More information about the llvm-commits mailing list