Re: [lldb-dev] [llvm-dev] 12.0.1-rc1 release has been tagged

[Chandler Carruth via lldb-dev]

In addition to the issues mentioned in this thread, I'd also like to ask if
it would be possible to fix these two bugs as well:
https://bugs.llvm.org/show_bug.cgi?id=43604 (maybe unique to Debian
packages)
https://bugs.llvm.org/show_bug.cgi?id=46321

Both of these are fixable exclusively by passing flags to CMake during the
build, no source changes are needed here. Homebrew packages for Linux have
fixed them now, but it'd be really great for the Linux distribution
packages to have these fixes too.

I believe the only thing needed is to add the following to the
`RUNTIMES_CMAKE_ARGS` list:
-DCMAKE_POSITION_INDEPENDENT_CODE=ON
-DLIBCXX_ENABLE_STATIC_ABI_LIBRARY=ON
-DLIBCXX_STATICALLY_LINK_ABI_IN_SHARED_LIBRARY=OFF
-DLIBCXX_STATICALLY_LINK_ABI_IN_STATIC_LIBRARY=ON
-DLIBCXX_USE_COMPILER_RT=ON
-DLIBCXXABI_USE_COMPILER_RT=ON
-DLIBCXXABI_USE_LLVM_UNWINDER=ON

(Technically, the last three are not strictly necessary, but without them
the installed libc++ and libc++abi libraries may fail due to missing
features in libgcc_s on some Linux platforms and it seems both easy and
beneficial to avoid this.)

On Wed, May 26, 2021 at 12:15 AM Tom Stellard via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> Hi,
>
> I've tagged the 12.0.1-rc1 release.  Testers may upload binaries and
> report results.
>
> -Tom
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [llvm-dev] December LLVM bay-area social is this Thursday!

[Chandler Carruth via lldb-dev]

+1, i'm just glad you're making progress on a promising option!

On Sat, Dec 28, 2019 at 8:33 PM JF Bastien  wrote:

> The guy on the phone said that wouldn’t be a problem 🤷‍♂️
> I hope that stays correct! Ideally we’d have the same deal: indeterminate
> number of people, ordering off the menu. I’ll check with you if that’s not
> the case.
>
>
> On Dec 28, 2019, at 7:41 PM, Chandler Carruth 
> wrote:
>
> 
> Mostly worried because we talked to them before and they wanted us to buy
> a banquet menu at  A lot of dollars.
>
> On Sat, Dec 28, 2019, 19:15 JF Bastien via cfe-dev 
> wrote:
>
>> I reached out to Steins (which is right across the street) to see if they
>> can host us. I’ll keep y’all posted, it seemed optimistic in our phone chat.
>>
>>
>> On Dec 24, 2019, at 11:06 AM, George Burgess IV via cfe-dev <
>> cfe-...@lists.llvm.org> wrote:
>>
>> Oof. :(
>>
>> Offhand, I can’t think of any place in particular. As one might imagine,
>> accommodating 50+ people isn’t always super easy for places to do.
>>
>> Suggestions welcome!
>>
>> On Tue, Dec 24, 2019 at 10:27 AM Sean Silva 
>> wrote:
>>
>>> It looks like Tied House will be shutting down :( Do we have a
>>> replacement venue?
>>>
>>>
>>> https://www.mv-voice.com/blogs/p/2019/12/23/facing-monthslong-closure-due-to-chemical-contamination-mountain-view-brewery-tied-house-calls-it-quits
>>>
>>>
>>> On Wed, Dec 4, 2019 at 12:49 PM George Burgess IV via llvm-dev <
>>> llvm-...@lists.llvm.org> wrote:
>>>
 We'll be at Tied House as usual, starting on Thursday the 5th at 7pm!

 If you can, help us plan and RSVP here:
 https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyzqbhb

 See everyone there!

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

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

Re: [lldb-dev] [cfe-dev] [llvm-dev] December LLVM bay-area social is this Thursday!

[Chandler Carruth via lldb-dev]

Mostly worried because we talked to them before and they wanted us to buy a
banquet menu at  A lot of dollars.

On Sat, Dec 28, 2019, 19:15 JF Bastien via cfe-dev 
wrote:

> I reached out to Steins (which is right across the street) to see if they
> can host us. I’ll keep y’all posted, it seemed optimistic in our phone chat.
>
>
> On Dec 24, 2019, at 11:06 AM, George Burgess IV via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
> Oof. :(
>
> Offhand, I can’t think of any place in particular. As one might imagine,
> accommodating 50+ people isn’t always super easy for places to do.
>
> Suggestions welcome!
>
> On Tue, Dec 24, 2019 at 10:27 AM Sean Silva  wrote:
>
>> It looks like Tied House will be shutting down :( Do we have a
>> replacement venue?
>>
>>
>> https://www.mv-voice.com/blogs/p/2019/12/23/facing-monthslong-closure-due-to-chemical-contamination-mountain-view-brewery-tied-house-calls-it-quits
>>
>>
>> On Wed, Dec 4, 2019 at 12:49 PM George Burgess IV via llvm-dev <
>> llvm-...@lists.llvm.org> wrote:
>>
>>> We'll be at Tied House as usual, starting on Thursday the 5th at 7pm!
>>>
>>> If you can, help us plan and RSVP here:
>>> https://www.meetup.com/LLVM-Bay-Area-Social/events/kncsjlyzqbhb
>>>
>>> See everyone there!
>>>
>> ___
>>> LLVM Developers mailing list
>>> llvm-...@lists.llvm.org
>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] RFC: Moving toward Discord and Discourse for LLVM's discussions

[Chandler Carruth via lldb-dev]

Hello folks,

I sent the message quoted below to llvm-dev@ just now, but it applies to
the whole community so sending an FYI here. Probably best to follow up w/
discussion on llvm-dev.

The archive link for reference is here:
http://lists.llvm.org/pipermail/llvm-dev/2019-November/136880.html

On Sun, Nov 17, 2019 at 11:48 PM Chandler Carruth 
wrote:

> Hello everyone,
>
>
> *Short version:*I've set up an LLVM Discord server for real time chat
> (similar to IRC) and an LLVM Discourse server for forums (similar to email
> lists):
> https://discord.gg/xS7Z362
> https://llvm.discourse.group/
>
> Please join and use these new services. They are only partially set up and
> still very new, so don't hesitate to improve them and/or reach out to this
> thread with any issues you see or things you want to fix. Also, both
> services have dedicated feedback channels.
>
> Do feel free to use Discourse for technical discussions, although try not
> to create duplicate discussions (any more than you would between the lists
> and Bugzilla) and make sure the people you're having the discussion with
> are fine using Discourse instead of the email list. In case Discourse
> doesn't work out, we'll collect and archive everything so it isn't lost.
>
>
> *Longer version & more details:*During this year's Women in Compilers and
> Tools meeting, folks expressed very clearly that our communication systems
> cause a non-trivial amount of friction for new people trying to find out
> about, learn, or contribute to LLVM. Both IRC for chatting and mailing
> lists for longer-form discussions are unfamiliar, difficult, and often
> intimidating for newcomers. While I have long been a fan and resistant to
> change in these areas, the feedback from folks at WiCT was compelling and
> important for us as a community to address. Even if it means I have to let
> go of my precious IRC. ;]
>
> We talked to a bunch of people and looked at the options out there and the
> most promising ones were Discord for chatting and Discourse for longer-form
> discussions. Meike and I have set up both an initial Discord and Discourse
> server. You can find them here:
> https://discord.gg/xS7Z362
> https://llvm.discourse.group/
>
> There is still a lot of work to be done. Notably, it'd be great for folks
> to clean up and improve the summaries for each of the groups in Discourse,
> and I'll be asking various people to help moderate on both Discourse and
> Discord. If you'd like to help out with a specific set of improvements to
> these, don't hesitate to reach out to me or Meike and we can get you set
> up. Some specific things we're already working on:
>
>- Getting Discord verified with a nice URL.
>- Archives of mailing lists on Discourse so you can search in one
>place, etc.
>   - See the plan here:
>   
> https://llvm.discourse.group/t/mirroring-and-archiving-llvm-mailing-lists-on-discourse/61
>- Moving Discourse to forums.llvm.org.
>- Documenting the best way to move to Discourse while preserving a
>similarly email-focused workflow.
>
>
> We're just adding these for now, but I'd like people to seriously try
> using them. While IRC has served us fairly well, I think it is one of the
> bigger barriers to entry. Our email lists are more effective, but also have
> had serious infrastructure challenges over the years: a constant flow of
> spam, bouncing for several major email providers, etc. Discourse has very
> powerful email-based workflows available and I think we should seriously
> consider moving to Discourse long-term instead of the email lists.
>
> I also want to say thanks to all the folks at the WiCT workshop for giving
> me and others feedback. I was pretty set in my ways around these kind of
> things, but hearing the kinds of challenges this has posed to people less
> established in the community was a real eye opener. It takes a lot to speak
> up like this, and I really appreciate it. I hope this also helps start to
> address these long-standing issues. Also a huge thanks to Tanya for
> organizing the WICT workshop and Meike for helping drive this message home
> to me and doing a bunch of the work getting these things set up. I wouldn't
> have been able to do it without her help, especially around Discord bots.
>
> -Chandler
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] New license & developer policy is installed! Subversion is active again!

[Chandler Carruth via lldb-dev]

Thanks for your patience everyone, it was a bit rocky but got done.

The new license is in place and all subsequent contributions to LLVM
projects need to be under this license.

A couple of brief reminders to everyone:

1) For the next week or two, if you are submitting a patch on behalf
of someone else, and you don't work at the same company, confirm with
them that they are aware of the new license and intending to
contribute under it. An easy way to do this is get the patch rebased.
In a few weeks when all incoming patches are based on this, the need
for this is gone. We just don't want people surprised or confused.

2) If your commit access no longer works, you probably have an email
from me mentioning either that you haven't filled out our form, or one
of your employers listed there hasn't signed a corporate agreement.
Steps to get commit access restored were detailed in the prior
email[1] but I'll also repeat them below[2].

3) We will be keeping the LLVM-8 branch's license *unchanged*. It will
remain under the old license. This will mean ensuring all the
cherrypicks to that branch are done under the old license, and we're
working w/ the release team and our lawyer to get guidance on what (if
anything) is needed here. It will likely be very lightweight however.


I'm still doing a bit of house keeping and updating the last remnants
that assume everything is under the old license.

If you have questions, or things aren't working as anticipated, please
reach out to me! You can CC license-questi...@llvm.org for private
discussions, or I'm happy to answer questions and discuss on
llvm-foundat...@lists.llvm.org.

Remember, this is juts installing the new license for *subsequent*
commits. We still will be working diligently to collect agreements
from all contributors, and until we complete that process all the
repositories will retain the legacy license framework, and adhere to
its requirements.

Last but not least, a huge thank you to Mike Edwards who did a ton of
work tonight to get this landed, as well as Anton and Tom who also
helped throughout the process of putting all the mechanical pieces in
place.

-Chandler

[1]: http://lists.llvm.org/pipermail/llvm-dev/2019-January/129069.html

[2]: ## Re-enabling commit access

If your commit access isn't automatically re-enabled, you will have to
take some action. There are several cases here:

a) If you haven't filled out the form (you can do this without signing
anything!), please do that first:
https://goo.gl/forms/X4HiyYRcRHOnTSvC3

b) If you signed the individual agreement, but not all companies you
listed in the form are covered, but your current employer is covered,
just ask license-questi...@llvm.org and let us know who your current
employer is and we will re-enable.

c) If your commits are 100% owned by a company (or companies) despite
your use of a personal email address (or an email we don't recognize
for a company) and you can't sign the individual agreement, please
write an email to license-questi...@llvm.org explicitly stating your
name, the relevant company, and that they own your contributions. As
soon as we have this in our archive and confirm the company is
covered, we will re-enable commit access. We'll follow up regarding
historical contributions later. However, I want to repeat that this
case is challenging for historical contributions and signing the
individual agreement is often much simpler and more cost-effective for
the LLVM project.

d) If your current employer hasn't yet signed the agreement, please
send email to license-questi...@llvm.org clearly stating that both you
and your current employer are aware of the new license and that all
subsequent contributions will be under this license, and we'll try to
re-enable access. However, getting agreement only for subsequent
contributions may be just as much work as getting the full corporate
agreement, so if possible please simply work with your employer as
outlined here: http://llvm.org/foundation/relicensing/#corporate_agreement

e) If you believe all relevant agreements are signed and your commit
access should have been re-enabled but we made an error, just send
email to license-questi...@llvm.org and we will try and fix
everything.

We are doing everything we can before the cut-over on Friday to
minimize how many contributors will be impacted by one of these cases.
And we will have folks working hard to respond rapidly to any further
issues.


On Fri, Jan 18, 2019 at 9:45 PM Chandler Carruth  wrote:
>
> Ok, most of the prep work is done, and SVN access is going down now.
> (Took us longer than anticipated, sorry about that.)
>
> On Fri, Jan 18, 2019 at 2:52 PM Chandler Carruth  wrote:
> >
> > We're getting the last things in place, and expect in roughly one hour
> > we will pause all commit access while we put in place the various
> > mechanical pieces of this.
> >
> > I will send a somewhat detailed email reminding people of what has
> > changed when everything opens back up.
> >
> >

Re: [lldb-dev] Heads up: new license & dev policy is happening in ~1 hour!!!

[Chandler Carruth via lldb-dev]

Ok, most of the prep work is done, and SVN access is going down now.
(Took us longer than anticipated, sorry about that.)

On Fri, Jan 18, 2019 at 2:52 PM Chandler Carruth  wrote:
>
> We're getting the last things in place, and expect in roughly one hour
> we will pause all commit access while we put in place the various
> mechanical pieces of this.
>
> I will send a somewhat detailed email reminding people of what has
> changed when everything opens back up.
>
> If this takes us more than 1-2 hours, I'll send an update with a rough
> time estimate.
>
> Details in case you missed the previous emails:
> http://lists.llvm.org/pipermail/llvm-dev/2019-January/129069.html
>
> -Chandler
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Heads up: new license & dev policy is happening in ~1 hour!!!

[Chandler Carruth via lldb-dev]

We're getting the last things in place, and expect in roughly one hour
we will pause all commit access while we put in place the various
mechanical pieces of this.

I will send a somewhat detailed email reminding people of what has
changed when everything opens back up.

If this takes us more than 1-2 hours, I'll send an update with a rough
time estimate.

Details in case you missed the previous emails:
http://lists.llvm.org/pipermail/llvm-dev/2019-January/129069.html

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

[lldb-dev] New license landing 2019-01-18 (end of next week!)

[Chandler Carruth via lldb-dev]

Greetings all!

# Summary
- We will put the new LLVM license and developer policy in place for all
subsequent commits next Friday (2019-01-18).
- Commit access will be stopped while this is done (starting 3pm PST,
hopefully under 3 hours).
- We will restore commit access for everyone covered by relevant corporate
and/or individual agreements.
- Others will need to take some steps to restore commit access (see below
for details).
- When committing patches contributed to the list by non-committers, ensure
they're aware of the new license.
- We are continuing to collect agreements for historical contributions,
working to full coverage.

If you haven’t yet, please go through the form:
https://goo.gl/forms/X4HiyYRcRHOnTSvC3

# Details

It’s been a long time coming, but we’re in a good position to put the new
license structure in place. This will cover all subsequent contributions to
LLVM projects. Once we complete collecting agreements for historical
contributions (this will take quite some time!), we will be able to remove
the old license. This follows the plan outlined and discussed on the lists:
http://lists.llvm.org/pipermail/llvm-dev/2018-October/126991.html
http://lists.llvm.org/pipermail/llvm-dev/2017-August/116266.html

We plan to install the new developer policy on Friday (2019-01-18). We will
disable all commit access while we install this, update all the relevant
license files, and update the headers of all files across the project. We
expect to turn off commit access at 3pm PST, and will restore everything
ASAP. We will send emails to the list an hour before this begins, when it
begins, and when everything is restored.

Once this is complete, we will start re-enabling commit access. We will
automatically enable commit access for all committers who match either of
these criteria:
1) Signed the individual agreement *and* any relevant employer signed a
corporate agreement.
2) Commits using an email address ending in one of the domains we can
trivially match with an employer that has signed a corporate agreement
covering all such employees.

We have emailed everyone who has committed in the last six months and isn't
covered by one of the above. These emails cover both individual agreements
and any missing corporate agreement. We are working on emailing everyone
who has committed in the last two years before the cut-over. If you haven't
gotten any recent emails about this, you're probably fine. We don't have a
better way of testing whether you're impacted (if we did, we'd use it to
send you a pro-active email).

## Re-enabling commit access

If your commit access isn't automatically re-enabled, you will have to take
some action. There are several cases here:

a) If you haven't filled out the form (you can do this without signing
anything!), please do that first: https://goo.gl/forms/X4HiyYRcRHOnTSvC3

b) If you signed the individual agreement, but not all companies you listed
in the form are covered, but your current employer is covered, just ask
license-questi...@llvm.org and let us know who your current employer is and
we will re-enable.

c) If your commits are 100% owned by a company (or companies) despite your
use of a personal email address (or an email we don't recognize for a
company) and you can't sign the individual agreement, please write an email
to license-questi...@llvm.org explicitly stating your name, the relevant
company, and that they own your contributions. As soon as we have this in
our archive and confirm the company is covered, we will re-enable commit
access. We'll follow up regarding historical contributions later. However,
I want to repeat that this case is challenging for historical contributions
and signing the individual agreement is often much simpler and more
cost-effective for the LLVM project.

d) If your current employer hasn't yet signed the agreement, please send
email to license-questi...@llvm.org clearly stating that both you and your
current employer are aware of the new license and that all subsequent
contributions will be under this license, and we'll try to re-enable
access. However, getting agreement only for subsequent contributions may be
just as much work as getting the full corporate agreement, so if possible
please simply work with your employer as outlined here:
http://llvm.org/foundation/relicensing/#corporate_agreement

e) If you believe all relevant agreements are signed and your commit access
should have been re-enabled but we made an error, just send email to
license-questi...@llvm.org and we will try and fix everything.

We are doing everything we can before the cut-over on Friday to minimize
how many contributors will be impacted by one of these cases. And we will
have folks working hard to respond rapidly to any further issues.

## Non-committer contributions

For non-committer contributions such as patches on lists, bugzilla, or
tools like phabricator, we want to make sure the author is aware of the new
license and intending their contribution to be

[lldb-dev] Holiday update on LLVM's Relicensing effort

[Chandler Carruth via lldb-dev]

I wanted to send out a general but brief update on relicensing as holiday
season (at least in my part of the world) approaches.

(If you don't know what the relicensing effort is, or want background, see
our website: http://llvm.org/foundation/relicensing/)

First off, a huge thank you to everyone who has gone through the
relicensing form and individual agreement. We are making fantastic
progress, with well over 500 individual agreements completed. This covers
over 73% of committers and over 80% of commits in the last 6 months, and
over 63% of committers and over 74% of commits in the last 2 years.

But we need to get these higher, so if you haven't already

*Please send me the best holiday gift you can by filling out the agreement
form below:*
https://goo.gl/forms/X4HiyYRcRHOnTSvC3

=D

We plan to install the new developer policy on *January 14th*, at which
point commit access will be disabled for anyone not covered by an agreement.

We have emailed every committer in the last 6 months who hasn't gone
through the form twice about this already, and will be sending weekly
emails from now until the switch happens.

We have emailed every committer in the last 2 years who hasn't gone through
the form once, and will send at least two more direct emails before the
14th.

Also, please, if at all possible, *sign the agreement as part of this*.
While you may in fact be 100% certain that all of your contributions are
owned by your employer, in many cases the LLVM Foundation will end up
having to verify this which is a very expensive operation and may
significantly delay us confirming that you are covered so we can restore
commit access.


And last but not least, if relevant, please forward the information on our
relicensing page to your current employer as we will need to get them to
sign the corporate agreement by January as well:
http://llvm.org/foundation/relicensing/#corporate_agreement
(Note that companies that have already signed or we are in active
discussions with are listed.)


Thank you again to everyone who has helped with this, is working with their
employers to get these things taken care of, and who has gone through the
individual agreement process.
-Chandler
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [libcxx-dev] LLVM Relicensing Update

[Chandler Carruth via lldb-dev]

On Tue, Oct 16, 2018 at 4:51 PM Pavan Maddamsetti <
pavan.maddamse...@gmail.com> wrote:

> Dear LLVM community,
>
> Please do not agree to relicense LLVM under the Apache 2 license.
>
This has already been discussed extensively. Please see the posts I cited.
I don't really want to re-discuss this, there was clear consensus in the
previous threads.

I acknowledge that some still have concerns, but I don't think
re-discussing it here is going to be constructive. If there is new
information, then a new discussion (not this thread) should be started.
However, the content of your email brings up points that have been
discussed already.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] LLVM Relicensing Update

[Chandler Carruth via lldb-dev]

Greetings,

I wanted to provide an update to all the LLVM project (including all of its
sub-projects) developers about the ongoing effort to relicense under LLVM
under a new, unified license.

TL;DR: It’s actually happening. If you are a contributor to LLVM, help us
out by filling out our form and signing an agreement to cover any
individual contributions you have made:
https://goo.gl/forms/X4HiyYRcRHOnTSvC3

All of this information and the latest status can always be found on the
relicensing website here:
http://llvm.org/foundation/relicensing/


## Background and Process

For background, here is the new license:
http://llvm.org/foundation/relicensing/LICENSE.txt
The motivation, scope, and discussion of the license itself, please see the
most recent thread from Chris on the subject:
http://lists.llvm.org/pipermail/llvm-dev/2017-April/112142.html
Also, we have the proposed new developer policy discussed here:
http://lists.llvm.org/pipermail/llvm-dev/2017-August/116266.html

Based on these discussions, there seems clear consensus to move forward,
and we (the Foundation) have been working on this for the past year. I want
to update folks on the progress and the next steps in the more boring
logistics side of this: how do we actually switch.

Our plan, roughly outlined when discussing the developer’s policy last
year, is to install the new license and the developer policy that
references both the new and old license. At that point, all subsequent
contributions will be under both licenses. To ensure contributors are
aware, we have a two-fold plan:

1) We’re going to get as many active contributors (both companies and
individuals) to explicitly sign an agreement to relicense their
contributions. This will make the change clear and will cover historical
contributions as well.
2) For any remaining contributors, turn off their commit access until we
can confirm they are covered by one of the above agreements.

We plan to have the *vast majority* of contributors handled via #1 ahead of
time, so this will not be disruptive. If necessary, we can delay this to
ensure that #1 covers enough of the active contributors. We do not want to
unnecessarily disrupt contributions, but we also want to move this forward
as fast as we can. For contributors who cannot, for whatever reason,
complete the outlined process (#2 above), please send email to
license-questi...@llvm.org and we'll work, in conjunction with our legal
counsel, to find a path forward.

Our current planned timeline is to install the new developer policy and the
new license after the LLVM 8.0 release branch in January. We will then be
focused on getting all of the historical contributions under an agreement
to relicense so we can remove the old license(s).


## Relicensing Agreements

For #1 to work, we need both individuals and companies to sign an agreement
to relicense. The Foundation has worked with our lawyer and built a process
for both companies and individuals.

For individuals, we’re asking everyone to fill out a form so we have the
necessary information (email addresses, potential employers, etc.) to
effectively relicense their contributions. It contains a link to a DocuSign
agreement to relicense any of their individual contributions under the new
license. We’re really hoping that most people will just sign this agreement
as it avoids us needing to prove whether every contribution is definitively
covered by some company. You can fill out the form and sign the agreement
here:
https://goo.gl/forms/X4HiyYRcRHOnTSvC3

For companies, we also have a DocuSign agreement:
https://na3.docusign.net/Member/PowerFormSigning.aspx?PowerFormId=5a2bb38c-41c4-4ce0-a26e-52a7eb8ae51c
We have already reached out to many major companies already, and a few have
already signed this agreement. We will be collecting more companies from
the form responses and reaching out to them. Feel free to reach out to your
employer with the DocuSign link above, but please check the list of
companies  we’ve
already contacted and try to coordinate internally to avoid duplicate work.

Once we get the new policy and license in place, we’ll be iterating with
these tools until we have everything relicensed, or we have a concrete plan
about what to do with any remaining material.


## New File Headers

With the new license and developer policy, we also need to update the file
headers. The Foundation worked with our lawyer to get a new header approved
that is both minimal and functional:
```
//===-- file/name - File description *- C++
-*-===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM
Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===--===//
```

Some notable aspects:
- No explicit copyright notice. After discussion with our law

Re: [lldb-dev] [cfe-dev] LLVM Bay Area Social July poll

[Chandler Carruth via lldb-dev]

Looks like 3:1 for having the social on July 12th... George, want to
officially call it (after confirming we can move w/ our lovely restaurant)?

On Thu, Jun 14, 2018 at 2:38 PM Chandler Carruth 
wrote:

> Twitter poll should be up:
> https://twitter.com/chandlerc1024/status/1007376443762880513
>
> (Why twitter? I'm lazy and know how to do it... and hey, I always love
> getting more folks on my twitter ;])
>
> On Thu, Jun 14, 2018 at 11:35 PM George Burgess IV via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> Hello all!
>>
>> I've received a few concerns about the date of the upcoming bay area LLVM
>> social. In particular, the 5th of July is a holiday for some people, others
>> won't be in town, etc.
>>
>> So, I was wondering what peoples' thoughts are on moving next month's
>> social to July 12th.
>>
>> Chandler volunteered to make a Twitter poll for this; I'll let him link
>> it.
>>
>> To be clear: this is just for July. Socials in August/September/... are
>> still planned for the first Thursday of their respective months.
>>
>> Any thoughts appreciated.
>>
>> Thanks!
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] LLVM Bay Area Social July poll

[Chandler Carruth via lldb-dev]

Twitter poll should be up:
https://twitter.com/chandlerc1024/status/1007376443762880513

(Why twitter? I'm lazy and know how to do it... and hey, I always love
getting more folks on my twitter ;])

On Thu, Jun 14, 2018 at 11:35 PM George Burgess IV via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> Hello all!
>
> I've received a few concerns about the date of the upcoming bay area LLVM
> social. In particular, the 5th of July is a holiday for some people, others
> won't be in town, etc.
>
> So, I was wondering what peoples' thoughts are on moving next month's
> social to July 12th.
>
> Chandler volunteered to make a Twitter poll for this; I'll let him link it.
>
> To be clear: this is just for July. Socials in August/September/... are
> still planned for the first Thursday of their respective months.
>
> Any thoughts appreciated.
>
> Thanks!
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [6.0.0 Release] Scheduling the release

[Chandler Carruth via lldb-dev]

FWIW, I don't have really strong objections, but I'm honestly not a fan.
The reason is mostly that I think it is very late to make the change and
likely to mean most people are on holiday when the branch occurs. I
somewhat anticipate significantly more cherrypicks as a consequence. I'd
love for Apple's releases to by sync'd with the open source ones, but I
don't understand why one week earlier is so critical. That said, I
generally defer to those who are working more heavily on the open source
releases.

The one thing I have a stronger opinion about is the idea of a "feature
freeze", stabilization period, or other change. I'm pretty strongly opposed
to this. One of the things that I most appreciate about the LLVM community
and process is that the top-of-tree is always open, always active, and
always kept green. Things that seem very likely to follow from trying to
change this process:

- People won't follow the guidelines because it would be a pretty huge
shift from prior workflows.
- We'll need some enforcement policy which will end up driving people to
use more branches and generally develop things less incrementally and with
less review.
- There will be the feeling that outside of these windows it is some how
less critical to keep top-of-tree "stable"

It also isn't clear what problem this idea is trying to solve. If the
release testers need the tree to start off closer to "ready", we should add
continuous testing of these areas and hold patches to that *always*, not
just right before a branch.

Anyways, my two cents
-Chandler

PS: None of the above means we shouldn't minimize *disruption* right before
a branch to make things easier. Making things hard to cherry pick, or
having APIs in a half-way state isn't a great idea. But folks already do a
good job (in my experience) timing disruptive changes to land in ways that
are friendly to the release branching schedule.

On Thu, Dec 14, 2017 at 1:57 PM Hans Wennborg via Openmp-dev <
openmp-...@lists.llvm.org> wrote:

> On Wed, Dec 6, 2017 at 9:28 AM, Hans Wennborg  wrote:
> > Hello everyone,
> >
> > It's time to start making plans for the 6.0.0 release.
> >
> > Following our regular schedule, the branch would occur about two weeks
> > into January, on Wednesday 17 January 2018, with the goal of shipping
> > early March. This is the schedule I would propose.
> >
> > However, one large consumer of the branch has asked if we could start
> > earlier this time, branching on 3 January instead (not moving the ship
> > date), to get a longer period for stabilization that syncs with their
> > internal process.
> >
> > While I'm hesitant to change the schedule because I think it's
> > important that it's predictable, there is a benefit of having large
> > users "in sync" with the upstream release branch, as that means more
> > people testing the same code.
> >
> > I will be out of the office the first weeks of January (and I'm
> > guessing other members of the community might be too), so while I
> > could get the branch started on the 3rd, it would be a kind of
> > "slow-start" of the process, but still allow those who want to start
> > testing and nominating merges to do so.
> >
> > Ultimately, it comes down to what the community prefers. Should we
> > stick to the regular schedule, or should we do the "slow-start" two
> > weeks early this time?
> >
> > Let me know what you think, especially those of you involved in the
> > release testing.
>
> Since there wasn't really any opposition to the 3 January "slow start"
> suggestion, let's go with that. I propose the following schedule:
>
> 3 January 2018 - Branch point. Those who want can start testing and
> nominating merges.
> 17 January 2018 - Release Candidate 1 tag, testing of that starts.
> 7 February 2018 - Release Candidate 2, things should ideally look
> pretty good now
> 21 February 2018 - Final tag. (Typically this slips a bit; just try
> not to slip into March.)
>
> Unless there are any objections, I'll post this on the web page soon.
>
> Cheers,
> Hans
> ___
> Openmp-dev mailing list
> openmp-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/openmp-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] FYI, enabling email verification requirement for creating Phabricator accounts

[Chandler Carruth via lldb-dev]

Never mind. The option doesn't work the way desired. I'll follow up with
Eric about other ideas to reduce spam.

On Fri, Apr 21, 2017 at 2:51 PM Chandler Carruth 
wrote:

> Hoping this will at least reduce the spam starting to show up. Let me or
> Eric know if you hit any issues with this (we've not tried it before).
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] FYI, enabling email verification requirement for creating Phabricator accounts

[Chandler Carruth via lldb-dev]

Hoping this will at least reduce the spam starting to show up. Let me or
Eric know if you hit any issues with this (we've not tried it before).
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] FYI, Phabricator is really slow due to HN about LLD

[Chandler Carruth via lldb-dev]

Nah, its fine. Would have been completely easy to throw the necessary
hardware at handling the load if I hadn't messed up the config. =]

On Fri, Feb 17, 2017 at 2:39 PM Andrew Kelley via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> Ah, sorry about that. Maybe I should have linked to the mailing list
> archive instead of the phabricator code review page.
>
> On Fri, Feb 17, 2017 at 2:23 PM, Chandler Carruth via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
> https://news.ycombinator.com/item?id=13670458
>
> I'm restarting Phab with lots more cores / memory. Hopefully back up and
> fast soon.
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] FYI, Phabricator is really slow due to HN about LLD

[Chandler Carruth via lldb-dev]

Fixed! So sorry for the email outage folks, was my bad.

On Fri, Feb 17, 2017 at 1:58 PM Chandler Carruth 
wrote:

> Have they come back? the instance appeared to reboot cleanly and the pages
> are serving... I'll dig into this in a couple of hours when I can.
>
> On Fri, Feb 17, 2017 at 1:37 PM Alex Bradbury via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
>
> On 17 February 2017 at 19:23, Chandler Carruth via lldb-dev
>  wrote:
> > https://news.ycombinator.com/item?id=13670458
> >
> > I'm restarting Phab with lots more cores / memory. Hopefully back up and
> > fast soon.
>
> Hi Chandler,
>
> Email notifications and the "recent changes" feed
> (https://reviews.llvm.org/feed/) seem to have stopped around the time
> you sent this email.
>
> Best,
>
> Alex
>
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] FYI, Phabricator is really slow due to HN about LLD

[Chandler Carruth via lldb-dev]

Have they come back? the instance appeared to reboot cleanly and the pages
are serving... I'll dig into this in a couple of hours when I can.

On Fri, Feb 17, 2017 at 1:37 PM Alex Bradbury via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> On 17 February 2017 at 19:23, Chandler Carruth via lldb-dev
>  wrote:
> > https://news.ycombinator.com/item?id=13670458
> >
> > I'm restarting Phab with lots more cores / memory. Hopefully back up and
> > fast soon.
>
> Hi Chandler,
>
> Email notifications and the "recent changes" feed
> (https://reviews.llvm.org/feed/) seem to have stopped around the time
> you sent this email.
>
> Best,
>
> Alex
> ___
> LLVM Developers mailing list
> llvm-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] FYI, Phabricator is really slow due to HN about LLD

[Chandler Carruth via lldb-dev]

https://news.ycombinator.com/item?id=13670458

I'm restarting Phab with lots more cores / memory. Hopefully back up and
fast soon.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] FYI: Landing the initial draft for an LLVM Code of Conduct

[Chandler Carruth via lldb-dev]

On Thu, Jun 30, 2016 at 12:18 PM C Bergström 
wrote:

> So discussion has been beaten to death and based on your comments - it
> seems you anticipate strong support.
>

I think there has been explicit strong support on the threads.


> Is any (in)formal vote planned? Will this just get enacted, "who" decided..
>

I don't think we need any kind of vote. I think there is pretty clear and
widespread consensus. It's not unanimous of course, but I don't think that
is a requirement or reason to have some kind of vote. If there are large
numbers of contributors who actively disagree with this direction, I think
they have had many opportunities to speak up (and thanks for doing just
that on prior threads). And folks can always speak up now or in the future.
If there is a clear change of consensus, the community can and should
respond to that.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] FYI: Landing the initial draft for an LLVM Code of Conduct

[Chandler Carruth via lldb-dev]

Hello folks,

As mentioned some time ago[1], we’ve had a long (looong) series of
discussions about establishing a code-of-conduct for the LLVM project as a
whole over on the llvm-dev thread and the http://reviews.llvm.org/D13741
code review.

The discussion has largely died down for some time, and towards the end
there has been pretty wide support for the draft wording we have now. It
isn’t perfect, and there are still some important questions around forming
the advisory committee to handle reporting, but I think the wording is at a
good point of compromise in a challenging area.

Based on the support, I’m going to land the patch that adds the draft. I’m
hoping this will immediately provide good advice and guidance, and I’m
hoping to see motion on setting up a reasonable advisory committee and
resolving any issues around reporting so we can make this an official part
of the community.

I sending this as a heads up so folks are aware, not to start a new
discussion thread. There are existing discussion threads[2] on llvm-dev if
folks want to join in active discussion or we can start fresh ones, but I
would encourage people to carefully read the discussion that has already
taken place to avoid revisiting areas that have already been heavily
discussed.

Also, many thanks to the folks who provided all their opinions on the
mailing list threads and in person in long discussions about this topic.

Thanks,
-Chandler

[1]: Prior announcements:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html
http://lists.llvm.org/pipermail/cfe-dev/2015-October/045460.html
http://lists.llvm.org/pipermail/lldb-dev/2015-October/008530.html
http://lists.llvm.org/pipermail/openmp-dev/2015-October/000954.html

[2]: Existing threads:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html
http://lists.llvm.org/pipermail/llvm-dev/2016-May/099120.html
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20151019/307070.html
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] [Openmp-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Chandler Carruth via lldb-dev]

On Tue, Jun 28, 2016 at 12:55 PM Chandler Carruth via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> My 2 cents.
>

And just to be explicit, I 100% support the person doing the heroic work to
*make* our releases having the final say in how they are numbered. =]
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [Openmp-dev] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Chandler Carruth via lldb-dev]

On Tue, Jun 28, 2016 at 12:45 PM Rafael Espíndola 
wrote:

> > I don't think this is as obvious as you might think it is. We can happily
> > drop the "major version equals bitcode compatibility" implicit promise
> if we
> > want, but it's been there for a while and will need some messaging as to
> the
> > actual promises here and what we'll do to fulfill and what we mean when
> we
> > want to change it (will we actually rev the version? not?). I think
> Hans's
> > idea for the release is fine and then will let us argue it as much as
> we'd
> > like on llvm-dev until we get a proposal that people are happy with.
>
> The promise just says that 4.0 *will* read 3.X and 4.1 might.
>

Yes, but while you have read it and interpreted it precisely, I suspect
that many people have misinterpreted it and assume that 4.0 will be the
last release to read 3.X. They may be incorrect, but I think it would still
be worth considering them and working to communicate this effectively.

Essentially, what Eric said: it may be accurate, but it isn't *obvious*, at
least not to everyone.


>
> I think I agree with Chris with 3.10 being the worst possible outcome.
>

I'd be interested to understand why you or Chris thing 3.10 is the worst
possible outcome.

Chris has said it is because he thinks we'll never change the "3", but I
don't understand why 3.10 is worse than 3.9 was in that respect. I happen
to agree that we'll never change the "3", but I don't think this makes 3.10
a particularly bad choice.


I'm seeing pretty much zero support for continuing to have a major/minor
split. As such, I pretty strongly suggest that as a community we move to a
single integer that increments every (time based) release, and a .N that
increments with every patch release off of that branch. GCC and numerous
other projects work this way.

I actually don't care at all what the number is: 4 or 40 seem fine.

If 4 seems too confusing, and 40 seems too extreme, how about 10.
Seriously. It seems exactly as good as any other integer to start counting
rationally, and won't confuse people by looking like a 4.0 release.

My 2 cents.
-Chandler
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Chandler Carruth via lldb-dev]

On Mon, Jun 27, 2016 at 3:38 PM Hans Wennborg via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> On Mon, Jun 27, 2016 at 3:29 PM, Chris Lattner  wrote:
> > On Jun 27, 2016, at 8:26 AM, Hans Wennborg via llvm-dev <
> llvm-...@lists.llvm.org> wrote:
> >> That's what concerns me about going to the scheme Richard and Rafael
> >> suggested, of bumping the major version each time: we'd release 4.0,
> >> and would Tom's dot-release then be 4.1? That would be confusing to
> >> those who are used to our current scheme. Chris suggested going
> >> straight to 40 to avoid this, but that also seems a bit extreme.
> >
> > Extreme how?  What do you mean by “extreme"?
>
> Sorry, that might have been a poor choice of wording.
>
> I just meant that change seems to have a much greater magnitude than
> the other proposals. I realize that's sort of the point, to make the
> change clear to users, but instinctively it feels wrong -- like
> cheating by skipping 36 versions :-)
>

Eh, if we're switching to a completely unrelated versioning scheme, it
doesn't seem completely unreasonable.

We could also count how many time-based releases we have had and use that...

:: shrug ::

I think counting from 4 or counting from 40 are all fine ways to number
releases.


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

Re: [lldb-dev] [cfe-dev] [llvm-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Chandler Carruth via lldb-dev]

On Sun, Jun 26, 2016 at 10:01 AM Xinliang David Li via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> I also believe this is the simplest versioning scheme*. It eliminates all
> future debates on this topic (e.g, when to bump major version etc) and
> solves the problem once and for all --  which is another plus :)
>

Except that we'll have to keep dealing with people who are confused why we
have two version numbers but they don't mean anything. That's why I think
if we don't want major/minor going forward, we should remove the '.'
regardless of what number we pick.


>
> *) similar suggestions a) start from 4, increase by 1; b) start from 40,
> increase by 1.   Date based scheme is also a variant of it.
>
> David
>
>
> On Sun, Jun 26, 2016 at 7:21 AM, Reid Kleckner via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> I also support Chris's position of 4.0, 4.1 etc. I don't think
>> "majorness" is that important, and we can sort out the bit code
>> compatibility story some other way.
>>
>> Sent from phone
>> On Jun 24, 2016 4:42 PM, "Hans Wennborg via llvm-dev" <
>> llvm-...@lists.llvm.org> wrote:
>>
>>> On Mon, Jun 13, 2016 at 4:54 PM, Hans Wennborg 
>>> wrote:
>>> > Breaking this out into a separate thread since it's kind of a separate
>>> > issue, and to make sure people see it.
>>> >
>>> > If you have opinions on this, please chime in. I'd like to collect as
>>> > many arguments here as possible to make a good decision. The main
>>> > contestants are 4.0 and 3.10, and I've seen folks being equally
>>> > surprised by both.
>>>
>>> Thanks everyone for chiming in.
>>>
>>> Please correct me if I misrepresent your opinion here, but I need to
>>> try and summarize this thread for my own sanity:
>>>
>>> The thread started out with lots of support for 3.10, the reasoning
>>> being roughly that we shouldn't bump the major version number unless
>>> we want to signify major change (Mehdi, Hal, Blaikie, Saleem,
>>> Chandler, Anton, Eric, Aaron, Sean, Vikram).
>>>
>>> Richard suggested that since we do time-based rather than
>>> feature-based releases, the distinction between a release with or
>>> without major changes is arbitrary, and we should move to a scheme
>>> where we update the major version number on each release (4.0, 5.0,
>>> etc.) with minor releases in between (4.1, 5.1, ..).
>>>
>>> Chris advocated for "keep adding 0.1 to each major release" (in the
>>> decimal sense), i.e. 3.9, 4.0, 4.1, etc. I haven't seen anyone else
>>> suggest this. "I do not think it is reasonable at all to go to '3.10'
>>> after '3.9', because we will never get to '4.0'."
>>>
>>> Chris then expressed support for alternatively just incrementing the
>>> major version each time, as Richard suggested, but starting at 40.
>>>
>>> Rafael expressed support for the above, but starting at 4.0: "It is
>>> simply not worth the time to try to figure out what is 'major' in a
>>> project with so many different uses."
>>>
>>> Chandler said he didn't like Chris's "keep adding 0.1 to each major
>>> release" scheme: "we shouldn't just go from 3.9 to 4.0 because of some
>>> decimal correspondence", and said he was open to either going to 3.10
>>> with the current major/minor split, or if we don't want that, use
>>> Richard's suggestion.
>>>
>>> Michael pointed out that if we do change the numbering scheme,
>>> changing the binary compatibility guarantee to something time-based
>>> isn't equivalent to what we currently have.
>>>
>>>
>>>
>>> So, it seems we're at an impasse with several folks in favour of 3.10,
>>> Chris speaking out strongly against it, and Richard's option which has
>>> some traction and which no one's disagreed with so far, but which
>>> would be a bigger change.
>>>
>>> I'll have a think about this over the weekend.
>>>
>>> Cheers,
>>> Hans
>>> ___
>>> LLVM Developers mailing list
>>> llvm-...@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>>>
>>
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Chandler Carruth via lldb-dev]

On Tue, Jun 14, 2016 at 1:32 AM Richard Smith via cfe-dev <
cfe-...@lists.llvm.org> wrote:

> On Mon, Jun 13, 2016 at 5:03 PM, Hal Finkel via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>> - Original Message -
>> > From: "Hans Wennborg via cfe-dev" 
>> > To: "llvm-dev" , "cfe-dev" <
>> cfe-...@lists.llvm.org>, "LLDB Dev" ,
>> > "openmp-dev (openmp-...@lists.llvm.org)" 
>> > Cc: "r jordans" , "Paul Robinson" <
>> paul_robin...@playstation.sony.com>
>> > Sent: Monday, June 13, 2016 6:54:19 PM
>> > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9 Release]
>> Release plan and call for testers)
>> >
>> > Breaking this out into a separate thread since it's kind of a
>> > separate
>> > issue, and to make sure people see it.
>> >
>> > If you have opinions on this, please chime in. I'd like to collect as
>> > many arguments here as possible to make a good decision. The main
>> > contestants are 4.0 and 3.10, and I've seen folks being equally
>> > surprised by both.
>> >
>> > Brain-dump so far:
>> >
>> > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0
>> > comes after 3.9.
>> >
>> > - There are special bitcode stability rules [1] concerning major
>> > version bumps. 2.0 and 3.0 had major IR changes, but since there
>> > aren't any this time, we should go to 3.10.
>> >
>> > - The bitcode stability rules allow for breakage with major versions,
>> > but it doesn't require it, so 4.0 is fine.
>> >
>> > - But maybe we want to save 4.0 for when we do have a significant IR
>> > change?
>>
>> I think that this is the right approach, and we happen to have a natural
>> forcing function here: opaque pointer types. I think we should increment
>> the major version number when opaque pointer types are here, as it will be
>> a major breaking change, and then we'll have a version 4.0. Until then,
>> unless something else breaking comes up, 3.10 sounds fine to me.
>>
>
> We're talking about version numbers for the entire LLVM project here,
> which encompasses a lot more than LLVM IR, and for many parts of which LLVM
> IR is utterly irrelevant. I'm not convinced that tying version numbers to
> backwards-incompatible changes to IR is reasonable any more, and it doesn't
> seem hard to explicitly document the oldest version with which we are
> compatible (in fact, we need to do that regardless, whether we say it's
> "the same major version" or "everything since 3.0" or whatever else).
>
> Given that our releases are time-based rather than feature-based, I don't
> see a distinct major / minor version being anything other than arbitrary,
> so I'd suggest we take 4.0 as our next release, 4.1 as the first patch
> release on that, 5.0 as the next release after that, and so on.
>

This seems oddly familiar.

So, one point is that LLVM's IR compatibility impacts more projects than
many other things do:
- Clang generates bitcode with '-flto' and cares about compatibility with
it.
- LLD imports bitcode for LTO and cares about compatibility with it.

Certainly, LLDB and libc++ are both ... substantially less impacted.

All that said, I'm not opposed to a dramatically simpler version numbering
scheme which just counts cycles provided we also establish some strategy
for marking the bitcode compatibility requirements.

But I also don't see it as an important change to make right now.
-Chandler


>  -Hal
>>
>> >
>> > - We've never had an x.10 version before; maybe that would be
>> > confusing? Perhaps it's simply time to move on (like Linux 2.6.39 ->
>> > 3.0 and 3.19 -> 4.0).
>> >
>> > - Since we do time-based rather than feature-based releases, the
>> > major
>> > version number shouldn't mean anything special anyway (e.g. big IR
>> > changes or not), so 4.0?
>> >
>> > - Everyone knows that after 9 comes 10, so 3.10 it is. The version is
>> > a tuple after all.
>> >
>> > - Let's go for 4.0 now, and 5.0 after that. Then the "dot"-releases
>> > in
>> > between would correspond to minor version bumps, which would make
>> > sense (and catch up with GCC!).
>> >
>> > - It's just a number, no big deal; flip a coin or something.
>> >
>> > What do you think?
>> >
>> >  - Hans
>> >
>> >
>> >  [1].
>> >  http://llvm.org/docs/DeveloperPolicy.html#ir-backwards-compatibility
>> > ___
>> > cfe-dev mailing list
>> > cfe-...@lists.llvm.org
>> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> >
>>
>> --
>> Hal Finkel
>> Assistant Computational Scientist
>> Leadership Computing Facility
>> Argonne National Laboratory
>> ___
>> cfe-dev mailing list
>> cfe-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [cfe-dev] What version comes after 3.9? (Was: [3.9 Release] Release plan and call for testers)

[Chandler Carruth via lldb-dev]

On Mon, Jun 13, 2016 at 5:03 PM Hal Finkel via lldb-dev <
lldb-dev@lists.llvm.org> wrote:

> - Original Message -
> > From: "Hans Wennborg via cfe-dev" 
> > To: "llvm-dev" , "cfe-dev" <
> cfe-...@lists.llvm.org>, "LLDB Dev" ,
> > "openmp-dev (openmp-...@lists.llvm.org)" 
> > Cc: "r jordans" , "Paul Robinson" <
> paul_robin...@playstation.sony.com>
> > Sent: Monday, June 13, 2016 6:54:19 PM
> > Subject: [cfe-dev] What version comes after 3.9? (Was: [3.9 Release]
> Release plan and call for testers)
> >
> > Breaking this out into a separate thread since it's kind of a
> > separate
> > issue, and to make sure people see it.
> >
> > If you have opinions on this, please chime in. I'd like to collect as
> > many arguments here as possible to make a good decision. The main
> > contestants are 4.0 and 3.10, and I've seen folks being equally
> > surprised by both.
> >
> > Brain-dump so far:
> >
> > - After LLVM 1.9 came 2.0, and after 2.9 came 3.0; naturally, 4.0
> > comes after 3.9.
> >
> > - There are special bitcode stability rules [1] concerning major
> > version bumps. 2.0 and 3.0 had major IR changes, but since there
> > aren't any this time, we should go to 3.10.
> >
> > - The bitcode stability rules allow for breakage with major versions,
> > but it doesn't require it, so 4.0 is fine.
> >
> > - But maybe we want to save 4.0 for when we do have a significant IR
> > change?
>
> I think that this is the right approach, and we happen to have a natural
> forcing function here: opaque pointer types. I think we should increment
> the major version number when opaque pointer types are here, as it will be
> a major breaking change, and then we'll have a version 4.0. Until then,
> unless something else breaking comes up, 3.10 sounds fine to me.
>

+1, complete agreement.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] February LLVM bay-area social is this Thursday!

[Chandler Carruth via lldb-dev]

(actually spelling lldb-dev correctly, sorry for the typo)

We'll be at Tied House as usual, starting on Thursday the 4th at 7pm!

If you can, help us plan and RSVP here: http://meetu.ps/2RN2C5

See everyone there!
-Chandler
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Just a reminder, LLVM bay-area social tonight at 7pm

[Chandler Carruth via lldb-dev]

Location is Tied House as usual.

Feel free to follow and RSVP here:
http://www.meetup.com/LLVM-Bay-Area-Social/events/226284610/
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Reminder: LLVM bay-area social is tonight @7PM

[Chandler Carruth via lldb-dev]

It's the first thursday of the month, and like every month, we have a
social!

7pm at Tied House as usual.

http://www.meetup.com/LLVM-Bay-Area-Social/events/226134792/
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] FYI, there is an RFC for an LLVM Community Code of Conduct

[Chandler Carruth via lldb-dev]

Please see the llvm-dev thread here and direct all discussion there:
http://lists.llvm.org/pipermail/llvm-dev/2015-October/091218.html
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] Reminder, monthly bay-area LLVM social is today at 7pm!

[Chandler Carruth via lldb-dev]

The plan is as always:

7pm, The Tied House, Mountain View

Meetup link: http://www.meetup.com/LLVM-Bay-Area-Social/events/224479893/

See folks there!
-Chandler

PS: sorry for not sending an email at the start of th eweek, will try to do
that more regularly.
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

[lldb-dev] September LLVM bay-area social!!!

[Chandler Carruth via lldb-dev]

It's that time again! Sorry for the late reminder, but tomorrow is the
first Thursday of the month and we will once again be gathering at the Tied
House at 7pm! Come, Joon us to debate new IR constructs, crazy C++ features
and any and everything else LLVM!

The meetup link is:
http://www.meetup.com/LLVM-Bay-Area-Social/events/224477737/

See you all there!
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev