[lldb-dev] LLVM 8.0.0 Release

[Hans Wennborg via lldb-dev]

I'm pleased to announce that LLVM 8 is now available.

Get it here: https://llvm.org/releases/download.html#8.0.0

This release contains the work on trunk up to Subversion revision
r351319, plus work on the release branch. It's the result of the LLVM
community's work over the past six months, including: speculative load
hardening, concurrent compilation in the ORC JIT API, no longer
experimental WebAssembly target, a Clang option to initialize
automatic variables, improved pre-compiled header support in clang-cl,
the /Zc:dllexportInlines- flag, RISC-V support in lld. And as usual,
many bug fixes, optimization and diagnostics improvements, etc.

For more details, see the release notes:
https://llvm.org/releases/8.0.0/docs/ReleaseNotes.html
https://llvm.org/releases/8.0.0/tools/clang/docs/ReleaseNotes.html
https://llvm.org/releases/8.0.0/tools/clang/tools/extra/docs/ReleaseNotes.html
https://llvm.org/releases/8.0.0/tools/lld/docs/ReleaseNotes.html
https://llvm.org/releases/8.0.0/projects/libcxx/docs/ReleaseNotes.html

Special thanks to the release testers and packagers: Amy Kwan, Bero
Rosenkränzer, Brian Cain, Diana Picus, Dimitry Andric, Kim Gräsman,
Lei Huang, Michał Górny, Sylvestre Ledru, Ulrich Weigand, Vedant
Kumar, and Yvan Roux.

For questions or comments about the release, please contact the
community on the mailing lists. Onwards to LLVM 9!

Thanks,
Hans
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Release-testers] [8.0.0 Release] The final tag is in

[Brian Cain via lldb-dev]

Uploaded ubuntu and SLES tarballs:

db0a5f7729507ddc4b161eff70cffcf5de052347
clang+llvm-8.0.0-x86_64-linux-sles11.3.tar.xz
2be69be355b012ae206dbc0ea7d84b831d77dc27
clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-16.04.tar.xz
6aeb8aa0998d37be67d886b878f27de5e5ccc5e4
clang+llvm-8.0.0-x86_64-linux-gnu-ubuntu-18.04.tar.xz


On Mon, Mar 18, 2019 at 8:04 AM Hans Wennborg via Release-testers <
release-test...@lists.llvm.org> wrote:

> Dear testers,
>
> The final version of 8.0.0 was just tagged from the release_80 branch
> at r356364. It's identical to rc5 except for a few documentation
> changes.
>
> Apologies for being behind schedule. It took longer than planned this time.
>
> Please build the final binaries and upload to the sftp.
>
> For those following along: this means 8.0.0 is done, but it will take
> a few days to get all the tarballs ready and published on the release
> web page. I will send the announcement once everything is ready.
>
> Thanks again everyone for your help with testing the release!
>
> Hans
> ___
> Release-testers mailing list
> release-test...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/release-testers
>


-- 
-Brian
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [GitHub] RFC: Enforcing no merge commit policy

[James Y Knight via lldb-dev]

Then we should not accept it. What if someone did the same on a phabricator
review?

On Wed, Mar 20, 2019 at 2:39 AM Anton Korobeynikov 
wrote:

> > Github PRs are how everyone who is not already super-involved in the
> llvm project is going to want to contribute changes, and we ought to be as
> welcoming as possible to such users.
> Still we'd need some policy & checks here. Say, what if someone will
> issue a PR to LLVM 4.0 branch? With clear code style violations, etc.
>
> --
> With best regards, Anton Korobeynikov
> Department of Statistical Modelling, Saint Petersburg State University
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [GitHub] RFC: Enforcing no merge commit policy

[David Greene via lldb-dev]

Tom Stellard via llvm-dev  writes:

> 1. Have either a status check or use the "Rebase and Merge" policy for
> pull requests to disallow merge commits.  Disable direct pushes to the
> master branch and update the git-llvm script to create a pull request
> when a developer does `git llvm push` and then have it automatically
> merged if there are no merge commits.

This seems to be the least disruptive to existing developers while
maintaining the invariant we want.  It has the advantage of potentially
being extended in the future to add additional criteria for merges
(e.g. "it builds" or "it passes this set of tests").

> 2. Enforce no merge commits for pull requests, but sill allow
> developers to push directly to master without checking for merge
> requests.  This is essentially a best effort approach where we avoid
> having to implement our own custom work-flow for committing, while
> accepting the possibility that someone might accidentally push a merge
> commit.

To me this is the least desirable.  I'd prefer we have one way of
getting changes into the repository.

> 3. Disable direct pushes to master, don't update the git-llvm script
> and require all developers to use pull requests, where this policy
> will be enforced.

I am completely fine with this.  It's friendlier to new contributors.
That said, I assume with #1 we wouldn't prevent users from git push-ing
their local branch to GitHub (i.e. not using git llvm push) and manually
opening a PR, so either #1 or #3 works for new developers.

> Which option do you prefer?

Maybe a slight preference for #1 as being less disruptive than #3 but I
really don't care either way.

  -David
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [GitHub] RFC: Enforcing no merge commit policy

[Zachary Turner via lldb-dev]

On Tue, Mar 19, 2019 at 12:00 PM Tom Stellard via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> Hi,
>
> I would like to follow up on the previous thread[1], where there was a
> consensus
> to disallow merge commits in the llvm github repository, and start a
> discussion
> about how we should enforce this policy.
>
> Unfortunately, GitHub does not provide a convenient way to fully enforce
> this policy.
>
>
Why isn't this enforceable with a server-side pre-receive hook?
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [GitHub] RFC: Enforcing no merge commit policy

[Tom Stellard via lldb-dev]

On 03/20/2019 10:41 AM, Zachary Turner wrote:
> 
> 
> On Tue, Mar 19, 2019 at 12:00 PM Tom Stellard via lldb-dev 
> mailto:lldb-dev@lists.llvm.org>> wrote:
> 
> Hi,
> 
> I would like to follow up on the previous thread[1], where there was a 
> consensus
> to disallow merge commits in the llvm github repository, and start a 
> discussion
> about how we should enforce this policy.
> 
> Unfortunately, GitHub does not provide a convenient way to fully enforce 
> this policy.
> 
>  
> Why isn't this enforceable with a server-side pre-receive hook?

GitHub[1] only supports pre-receive hooks in the 'Enterprise Server'
plan, which is for self-hosted github instances.

-Tom

[1] https://github.com/pricing
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [GitHub] RFC: Enforcing no merge commit policy

[Zachary Turner via lldb-dev]

It sounds like we need to get someone from the Foundation (chandlerc@,
lattner@, tanya@, someone else?) to reach out to them offline about this.

On Wed, Mar 20, 2019 at 11:23 AM Arthur O'Dwyer 
wrote:

> On Wed, Mar 20, 2019 at 2:19 PM Tom Stellard via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> On 03/20/2019 10:41 AM, Zachary Turner wrote:
>> >
>> > On Tue, Mar 19, 2019 at 12:00 PM Tom Stellard via lldb-dev <
>> lldb-dev@lists.llvm.org > wrote:
>> >
>> > Hi,
>> >
>> > I would like to follow up on the previous thread[1], where there
>> was a consensus
>> > to disallow merge commits in the llvm github repository, and start
>> a discussion
>> > about how we should enforce this policy.
>> >
>> > Unfortunately, GitHub does not provide a convenient way to fully
>> enforce this policy.
>> >
>> >
>> > Why isn't this enforceable with a server-side pre-receive hook?
>>
>> GitHub[1] only supports pre-receive hooks in the 'Enterprise Server'
>> plan, which is for self-hosted github instances.
>>
>
> AIUI, the GitHub team is perfectly willing to help out the LLVM project in
> whatever way LLVM needs, including but not limited to turning on
> server-side hooks for us.
> https://twitter.com/natfriedman/status/1086470665832607746
>
> Server-side hooks are *the *answer to this problem. There is no problem.
> You just use a server-side hook.
>
> (Whether or not to use GitHub PRs is an orthogonal question. You can use
> hooks with PRs, or hooks without PRs; PRs with hooks, or PRs without hooks.)
>
> –Arthur
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [GitHub] RFC: Enforcing no merge commit policy

[Tom Stellard via lldb-dev]

On 03/20/2019 11:38 AM, Zachary Turner wrote:
> It sounds like we need to get someone from the Foundation (chandlerc@, 
> lattner@, tanya@, someone else?) to reach out to them offline about this.
> 

Yes, we will try to reach out to GitHub directly about this, but I still
think we need some kind of contingency plan in case pre-receive hooks
or even a new kind of branch protection won't be an option for us.

-Tom

> On Wed, Mar 20, 2019 at 11:23 AM Arthur O'Dwyer  > wrote:
> 
> On Wed, Mar 20, 2019 at 2:19 PM Tom Stellard via cfe-dev 
> mailto:cfe-...@lists.llvm.org>> wrote:
> 
> On 03/20/2019 10:41 AM, Zachary Turner wrote:
> >
> > On Tue, Mar 19, 2019 at 12:00 PM Tom Stellard via lldb-dev 
> mailto:lldb-dev@lists.llvm.org> 
> >> wrote:
> >
> > Hi,
> >
> > I would like to follow up on the previous thread[1], where 
> there was a consensus
> > to disallow merge commits in the llvm github repository, and 
> start a discussion
> > about how we should enforce this policy.
> >
> > Unfortunately, GitHub does not provide a convenient way to 
> fully enforce this policy.
> >
> > 
> > Why isn't this enforceable with a server-side pre-receive hook?
> 
> GitHub[1] only supports pre-receive hooks in the 'Enterprise Server'
> plan, which is for self-hosted github instances.
> 
> 
> AIUI, the GitHub team is perfectly willing to help out the LLVM project 
> in whatever way LLVM needs, including but not limited to turning on 
> server-side hooks for us.
> https://twitter.com/natfriedman/status/1086470665832607746
> 
> Server-side hooks are *the *answer to this problem. There is no problem. 
> You just use a server-side hook.
> 
> (Whether or not to use GitHub PRs is an orthogonal question. You can use 
> hooks with PRs, or hooks without PRs; PRs with hooks, or PRs without hooks.)
> 
> –Arthur
> 

___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [GitHub] RFC: Enforcing no merge commit policy

[Brian Cain via lldb-dev]

On Tue, Mar 19, 2019 at 2:00 PM Tom Stellard via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> Hi,
>
> I would like to follow up on the previous thread[1], where there was a
> consensus
> to disallow merge commits in the llvm github repository, and start a
> discussion
> about how we should enforce this policy.
>
> Unfortunately, GitHub does not provide a convenient way to fully enforce
> this policy.
> We can enforce it for pull requests, but not for direct pushes to the
> master branch,
> so we will have to come up with our own solution if we want to completely
> prevent
> merge commits.  I've spent some time looking into this and here are a few
> options that I've come up with (If you are a GitHub expert and have other
> suggestions, please let us know):
>
> 1. Have either a status check or use the "Rebase and Merge" policy for
> pull requests
> to disallow merge commits.  Disable direct pushes to the master branch and
> update the
> git-llvm script to create a pull request when a developer does `git llvm
> push` and
> then have it automatically merged if there are no merge commits.
>
> 2. Enforce no merge commits for pull requests, but sill allow developers
> to push directly
> to master without checking for merge requests.  This is essentially a best
> effort
> approach where we avoid having to implement our own custom work-flow for
> committing,
> while accepting the possibility that someone might accidentally push a
> merge commit.
>
> 3. Disable direct pushes to master, don't update the git-llvm script and
> require all
> developers to use pull requests, where this policy will be enforced.
>
> Which option do you prefer?
>
>
>
I don't think I have a preference regarding merge commits but having a
status check where some subset of build + test takes place is a really good
idea, IMO.  It would be great if it were applied for everyone but if that
causes too many problems, I would settle for opt-in.  Preferably not
all-or-nothing on the check.

Regarding the scope of the check (boldly assuming one would be in place):
the more, the better (so long as it's stable and tolerable to the team).
Some dev teams that use GH have a bot that optimistically batch
builds-and-tests commits and when failures inevitably happen, contributors
are encouraged to triage and re-enqueue their PR for being built if they
can surmise the failure is not due to their change.

When contributing changes upstream, it takes away some of the
stress/challenge if you have some independent automaton verify that your
change doesn't cause regressions.  As it stands I feel like I should be on
standby for 24 to 72 hours after the commit in order to investigate/revert
if my change causes someone problems.  I realize that it's prudent to limit
the scope such that the checks don't create an enormous backlog.


-- 
-Brian
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev