Re: [lldb-dev] [llvm-dev] RFC: New Automated Release Workflow (using Issues and Pull Requests)

[Philip Reames via lldb-dev]

On 12/20/21 3:24 PM, Tom Stellard via llvm-dev wrote:

On 12/20/21 09:16, Tom Stellard wrote:

On 12/18/21 15:04, David Blaikie wrote:



On Fri, Dec 17, 2021 at 6:38 PM Tom Stellard > wrote:


    On 12/17/21 16:47, David Blaikie wrote:
 > Sounds pretty good to me - wouldn't mind knowing more about/a 
good summary of the effects of this on project/repo/etc 
notifications that Mehdi's mentioning. (be good to have a write up 
of the expected impact/options to then discuss - from the thread so 
far I understand some general/high level concerns, but it's not 
clear to me exactly how it plays out)

 >

    The impact is really going to depend on the person and what 
notification preferences they
    have/want.  If you are already watching the repo with the 
default settings, then you probably
    won't notice much of a difference given the current volume of 
notifications.



I think I'm on the default settings - which does currently mean a 
notification for every issue update, which is a lot. Given that 
llvm-b...@email.llvm.org  has been 
re-enabled, sending mail only on issue creation, I & others might 
opt back in to that behavior by disabling the baseline "notify on 
everything" to "notify only on issues I'm mentioned in".


I guess currently the only email that github is generating is one 
email per issue update. We don't have any pull requests, so there 
aren't any emails for that, yeah?


So this new strategy might add a few more back-and-forth on each 
cherrypick issue (for those using llvm-bugs & disabling general 
issue notifications, this will not be relevant to them - there won't 
be more issues created, just more comments on existing issues). But 
there will be some more emails generated related to the pull 
requests themselves, I guess? So each cherrypick goes from 2 emails 
to llvm-bugs (the issue creation and closure) to, how many? 4 (2 for 
llvm-bugs and I guess at least 2 for the pull request - one to make 
the request and one to close it - maybe a couple more status ones 
along the way?)




I think the number of net new comments on issues will be very minimal 
or none at all.  The
automated comments that are created by this process are replacing 
comments that I'm already making

manually.

So 2+ for pull requests is probably a good estimate.  I still need to 
figure out how many notifications

get generated for Actions with the default settings.



I did some research on the notifications and here is what I came up with:

From what I can tell, notifications for actions are only sent to the
user that initiated the event that led to the actions, so there would
be no global notifications sent for the actions used by this workflow.

There have been 131 bugs marked as release blockers in the llvm-13 cycle,
this includes the 13.0.0 and 13.0.1 release.  In the best case scenario,
this proposal would generate 2 additional notifications per issue
(1 for creating a pull request and 1 for merging it), and 0 net new
issue comments (the automated comments just replace manual comments).

If you assume that no manual comments would be replaced by the 
automation,

then in the typical use case there would be a maximum of  4 notifications
generated from issues (/cherry-pick comment, cherry-pick failed comment,
/branch comment, /pull-request comment). In addition to the 2 pull
request notifications.

Based on this, my estimate is that this proposal will produce between
(2 * 131) = 262 and (6 * 131) = 786 net new notifications every 6 months.
Or between 1.46 and 4.367 net new notifications per day.

For comparison, on Fri Dec 17, I received 115 email notifications from
the llvm/llvm-project repo.

The pull request emails should be easy for people to filter out of their
inboxes with a rule.  Pull request emails would have llvm/llvm-project in
the To: field and have '(PR #123456)' at the end of the Subject: field
(where 123456 is pull request number).

For people who filter out the pull request notifications, they would 
have between

0 and 2.9 net new notifications per day.


This seems both fairly minimal, and well justified to me.

Philip



- Tom



--Tom

    If people want to give their notification preferences, I can try 
to look at how

    this change will impact specific configurations.


@Mehdi AMINI  - are there particular 
scenarios you have in mind that'd be good to work through?



    -Tom


 > On Fri, Dec 17, 2021 at 1:15 PM Tom Stellard via llvm-dev 
mailto:llvm-...@lists.llvm.org> 
>> 
wrote:

 >
 >     Hi,
 >
 >     Here is a proposal for a new automated workflow for 
managing parts of the release
 >     process.  I've been experimenting with this over the past 
few releases and
 >     now that we have migrated to GitHub issues, it would be 
possible for us to

 >     implement this in the main rep

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Code Review Process

[Philip Reames via lldb-dev]

Since I think we're risking confusion on the point here, let me clarify 
that at least my response to this thread should not be read as 
opposition (or support) for a migration to github.  I am expressing no 
opinion on that matter.  I see the primary point being discussed in this 
thread being the decision making process proposed, not the decision itself.


Philip

On 10/6/21 10:26 AM, Chris Tetreault via llvm-dev wrote:


> … nothing's really changed from the previous conversations on PRs 
versus Github, apart from the announcement of end of support by the 
upstream company, but that was quite a while ago now, and even with 
the stale Arcanist issue, there hasn't been a big push from community 
members to change …


James, If you’ll forgive me for cherry-picking a small part of your 
point, I think it bears mentioning that human beings tend to ignore 
future problems until they become current problems. Most of us here 
want to work on compilers, not deal with infrastructure. This doesn’t 
mean that the status quo is ok.


As I see it, it would be a mistake to just continue on with 
zombie-phabricator as we have. Perhaps the board of directors could 
have taken a different tone when presenting this issue, but I think 
they are doing the right thing by forcing a change soon. Tools are 
degrading, and security fixes are not being implemented. If we do 
nothing we’re all going to wake up some day and find that the github 
repo has had its owner changed or somesuch catastrophe. We need to do 
**something**, and I think setting a deadline for a change was the 
right call.


From my perspective, there are 4 reasonable things we can do, in order 
of disruptiveness:


 1. Investigate a community replacement for phabricator. Does Phorge
meet our needs? Is there a maintained fork of phabricator? Can we
just drop in some replacement?
 2. Fork Phabricator, and take on the maintenance burden ourselves.
This sounds like work.
 3. Move to github PRs. As others have mentioned, there are pros and
cons to this.
 4. Something else? We’d have to figure out what this is, and justify
it over options 1-3.

If the deadline the board has set is unpalatable to the community, 
then perhaps it makes sense to fork Phabricator, and then decide on a 
longer term migration plan. But we need to do something and we need to 
do it now, not when there’s an actual fire.


Personally, I like Phabricator, and find github PRs to be tedious to 
work with. If we went with github PRs, I would be able to work, but I 
would prefer something more like phabricator.


thanks,

   Chris Tetreault

*From:* cfe-dev  *On Behalf Of *James 
Henderson via cfe-dev

*Sent:* Wednesday, October 6, 2021 1:47 AM
*To:* Tanya Lattner 
*Cc:* llvm-dev ; Renato Golin 
; clang developer list ; 
openmp-dev (openmp-...@lists.llvm.org) ; 
LLDB Dev 

*Subject:* Re: [cfe-dev] [llvm-dev] RFC: Code Review Process

*WARNING:*This email originated from outside of Qualcomm. Please be 
wary of any links or attachments, and do not enable macros.


Forgive me if I'm wrong, but if the community consensus is that we 
should continue to use Phabricator, and Phabricator is not being 
provided/maintained by the LLVM Foundation, isn't it moot what the 
LLVM Foundation/Infrastructure Working Group recommends/wants to 
happen? The current maintainers would continue to maintain Phabricator 
(assuming they wanted to), and people would still be able to review 
things there. What would happen if the Foundation officially supported 
PRs, without community consensus (in particular from the Phabricator 
maintainers), is a potential split in the community, with some 
continuing in the old way and others using the new way (and presumably 
some choosing to review on both platforms). This cannot be good.


I'm all for the discussion to be had, about whether we switch, but as 
far as I can see, nothing's really changed from the previous 
conversations on PRs versus Github, apart from the announcement of end 
of support by the upstream company, but that was quite a while ago 
now, and even with the stale Arcanist issue, there hasn't been a big 
push from community members to change: the consensus in the posts 
discussing this and the moving to PRs seems to still be "there are 
things that are blocking switching still".


At the most, from this IWG/Foundation consultation, it should be that 
the Foundation recommends one or other approach, and is willing to 
provide X infrastructure required. The community can then choose to 
agree with whatever approach is recommended or stick with the status 
quo. There shouldn't be an edict that says we will do one thing or the 
other.


Another side-point: whilst the IWG may consist of people who care 
about LLVM, there are far more people who care as much, but who just 
don't have the time to participate in such a group. This is 
particularly important to note, because the community does not elect 
members to this group. To an extent, the same is 

Re: [lldb-dev] [llvm-dev] RFC: Code Review Process

[Philip Reames via lldb-dev]

+1 to Renato's response here.  I had the same thought, and Renato 
phrased it much better than I'd have managed.


Philip

On 10/5/21 9:47 AM, Renato Golin via llvm-dev wrote:
On Tue, 5 Oct 2021 at 17:06, Tom Stellard via llvm-dev 
mailto:llvm-...@lists.llvm.org>> wrote:


- Any other information that you think will help the Board of
Directors make the best decision. 


- Foundation Board will have 30 days to make a final decision
about using GitHub Pull Requests and then communicate a migration
plan to the community.


Hi Tom,

Please help me here, I think I'm severely misunderstanding what this 
means...


I'm reading it that the "Board of Directors" will make a decision and 
communicate to the community, apparently through some undisclosed 
internal process.


For example:
 * What about people that are on holidays during the 30 days comment 
period?

 * What if the points are not made clear after 30 days?
 * How do we know the IWG will correctly summarise the comments to the 
board?
 * How does the board guarantee it will take all facts in 
consideration without bias?
 * What kind of recourse would the community have if the decision 
alienates a large part of the developers?


Please understand that I'm not assuming malice *at all*. We're all 
humans, and in the effort to make some change happen we quite often 
let unconscious bias be the merits of our decisions.


For context...

Since its inception[1], the foundation has always steered away from 
technical decisions, always referring to the llvm-dev list for those. 
Previous long running contentious issues (Github, monorepo, CoC) were 
all decided by the community, in the llvm-dev list, and executed by 
the foundation.


Recent discussions about the mailing list, irc, discord, discourse 
have emphasised that, even with an infrastructure working group, the 
views of the community are still too hard to predict and make it work 
for the majority. Neither the board of directors, nor the IWG are wide 
and diverse enough to make decisions that take most people's views 
into consideration. That is why we still rely on the dev list for 
large technical discussions and decisions.


Code review and bug tracking are very much technical decisions. Not 
code directly, but how we all work. And there are a lot of us. Giving 
feedback and having no insight into the decision making process will 
certainly divide the community even more, if we're forced to accept 
whatever outcome.


I can't see how this "solves" the problem of never-ending discussions, 
other than further fragmenting the community.


cheers,
--renato

[1] http://blog.llvm.org/2014/04/the-llvm-foundation.html 



___
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] [llvm-dev] Mailing List Status Update

[Philip Reames via lldb-dev]

On 6/21/21 12:53 PM, Chris Lattner wrote:
On Jun 9, 2021, at 10:50 AM, Philip Reames via llvm-dev 
mailto:llvm-...@lists.llvm.org>> wrote:


Specific to the dev lists, I'm very hesitant about moving from 
mailing lists to discourse.  Why?


Well, the first and most basic is I'm worried about having core 
infrastructure out of our own control. For all their problems, 
mailing lists are widely supported, there are many 
vendors/contractors available. For discourse, as far as I can tell, 
there's one vendor. It's very much a take it or leave it situation.  
The ability to preserve discussion archives through a transition away 
from discourse someday concerns me.  I regularly and routinely need 
to dig back through llvm-dev threads which are years old.  I've also 
recently had some severely negative customer experiences with other 
tools (most recently discord), and the thought of having my 
employability and ability to contribute to open source tied to my 
ability to get a response from customer service teams at some third 
party vendor I have no leverage with, bluntly, scares me.


Second, I feel that we've overstated the difficulty of maintaining 
mailing lists.  I have to acknowledge that I have little first hand 
experience administering mailman, so maybe I'm way off here.



Hi Philip,

Hi Chris,


First, despite the similar names, Discord is very different than 
Discourse.  Here I’m only commenting about Discourse, I have no 
opinion about Discord.
I'm aware, thank you.  I'm sorry that my wording seems to have caused 
confusion on this point.



In this case, I think we need to highly weight the opinions of the 
people actively mainlining the existing systems.  It has become clear 
that the priority isn’t “control our own lists”, it is “make sure they 
stay up” and “get LLVM people out of maintaining them”.


The ongoing load of maintaining these lists (including moderation) and 
of dealing with the security issues that keep coming up are carried by 
several individuals, not by the entire community.  I’m concerned about 
those individuals, but I’m also more broadly concerned about *any* 
individuals being solely responsible for LLVM infra.  Effectively 
every case we’ve had where an individual has driving LLVM infra turns 
out to be a problem.  LLVM as a project isn’t good at running web 
scale infra, but we highly depend on it.


It seems clear to me that we should outsource this to a proven vendor.
I agree with everything you said up to here.  The goals make sense, and 
I fully support them.


Your concerns about discourse seem very similar to the discussion 
about moving to Github (being a single vendor who was once much 
smaller than Microsoft).  I think your concerns are best addressed by 
having the IWG propose an answer to “what is our plan if 
Discourse-the-company goes sideways?"


This is where I disagree.  The key point for me is that mailman3 exists 
and there are commercial vendors who specialize in exactly what we 
need.  I don't object at all to having a proven vendor.  I just don't 
see discourse as being the obvious choice.


Now, as I said in my first email, you don't actually need to convince me 
here.  If the move is made to discourse, I will follow.  At the end of 
the day, a decision does need to be made, and I'm willing to defer to 
those putting in the work.


Philip

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

Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing List Status Update

[Philip Reames via lldb-dev]

On 6/15/21 11:15 AM, Matt P. Dziubinski via llvm-dev wrote:

On 6/15/2021 19:41, David Blaikie wrote:

    When
    you open a page on https://llvm.discourse.group
     it doesn't load (or
    show) the entire thread on one page by default but instead
    progressively
    loads (and unloads) partial content as you scroll along.

Ah, yeah - which is why it hijacks the search shortcut to do a web 
form search rather than the browser builtin. Seems to work OK - I 
wouldn't count this as a major usability problem, at least for me.


Fair enough, there's always an element of subjectivity to UX, so YMMV. 
At the same time one issue with the aforementioned hijacking is that 
is not complete, either--e.g., it doesn't support built-in search 
features like "Find Next" or "Find Previous". For users used to 
keyboard navigation this is a usability problem (especially in 
development-oriented discussions, when searching for occurrences of 
identifiers in, say, LLVM IR does come in handy).


I want to highlight the accessibility point here.  I have fairly poor 
vision, and regularly consume content in modes which someone with 
perfect vision might not.  The ability to blow things up, search easily 
within a page, and otherwise consume content in a customizable manner 
*matters* to me.  I emphasize this because I feel the point often gets 
lost in tooling discussions.





    There's no such restriction in the Mailman web UI since it 
displays the

    entire thread on one page by default, even for longer threads, e.g.,
https://mail.python.org/archives/list/python-...@python.org/thread/JM6SQ2YNMDAKXYD5O54QWMVR2X7QOXVL/

    Loading the complete thread (displaying all messages) allows the
    built-in search to work without issues.

Great to see too - especially to see that it addresses an issue 
that's always pained me about our current mailman setup, where 
threads get split by week or month - so there's no nice way to link 
to a whole thread. I'll be happy to see that addressed in either/any 
way.


Agreed, I also see this as an improvement.

Best,
Matt
___
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] [llvm-dev] Mailing List Status Update

[Philip Reames via lldb-dev]

I have concerns about this proposal.  Those concerns aren't necessarily 
unaddressable, but I do want to share them.  My concerns fall into two 
broad categories.


The first category is the process one.  My understanding when the LLVM 
foundation was established was that the role of the foundation and the 
board was to support the community, not to make major decisions for the 
community.  I understand there is a degree of pragmatism we have to 
accept - e.g. sometimes the situation forces our hand, and we need to 
act, even if in a sub-optimal way - but this runs dangerously close to 
the edge of the board dictating the solution to the community.  I do 
want to acknowledge that I truly do thing everyone on the board is 
acting in good faith here.  I'm not so much worried about the intentions 
of anyone involved so much as the appearance and precedent this sets.


The second category is the proposed migration itself.  I'll start by 
saying that the restriction in the proposal text to the *-dev lists 
(explicitly excluding the *commits lists) does soften my concerns 
substantially, but I'm left wondering about the long term plan for the 
commit lists.  As has come up in recent threads around phabricator, I 
feel the commit lists play a critical role in our development practice 
and, almost more importantly, *culture* which is hard to replicate.   
I'm a bit worried that this proposal if accepted will be the camel 
getting his nose under the tent as it were.


Specific to the dev lists, I'm very hesitant about moving from mailing 
lists to discourse.  Why?


Well, the first and most basic is I'm worried about having core 
infrastructure out of our own control.  For all their problems, mailing 
lists are widely supported, there are many vendors/contractors 
available.  For discourse, as far as I can tell, there's one vendor.  
It's very much a take it or leave it situation.  The ability to preserve 
discussion archives through a transition away from discourse someday 
concerns me.  I regularly and routinely need to dig back through 
llvm-dev threads which are years old.  I've also recently had some 
severely negative customer experiences with other tools (most recently 
discord), and the thought of having my employability and ability to 
contribute to open source tied to my ability to get a response from 
customer service teams at some third party vendor I have no leverage 
with, bluntly, scares me.


Second, I feel that we've overstated the difficulty of maintaining 
mailing lists.  I have to acknowledge that I have little first hand 
experience administering mailman, so maybe I'm way off here.  However, 
there are multiple commercial vendors which provide mailman hosting.  
TBH, this seems like a case where the foundation should simply pay for 
commercial hosting and migration support to mailman3.  It may be this is 
a lot more expensive in practice than I'm imagining, but this feels like 
it should be our default answer and that anything else (i.e. discourse) 
should require major evidence of benefit over that default to be considered.


Third, I'm worried that there are culture elements very tied up in our 
current usage of the mailing lists.  As some specific examples, consider 
each of the following:


 * Discourse does not allow private responses via email.  You have to
   use their web interface.  I spent a lot of time replying privately
   to other contributors.  I'm worried that, in practice, the extra
   step will cause me to follow up less, and miss even more responses. 
   I'm particularly concerned about the impact for new contributors. 
   (Existing contributors, I probably have an email address for already.)
 * Discourses does not allow cross posts (or at least, it's not clear
   how to do so).  At least a couple times a year, we have design
   discussions which cross between sub-projects.  This can be addressed
   with a process change, but it needs some discussion before the
   migration happens.

It's not that we can't adjust our processes to the limitations of 
discourse; we clearly can.  My concern is all of the subtle things we 
loose along the way.


Now that I've finished up, let me explicitly state that I don't intend 
my comments here to be blocking.  I don't think this is a good idea, or 
at least needs further expansion before acceptance, but I'm also not in 
place where I can really invest in providing a realistic alternative.  
At the end of the day, pragmatism does require that we give discretion 
to the folks actually investing their own time, and energy to keep the 
community running.


Philip



On 6/1/21 1:50 PM, Tom Stellard via llvm-dev wrote:

Hi,

We recently[1] ran into some issues with the mailing lists that caused
us to disable automatic approval of subscriptions.  Over the past few
months, the LLVM Foundation Board of Directors have been investigating
solutions to this issue and are recommending that the project move its
discussion forum from mailman to Discourse[2]

Re: [lldb-dev] [llvm-dev] [RFC] Deprecate pre-commit email code reviews in favor of Phabricator

[Philip Reames via lldb-dev]

Seems reasonable to me.  I'm not strongly in favor, but since I was 
strongly opposed to the previous proposal, a "don't object" seemed 
reasonable to share.


Philip

On 5/17/21 11:12 AM, Krzysztof Parzyszek via llvm-dev wrote:


This is a revision of the previous RFC[1].  This RFC limits the scope 
to pre-commit reviews only.


*Statement:*

Our current code review policy states[2]:

“Code reviews are conducted, in order of preference, on our web-based 
code-review tool (see Code Reviews with Phabricator), by email on the 
relevant project’s commit mailing list, on the project’s development 
list, or on the bug tracker.”


This proposal is to limit pre-commit code reviews only to 
Phabricator.  This would apply to all projects in the LLVM monorepo.  
With the change in effect, the amended policy would read:


“Pre-commit code reviews are conducted on our web-based code-review 
tool (see Code Reviews with Phabricator).  Post-commit reviews are 
conducted, in order of preference, on Phabricator, by email on the 
relevant project’s commit mailing list, on the project’s development 
list, or on the bug tracker.”


*Current situation:*

 1. In a recent llvm-dev thread[3], Christian Kühnel pointed out that
pre-commit code reviews rarely originate via an email (most are
started on Phabricator), although, as others pointed out, email
responses to an ongoing review are not uncommon.  (That thread
also contains examples of mishaps related to the email-Phabricator
interactions, or email handling itself.)
 2. We have Phabricator patches that automatically apply email
comments to the Phabricator reviews, although reportedly this
functionality is not fully reliable[4,5].  This can cause review
comments to be lost in the email traffic.

*Benefits:*

 1. Single way of doing pre-commit code reviews: these code reviews
are a key part of the development process, and having one way of
performing them would make the process clearer and unambiguous.
 2. Review authors and reviewers would only need to monitor one source
of comments without the fear that a review comment may end up
overlooked.
 3. This changesimply codifies an existing practice.

*Concerns:*

 1. Because of the larger variety, email clients may offer better
accessibility options than web browsers.

[1] https://lists.llvm.org/pipermail/llvm-dev/2021-May/150344.html 



[2] 
https://llvm.org/docs/CodeReview.html#what-tools-are-used-for-code-review 



[3] https://lists.llvm.org/pipermail/llvm-dev/2021-April/150129.html 



[4] https://lists.llvm.org/pipermail/llvm-dev/2021-April/150136.html 



[5] https://lists.llvm.org/pipermail/llvm-dev/2021-April/150139.html 



--

Krzysztof Parzyszek kparz...@quicinc.com 
   AI tools development



___
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] [llvm-dev] [RFC] Deprecate email code reviews in favor of Phabricator

[Philip Reames via lldb-dev]

In my view, this email is really too different topics.  Given that, my 
response is split into two parts.


First, should we make phabricator our default for code review?  I am not 
opposed to this.  I don't particular support it either, but I would not 
spend time arguing against it.  I would suggest that we re-frame the 
proposal to distinguish precommit and post commit review - with only the 
former moving to phabricator.  I have not seen post-commit done 
successfully on phabricator to date in any wide spread manner.


Second, should we consider retiring llvm-commits and the other mailing 
lists?  My gut response is a flat out NO  What we have works.  I am 
highly reluctant to run the risk of breaking our existing processes - 
which for all their problems mostly work - for the, to me, seemingly 
very minimal value obtained by moving away from email discussion.  Post 
commit review in email works.  I strongly suspect that if you try to 
change that, you will either simply drive out post commit review 
discussion (bad idea!) or discussions will move to private email 
exchanges (bad idea!).  I'm open to being convinced here, but the burden 
of proof is high. The risk we'd be talking about with such a transition 
is immense.


Philip

On 5/3/2021 10:24 AM, Krzysztof Parzyszek via llvm-dev wrote:


*Statement:*

Our current code review policy states[1]:

“Code reviews are conducted, in order of preference, on our web-based 
code-review tool (see Code Reviews with Phabricator), by email on the 
relevant project’s commit mailing list, on the project’s development 
list, or on the bug tracker.”


This proposal is to limit code reviews only to Phabricator.  This 
would apply to all projects in the LLVM monorepo.  With the change in 
effect, the amended policy would read:


“Code reviews are conducted on our web-based code-review tool (see 
Code Reviews with Phabricator).”


*Current situation:*

 1. In a recent llvm-dev thread[2], Christian Kühnel pointed out that
pre-commit code reviews rarely originate via an email (most are
started on Phabricator), although, as others pointed out, email
responses to an ongoing review are not uncommon.  (That thread
also contains examples of mishaps related to the email-Phabricator
interactions, or email handling itself.)
 2. I don’t have specific information about post-commit reviews.  It
seems like the most common form is an email reply to the
auto-generated commit message, although (in my personal
experience), “raising a concern” in the commit on Phabricator or
commenting in the pre-commit review is usually sufficient to get
author’s attention.
 3. We have Phabricator patches that automatically apply email
comments to the Phabricator reviews, although reportedly this
functionality is not fully reliable[3,4].  This can cause review
comments to be lost in the email traffic.

*Benefits:*

 1. Single way of doing code reviews: code reviews are a key part of
the development process, and having one way of performing them
would make the process clearer and unambiguous.
 2. Review authors and reviewers would only need to monitor one source
of comments without the fear that a review comment may end up
overlooked.
 3. Local Phabricator extensions would no longer be needed.

*Concerns:*

 1. For post-commit reviews, the commenter would need to find either
the original review, or the Phabricator commit (e.g.
https://reviews.llvm.org/rG06234f758e19
). Those are communicated
(perhaps ironically) via email, which implies that those automatic
emails should remain in place.
 2. The current policy has been in place for a long time and it’s
expected that some people will continue using email for reviews
out of habit or due to lack of awareness of the policy change.
 3. Because of the larger variety, email clients may offer better
accessibility options than web browsers.

*Potential future direction:*

This section presents a potential future evolution of the review 
process.  Christian has conducted experiments suggesting that we can 
replace the XXX-commits mailing lists with notifications directly from 
Phabricator:


  * For each of the mailing lists, we create a "project" with the same
name in Phabricator, e.g. [5]. Every Phabricator user can
join/leave these projects on their own.
  * Everyone on these projects will receive the same email
notifications from Phabricator as we have on the mailing lists.
This is configured via "Herald" rules in Phabricator, as today,
e.g. [7].
  * Users can reply to these email notifications and Phabricator will
incorporate these responses with their email client, see [6] for
some example emails. Quoting and markup is supported as well.
  * We do NOT migrate the membership lists. Users need to sign up to
the projects manually. We will send an email with instructions to
the maili

Re: [lldb-dev] [llvm-dev] RFC: Release process changes

[Philip Reames via lldb-dev]

All of this sounds reasonable to me, but we don't directly follow the 
upstream release cadence so I'm an interested observer at most.


Philip

On 5/21/20 11:59 AM, Tom Stellard via llvm-dev wrote:

Hi,

I would like to propose a few changes to the LLVM release process.  The
current process is documented here:  https://llvm.org/docs/HowToReleaseLLVM.html

There are two parts to this proposal.  The first is a list of clarifications,
which are things we are currently doing that aren't documented. The second
is a list of changes which would actually modify how releases are currently
managed.



*** Proposed Clarifications ***



**  Release manager is allowed to commit changes to the release branch without
 code owner approval.  However, the release manager is encouraged to consult
 with code owners or patch reviewers for non-trivial changes.

It's not practical to get code owner approval every time.  Either because there
is no code owner or because the number of backports is too high (e.g. pre-rc1 / 
pre-rc2).
This proposed clarification matches how releases are currently managed.


** There is no official release criteria.

We have time-based releases and when the release is 'ready' has been
up to the discretion of the release manager.  Changing the release
criteria is out of the scope of this proposal, but I do think it would
be good to have a discussion about this as a community, so I'm going to
start a separate thread to discuss this.



*** Proposed Changes ***



** Create a time-based bug-fix release schedule.  After each major release, make
a new bug-fix release every 2 weeks for 12 weeks (6 releases total).

** Eliminate release candidates for bug-fix releases.

The current unofficial bug-fix release schedule is:

X.Y.1-rc1 (6 weeks after major release)
X.Y.1-rc2 (10 weeks after major release)
X.Y.1-final (12 weeks after major release)

I think this change will improve the overall test coverage of the release 
branch.
I don't think the branch itself or even the release candidates get the same
level of testing as the final releases.  If we are consistently snapshotting
the release branch and putting out releases, I think this will make it easier
and thus more likely that users will test out the release branch code.

Additionally, with more frequent bug-fix release it removes the need to have
release candidate releases. Every bug-fix release (up until the last one)
would serve the same purpose as our current release candidates in that they
are intended to give users an easier way to test the code before the final
release.


** Create clear rules for what kind of backports are accepted during each
release phase.

* Before RC1:Patches should be limited to bug fixes, important optimization
   improvements, or completion of features that were started before the branch
   was created.  As with all phases, release managers and code owners can reject
   patches that are deemed too invasive.

* Before RC2: Patches should be limited to bug fixes or backend specific
   improvements that are determined to be very safe.

* Before RC3/Final: Major Release* Patches should be limited to critical
   bugs or regressions.
  
* Bug fix releases: Patches should be limited to bug fixes or very safe

   and critical performance improvements.  Patches must maintain both API and
   ABI compatibility with the previous major release.
  
* Final bug fix release: Patches should be limited to critical bug fixes only.




What does everyone thing about these changes?


-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] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Philip Reames via lldb-dev]

On 4/25/20 10:02 PM, Mehdi AMINI via cfe-dev wrote:



On Fri, Apr 24, 2020 at 12:04 PM Tom Stellard via llvm-dev 
mailto:llvm-...@lists.llvm.org>> wrote:


On 04/24/2020 03:24 AM, Sam McCall wrote:
> clangd's experience using github issues to track bugs (in a
separate repo) has been very positive, and I'm glad you're pushing
on this!
>
> Part of this has been that our issue tracker has been scoped to
our subproject only, which is a scope that the tool works well for
(on the user and developer side).
> As such I don't think we should migrate clangd to a using the
monorepo bugtracker. Email subscription to a label is better than
nothing, but worse than a separate repo.
> Removing the clangd label from the monorepo bugtracker seems
like the simplest thing, though I'm happy to work on auto-moving
bugs if that's better.
>
> (I'd suggest considering the same for other subprojects, though
I know that's not a popular opinion here)

I think it's important for everything in the monorepo to use the
same bug tracker.

There are advantages to having code in the monorepo (e.g. free
updates for API changes, a more consistent build experience, etc.).
But there are also costs, as you have pointed out, like having to use
a less than ideal bug tracker.  It's really up to sub-projects
to make the decision about whether these benefits are worth the costs.
The flang developers have just gone through this process and have
had to make some sacrifices to get the code in, but ultimately
felt the
sacrifices were worth it. 



I think it hurts the ability of developers and users to
collaborate effectively,
if the infrastructure for the project is spread across too many
different places.
And good collaboration is key for a project of this size with some
many tightly
connected components.


+1: seems like clangd here is trying a "in-between" approach in being 
halfway into a LLVM project. It was something that was strongly pushed 
back against multiple times during the discussions on Flang 
integration, it isn't clear to me why we'd get into a different 
approach with clangd. I am really in favor of keeping a cohesion in 
the project and not having a "graph of somehow disconnected projects". 
There might be sub-optimality sometimes, but we should address them 
for everyone instead of one-off improvements that may benefit one 
subproject on the short term but I suspect hurt the project on the 
long term.

+1.  Agreed w/Mehdi.


--
Mehdi


Getting back to the proposal we are discussing.  Do you have any
specific feedback
for improvements that might help make it align better with the
kind of experience
the clangd users and developers are looking for?

- Tom





___
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
___
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] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Philip Reames via lldb-dev]

On 4/22/20 2:35 PM, Richard Smith wrote:
On Wed, 22 Apr 2020 at 09:45, Philip Reames via cfe-dev 
mailto:cfe-...@lists.llvm.org>> wrote:


On 4/21/20 6:50 PM, Richard Smith wrote:


On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev
mailto:llvm-...@lists.llvm.org>> wrote:

On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote:
> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev
mailto:cfe-...@lists.llvm.org>
>> wrote:
>
>     +1 to James's take
>
>     I'd prefer simplicity of implementation over perfection
here.
>
> If we end up with two different bug numbering systems,
that's a problem that we will be paying for for many years.
It's worth some investment now to avoid that problem. And it
doesn't seem like it really requires much investment.
>
> Here's another path we could take:
>
> 1) Fork the llvm repository to a private "bugs" repository.
Mirror the bugzilla issues there. Iterate until we're happy,
as per James's proposal.
> 2) Sync the forked repository to the llvm repository,
delete the llvm repository, rename "bugs" to "llvm", and make
it public.
>
> Then we'll have the first N bugs in llvm-project/llvm being
*exactly* the bugzilla bugs, and we'll have excised the
existing github issues that we want to pretend never existed
anyway.
>
>
> I think we've missed an important step in the planning
here: we've not agreed on a set of goals for the transition.
Here are mine:
>
>  * We end up with one single issue tracking system
containing all issues, both old and new, both open and closed.
>  * All links and references to existing bugs still work.
>  * We have a single bug numbering system covering all bugs,
and old bugs retain their numbers.

Why are the bug numbers important?


These numbers appear all over our codebase. PR[0-9] appears 3592
times in Clang testcases, plus 45 times in Clang source code and
119 times more as the file names of Clang testcases. If we add
inconvenience to looking up all of those, that makes maintenance
harder each time someone wants to look one of those up. (That's
probably a ~weekly occurrence for me.)


For this use case, a simple script and bulk change to update
references in source repo means the numbering can change
arbitrarily.  ~4k small mechanical changes is just not that much
to review for a one time update assuming you trust the number
remapping script and are just looking for overly aggressive regex
matches.

It's not quite as straightforward as you're suggesting: such a simple 
script would break a bunch of our CodeGen tests that match mangled 
names, if the length of any bug identifier changes. A grep for 
'_Z.*PR[0-9]' indicates that there are at least 254 of those that 
might need manual updating if we took this path.
We have an auto-updater for most llc scripts, but point taken.  My main 
point was this was one time, not that the one time was trivial.


(I don't have any quick fixes for your other mentioned cases.)

Another case I didn't think of before, but that seems very important: 
bug numbers appear in commit messages, and are primary context in 
understanding what the commit is doing and why. [We *could* go on a 
bulk history editing spree to fix those commit messages up (git 
filter-branch actually makes this fairly easy) -- but that too would 
create a little churn as everyone would needs to rebase all their work 
in progress on the rewritten master, and honestly, that sounds a lot 
scarier than any of the other things we've considered in this thread :)]
Agreed, history rewrite as a solution here should be rejected out of 
hand.  :)



Also, bug numbers appear in other bugs. I would assume we're not
going to be able to reliably figure out which numbers appearing
in a bug are bug numbers during the import process, so those
numbers will persist into the github issues world.

(In addition, I'm sure multiple groups have their own tracking
systems, web pages, documentation, etc. that contain references
to LLVM PR numbers. But maybe we shouldn't worry too much about
that.)

Could you help give some example use cases that require having
a non-intersecting set of bug numbers for bugzilla bugs and
github issues?


It makes conversing about bug numbers more difficult if you need
to clarify which system you're talking about. As a minor example,
we'd have to avoid saying "PR" for the new system in order to
avoid confusion, and get used to some new terminology, and
probably not use "bug 1234" to describe either system, because
  

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Philip Reames via lldb-dev]

On 4/21/20 6:50 PM, Richard Smith wrote:
On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev 
mailto:llvm-...@lists.llvm.org>> wrote:


On 04/21/2020 03:36 PM, Richard Smith via llvm-dev wrote:
> On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev
mailto:cfe-...@lists.llvm.org>
>>
wrote:
>
>     +1 to James's take
>
>     I'd prefer simplicity of implementation over perfection here.
>
> If we end up with two different bug numbering systems, that's a
problem that we will be paying for for many years. It's worth some
investment now to avoid that problem. And it doesn't seem like it
really requires much investment.
>
> Here's another path we could take:
>
> 1) Fork the llvm repository to a private "bugs" repository.
Mirror the bugzilla issues there. Iterate until we're happy, as
per James's proposal.
> 2) Sync the forked repository to the llvm repository, delete the
llvm repository, rename "bugs" to "llvm", and make it public.
>
> Then we'll have the first N bugs in llvm-project/llvm being
*exactly* the bugzilla bugs, and we'll have excised the existing
github issues that we want to pretend never existed anyway.
>
>
> I think we've missed an important step in the planning here:
we've not agreed on a set of goals for the transition. Here are mine:
>
>  * We end up with one single issue tracking system containing
all issues, both old and new, both open and closed.
>  * All links and references to existing bugs still work.
>  * We have a single bug numbering system covering all bugs, and
old bugs retain their numbers.

Why are the bug numbers important?


These numbers appear all over our codebase. PR[0-9] appears 3592 times 
in Clang testcases, plus 45 times in Clang source code and 119 times 
more as the file names of Clang testcases. If we add inconvenience to 
looking up all of those, that makes maintenance harder each time 
someone wants to look one of those up. (That's probably a ~weekly 
occurrence for me.)


For this use case, a simple script and bulk change to update references 
in source repo means the numbering can change arbitrarily.  ~4k small 
mechanical changes is just not that much to review for a one time update 
assuming you trust the number remapping script and are just looking for 
overly aggressive regex matches.


(I don't have any quick fixes for your other mentioned cases.)



Also, bug numbers appear in other bugs. I would assume we're not going 
to be able to reliably figure out which numbers appearing in a bug are 
bug numbers during the import process, so those numbers will persist 
into the github issues world.


(In addition, I'm sure multiple groups have their own tracking 
systems, web pages, documentation, etc. that contain references to 
LLVM PR numbers. But maybe we shouldn't worry too much about that.)


Could you help give some example use cases that require having
a non-intersecting set of bug numbers for bugzilla bugs and github
issues?


It makes conversing about bug numbers more difficult if you need to 
clarify which system you're talking about. As a minor example, we'd 
have to avoid saying "PR" for the new system in order to avoid 
confusion, and get used to some new terminology, and probably not use 
"bug 1234" to describe either system, because that would be ambiguous. 
None of these individual factors seems like a huge disruption, but 
they all seem like inconvenience we should prefer to avoid if possible.


-Tom


>
> It sounds like we don't all agree that the last point is
important, but if we can achieve it without any significant
additional cost, why not do so?
>
>     Philip
>
>     On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote:
>>     In a previous discussion, one other suggestion had been to
migrate all the bugzilla bugs to a separate initially-private "bug
archive" repository in github. This has a few benefits:
>>     1. If the migration is messed up, the repo can be deleted,
and the process run again, until we get a result we like.
>>     2. The numbering can be fully-controlled.
>>     Once the bugs are migrated to /some/ github repository,
individual issues can then be "moved" between repositories, and
github will redirect from the movefrom-repository's bug to the
target repository's bug.
>>
>>     We could also just have llvm.org/PR###
  be the url
only for legacy bugzilla issue numbers -- and have it use a file
listing the mappings of bugzilla id -> github id to generate the
redirects. (GCC just did this recently for svn revision number
redirections,
https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html).
>>
>>     Then we could introduce a new nam

Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Philip Reames via lldb-dev]

On 4/21/20 3:36 PM, Richard Smith wrote:
On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev 
mailto:cfe-...@lists.llvm.org>> wrote:


+1 to James's take

I'd prefer simplicity of implementation over perfection here.

If we end up with two different bug numbering systems, that's a 
problem that we will be paying for for many years. It's worth some 
investment now to avoid that problem. And it doesn't seem like it 
really requires much investment.


I used to think this was super important, but I've now been through a 
couple of conversions which didn't provide a 1-to-1 mapping.  It's 
annoying for about 6 months, and after that, you basically forget it 
happened.  As long as old bugs are searchable in the new system, and you 
can find the new ID from the old system, the exact identifier isn't as 
important.


Anyways, this is all subjective and I'm certainty not volunteering to 
work on this, so IMHO my own opinion doesn't really count.  :)





Here's another path we could take:

1) Fork the llvm repository to a private "bugs" repository. Mirror the 
bugzilla issues there. Iterate until we're happy, as per James's proposal.
2) Sync the forked repository to the llvm repository, delete the llvm 
repository, rename "bugs" to "llvm", and make it public.


Then we'll have the first N bugs in llvm-project/llvm being *exactly* 
the bugzilla bugs, and we'll have excised the existing github issues 
that we want to pretend never existed anyway.



I think we've missed an important step in the planning here: we've not 
agreed on a set of goals for the transition. Here are mine:


 * We end up with one single issue tracking system containing all 
issues, both old and new, both open and closed.

 * All links and references to existing bugs still work.
 * We have a single bug numbering system covering all bugs, and old 
bugs retain their numbers.


It sounds like we don't all agree that the last point is important, 
but if we can achieve it without any significant additional cost, why 
not do so?


Philip

On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote:

In a previous discussion, one other suggestion had been to
migrate all the bugzilla bugs to a separate initially-private
"bug archive" repository in github. This has a few benefits:
1. If the migration is messed up, the repo can be deleted, and
the process run again, until we get a result we like.
2. The numbering can be fully-controlled.
Once the bugs are migrated to /some/ github repository,
individual issues can then be "moved" between repositories, and
github will redirect from the movefrom-repository's bug to the
target repository's bug.

We could also just have llvm.org/PR###
 be the url only for legacy bugzilla
issue numbers -- and have it use a file listing the mappings of
bugzilla id -> github id to generate the redirects. (GCC just did
this recently for svn revision number redirections,
https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html).

Then we could introduce a new naming scheme for github issue
shortlinks.

On Mon, Apr 20, 2020 at 3:50 PM Richard Smith via llvm-dev
mailto:llvm-...@lists.llvm.org>> wrote:

On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev
mailto:llvm-...@lists.llvm.org>> wrote:

Hi,

I wanted to continue discussing the plan to migrate from
Bugzilla to Github.
It was suggested that I start a new thread and give a
summary of the proposal
and what has changed since it was originally proposed in
October.

== Here is the original proposal:

http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html

== What has changed:

* You will be able to subscribe to notifications for a
specific issue
  labels.  We have a proof of concept notification system
using github actions
  that will be used for this.

* Emails will be sent to llvm-bugs when issues are opened
or closed.

* We have the initial list of labels:
https://github.com/llvm/llvm-project/labels

== Remaining issue:

* There is one remaining issue that I don't feel we have
consensus on,
and that is what to do with bugs in the existing
bugzilla.  Here are some options
that we have discussed:

1. Switch to GitHub issues for new bugs only. Bugs filed
in bugzilla that are
still active will be updated there until they are
closed.  This means that over
time the number of active bugs in bugzilla will slowly
decrease as bugs are closed
out.  Then at some point in the future, all of the bugs
from bugzilla will be archived
into their 

Re: [lldb-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

[Philip Reames via lldb-dev]

+1 to James's take

I'd prefer simplicity of implementation over perfection here.

Philip

On 4/20/20 4:08 PM, James Y Knight via llvm-dev wrote:
In a previous discussion, one other suggestion had been to migrate all 
the bugzilla bugs to a separate initially-private "bug archive" 
repository in github. This has a few benefits:
1. If the migration is messed up, the repo can be deleted, and the 
process run again, until we get a result we like.

2. The numbering can be fully-controlled.
Once the bugs are migrated to /some/ github repository, individual 
issues can then be "moved" between repositories, and github will 
redirect from the movefrom-repository's bug to the target repository's 
bug.


We could also just have llvm.org/PR###  be the 
url only for legacy bugzilla issue numbers -- and have it use a file 
listing the mappings of bugzilla id -> github id to generate the 
redirects. (GCC just did this recently for svn revision number 
redirections, https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html).


Then we could introduce a new naming scheme for github issue shortlinks.

On Mon, Apr 20, 2020 at 3:50 PM Richard Smith via llvm-dev 
mailto:llvm-...@lists.llvm.org>> wrote:


On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev
mailto:llvm-...@lists.llvm.org>> wrote:

Hi,

I wanted to continue discussing the plan to migrate from
Bugzilla to Github.
It was suggested that I start a new thread and give a summary
of the proposal
and what has changed since it was originally proposed in October.

== Here is the original proposal:

http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html

== What has changed:

* You will be able to subscribe to notifications for a
specific issue
  labels.  We have a proof of concept notification system
using github actions
  that will be used for this.

* Emails will be sent to llvm-bugs when issues are opened or
closed.

* We have the initial list of labels:
https://github.com/llvm/llvm-project/labels

== Remaining issue:

* There is one remaining issue that I don't feel we have
consensus on,
and that is what to do with bugs in the existing bugzilla. 
Here are some options
that we have discussed:

1. Switch to GitHub issues for new bugs only.  Bugs filed in
bugzilla that are
still active will be updated there until they are closed. 
This means that over
time the number of active bugs in bugzilla will slowly
decrease as bugs are closed
out.  Then at some point in the future, all of the bugs from
bugzilla will be archived
into their own GitHub repository that is separate from the
llvm-project repo.

2. Same as 1, but also create a migration script that would
allow anyone to
manually migrate an active bug from bugzilla to a GitHub issue
in the llvm-project
repo.  The intention with this script is that it would be used
to migrate high-traffic
or important bugs from bugzilla to GitHub to help increase the
visibility of the bug.
This would not be used for mass migration of all the bugs.

3. Do a mass bug migration from bugzilla to GitHub and enable
GitHub issues at the same time.
Closed or inactive bugs would be archived into their own
GitHub repository, and active bugs
would be migrated to the llvm-project repo.


Can we preserve the existing bug numbers if we migrate this way?
There are lots of references to "PRx" in checked in LLVM
artifacts and elsewhere in the world, as well as links to
llvm.org/PRx , and if we can preserve
all the issue numbers this would ease the transition pain
substantially.

The key difference between proposal 1,2 and 3, is when bugs
will be archived from bugzilla
to GitHub.  Delaying the archiving of bugs (proposals 1 and 2)
means that we can migrate
to GitHub issues sooner (within 1-2 weeks), whereas trying to
archive bugs during the
transition (proposal 3) will delay the transition for a while
(likely several months)
while we evaluate the various solutions for moving bugs from
bugzilla to GitHub.


The original proposal was to do 1 or 2, however there were
some concerns raised on the list
that having 2 different places to search for bugs for some
period of time would
be very inconvenient.  So, I would like to restart this
discussion and hopefully we can
come to some kind of conclusion about the best way forward.

Thanks,
Tom

___
LLVM Developers mailing list
 

Re: [lldb-dev] [cfe-dev] RFC: Using GitHub Actions for CI testing on the release/* branches

[Philip Reames via lldb-dev]

+1, I'll be really curious to know how this works out.

Philip

On 11/11/19 4:32 PM, Tom Stellard via cfe-dev wrote:
> Hi,
>
> I would like to start using GitHub Actions[1] for CI testing on the release/*
> branches.  As far as I know we don't have any buildbots listening to the
> release branches, and I think GitHub Actions are a good way for us to quickly
> bring-up some CI jobs there.
>
> My proposal is to start by adding two post-commit CI jobs to the release/9.x 
> branch.
> One for building and testing (ninja checka-all) llvm/clang/lld on Linux,
> Windows, and Mac, and another for detecting ABI changes since the 9.0.0 
> release.
>
> I have already implemented these two CI jobs in my llvm-project fork on 
> GitHub[2][3],
> but in order to get these running in the main repository, I would need to:
>
> 1. Create a new repository in the LLVM organization called 'actions' for 
> storing some custom
> builds steps for our CI jobs (see [4]).
> 2. Commit yaml CI definitions to the .github/workflows directory in the 
> release/9.x
> branch.
>
> In the future, I would also like to add buil and tests jobs for other 
> sub-projects
> once I am able to get those working.
>
> In addition to being used for post-commit testing, having these CI 
> definitions in the
> main tree will make it easier for me (or anyone) to do pre-commit testing for 
> the
> release branch in a personal fork.  It will also allow me to experiment with 
> some new
> workflows to help make managing the releases much easier.
>
> I think this will be a good way to test Actions in a low traffic environment 
> to
> see if they are something we would want to use for CI on the master branch.
>
> Given that we are close to the end of the 9.0.1 cycle, unless there are any
> strong objections, I would like to get this enabled by Mon Nov 18, to 
> maximize its
> usefulness.  Let me know what you think.
>
> Thanks,
> Tom
>
> [1] https://github.com/features/actions
> [2] 
> https://github.com/tstellar/llvm-project/commit/952d80e8509ecc95797b2ddbf1af40abad2dcf4e/checks?check_suite_id=305765621
> [3] 
> https://github.com/tstellar/llvm-project/commit/6d74f1b81632ef081dffa1e0c0434f47d4954423/checks?check_suite_id=303074176
> [4] https://github.com/tstellar/actions
>
> ___
> 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] RFC: End-to-end testing

[Philip Reames via lldb-dev]

On 10/9/19 6:25 PM, David Greene wrote:

Philip Reames via cfe-dev  writes:


A challenge we already have - as in, I've broken these tests and had to
fix them - is that an end to end test which checks either IR or assembly
ends up being extraordinarily fragile.  Completely unrelated profitable
transforms create small differences which cause spurious test failures.
This is a very real issue today with the few end-to-end clang tests we
have, and I am extremely hesitant to expand those tests without giving
this workflow problem serious thought.  If we don't, this could bring
development on middle end transforms to a complete stop.  (Not kidding.)

Do you have a pointer to these tests?  We literally have tens of
thousands of end-to-end tests downstream and while some are fragile, the
vast majority are not.  A test that, for example, checks the entire
generated asm for a match is indeed very fragile.  A test that checks
whether a specific instruction/mnemonic was emitted is generally not, at
least in my experience.  End-to-end tests require some care in
construction.  I don't think update_llc_test_checks.py-type operation is
desirable.
The couple I remember off hand were mostly vectorization tests, but it's 
been a while, so I might be misremembering.


Still, you raise a valid point and I think present some good options
below.


A couple of approaches we could consider:

  1. Simply restrict end to end tests to crash/assert cases.  (i.e. no
 property of the generated code is checked, other than that it is
 generated)  This isn't as restrictive as it sounds when combined
 w/coverage guided fuzzer corpuses.

I would be pretty hesitant to do this but I'd like to hear more about
how you see this working with coverage/fuzzing.
We've found end-to-end fuzzing from Java (which guarantees single 
threaded determinism and lack of UB) comparing two implementations to be 
extremely effective at catching regressions.  A big chunk of the 
regressions are assertion failures.  Our ability to detect miscompiles 
by comparing the output of two implementations (well, 2 or more for tie 
breaking purposes) has worked extremely well. However, once a problem is 
identified, we're stuck manually reducing and reacting, which is a very 
major time sink.  Key thing here in the context of this discussion is 
that there are no IR checks of any form, we just check the end-to-end 
correctness of the system and then reduce from there.



  2. Auto-update all diffs, but report them to a human user for
 inspection.  This ends up meaning that tests never "fail" per se,
 but that individuals who have expressed interest in particular tests
 get an automated notification and a chance to respond on list with a
 reduced example.

That's certainly workable.


  3. As a variant on the former, don't auto-update tests, but only inform
 the *contributor* of an end-to-end test of a failure. Responsibility
 for determining failure vs false positive lies solely with them, and
 normal channels are used to report a failure after it has been
 confirmed/analyzed/explained.

I think I like this best of the three but it raises the question of what
happens when the contributor is no longer contributing.  Who's
responsible for the test?  Maybe it just sits there until someone else
claims it.
I'd argue it should be deleted if no one is willing to actively step 
up.  It is not in the community's interest to assume unending 
responsibility for any third party test suite given the high burden 
involved here.



I really think this is a problem we need to have thought through and
found a workable solution before end-to-end testing as proposed becomes
a practically workable option.

Noted.  I'm very happy to have this discussion and work the problem.

  -David

___
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] How soon after the GitHub migration should committing with git-llvm become optional?

[Philip Reames via lldb-dev]

I'm also a strong proponent of not requiring the wrapper.

The linear history piece was important enough to make the cost worth 
it.  The extra branches piece really isn't.  If someone creates a branch 
that's not supposed to exist, we just delete it. No big deal.  It will 
happen, but the cost is so low I don't worry about it.


There's a bunch of things in our developer policy we don't enforce 
except through social means.  I don't see any reason why the "no 
branches" thing needs to be special.


If we really want some automation, a simple script that polls for new 
branches every five minutes and deletes them unless on a while list 
would work just fine.  :)


Philip

On 10/15/19 9:26 PM, Mehdi AMINI via cfe-dev wrote:



On Tue, Oct 15, 2019 at 12:26 PM Hubert Tong via llvm-dev 
mailto:llvm-...@lists.llvm.org>> wrote:


On Tue, Oct 15, 2019 at 3:47 AM Marcus Johnson via llvm-dev
mailto:llvm-...@lists.llvm.org>> wrote:

I say retire it instantly.

+1. It has never been a real requirement to use the script. Using
native svn is still viable until the point of the migration.


It was a requirement for the "linear history" feature. With GitHub 
providing this now, I'm also +1 on retiring the tool unless there is a 
another use that can be articulated for it?


--
Mehdi


> On Oct 15, 2019, at 3:14 AM, Tom Stellard via cfe-dev
mailto:cfe-...@lists.llvm.org>> wrote:
>
> Hi,
>
> I mentioned this in my email last week, but I wanted to
start a new
> thread to get everyone's input on what to do about the
git-llvm script
> after the GitHub migration.
>
> The original plan was to require the use of the git-llvm
script when
> committing to GitHub even after the migration was complete.
> The reason we decided to do this was so that we could
prevent developers
> from accidentally pushing merge commits and making the
history non-linear.
>
> Just in the last week, the GitHub team completed the
"Require Linear
> History" branch protection, which means we can now enforce
linear
> history server side and do not need the git-llvm script to
do this.
>
> With this new development, the question I have is when
should the
> git-llvm script become optional?  Should we make it optional
immediately,
> so that developers can push directly using vanilla git from
day 1, or should we
> wait a few weeks/months until things have stabilized to make
it optional?
>
> Thanks,
> Tom
>
>
>
>
>
> ___
> cfe-dev mailing list
> cfe-...@lists.llvm.org 
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
___
LLVM Developers mailing list
llvm-...@lists.llvm.org 
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

___
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
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Re: [lldb-dev] [llvm-dev] [cfe-dev] Mailing list changes this week

[Philip Reames via lldb-dev]

On 10/16/19 5:51 PM, Mehdi AMINI via llvm-dev wrote:



On Wed, Oct 16, 2019 at 5:46 PM Tom Stellard > wrote:


On 10/16/2019 07:23 AM, Robinson, Paul wrote:
> +1.  And put it in the email (subject?).  While it’s possible to
derive a count from a hash manually, better to have it in the
email in the first place.  You can’t rely on
order-of-email-delivery to reflect order-of-commit.
>

I spent some time today looking into what it would take to add the
commit
number into the email.  Implementing this will add some extra
complexity to the
emailer script and add another point of failure for us. We also
can't guarantee to always have it since at some point we may want
to start using
github's standard commit emails.

I think we should just wait and see how things go without having
a commit number in the email.  It's easy to generate the number
locally from a git hash if needed.  If it becomes a major
inconvenience
to not have it in the email, we can always look at adding it in later.


Having to get an up-to-date local clone and run commands to be able to 
reason about the logical relationship between commits (does this build 
failure email from a slow bot comes from before or after I landed my 
revert?) seems to me like a non-trivial workflow regression. I would 
personally be OK to increase the tooling complexity to preserve this.
+1 on this, but it's worth clarifying this is definitely not a blocker.  
Just a nice to have which can easily be done after the switch if needed.


The best way to prove or disprove this is likely do what you suggest 
though, and live through this for some time :)


--
Mehdi




-Tom

> --paulr
>
>
>
> *From:* llvm-dev mailto:llvm-dev-boun...@lists.llvm.org>> *On Behalf Of *Shoaib
Meenai via llvm-dev
> *Sent:* Wednesday, October 16, 2019 1:42 AM
> *To:* tstel...@redhat.com ; Mehdi
AMINI mailto:joker@gmail.com>>
> *Cc:* llvm-dev mailto:llvm-...@lists.llvm.org>>; cfe-dev mailto:cfe-...@lists.llvm.org>>; openmp-dev
(openmp-...@lists.llvm.org )
mailto:openmp-...@lists.llvm.org>>;
LLDB Dev mailto:lldb-dev@lists.llvm.org>>
> *Subject:* Re: [llvm-dev] [cfe-dev] Mailing list changes this week
>
>
>
> I thought we were just going to count commits on a particular
branch and use the (branch name, commit count) tuple as our
monotonic incrementing identifier?

https://llvm.org/docs/Proposals/GitHubMove.html#on-managing-revision-numbers-with-git
>
>
>
>
>
> *From: *cfe-dev mailto:cfe-dev-boun...@lists.llvm.org>
>> on behalf of cfe-dev
mailto:cfe-...@lists.llvm.org>
>>
> *Organization: *Red Hat
> *Reply-To: *"tstel...@redhat.com 
>"
mailto:tstel...@redhat.com>
>>
> *Date: *Tuesday, October 15, 2019 at 10:13 PM
> *To: *Mehdi AMINI mailto:joker@gmail.com> >>
> *Cc: *llvm-dev mailto:llvm-...@lists.llvm.org> >>, cfe-dev
mailto:cfe-...@lists.llvm.org>
>>,
"openmp-dev (openmp-...@lists.llvm.org

>)" mailto:openmp-...@lists.llvm.org>
>>, LLDB Dev
mailto:lldb-dev@lists.llvm.org>
>>
> *Subject: *Re: [cfe-dev] Mailing list changes this week
>
>
>
> On 10/15/2019 09:44 PM, Mehdi AMINI wrote:
>
>     On Tue, Oct 15, 2019 at 9:33 PM Tom Stellard
mailto:tstel...@redhat.com>
>
>
%3e>> wrote:
>
>          On 10/15/2019 09:24 PM, Mehdi AMINI wrote:
>
>          > Hi Tom.
>
>          >
>
>          > One issue with this is that we don't have a clear
"ordering" from linear revision numbers from these emails. Have we
looked into continuing to generate our own emails per commits
instead so that we control the format?
>
>          >
>
>          This actually what we are doing, we are listening for
github commit events and
>
>          then generating our own emails based on the da

Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: End-to-end testing

[Philip Reames via lldb-dev]

+1 to the points made here.  Renato very nicely explained the tradeoffs 
involved.


On 10/10/19 3:29 PM, Renato Golin via llvm-dev wrote:

On Thu, 10 Oct 2019 at 22:26, David Greene  wrote:

That would be a shame.  Where is test-suite run right now?  Are there
bots?  How are regressions reported?

There is no shame in making the test-suite better.

We do have bots running them in full CI for multiple targets, yes.
Regressions are reported and fixed. The benchmarks are also followed
by a smaller crowd and regression on those are also fixed (but
slower).

I'm not proposing to move e2e off to a dark corner, I'm proposing to
have a scaled testing strategy that can ramp up and down as needed,
without upsetting the delicate CI and developer balance.

Sure, e2e tests are important, but they need to catch bugs that the
other tests don't catch, not being our front-line safety net.

We planned doing incremental testing with buildbots for years and
Apple has done something like that in their GreenBots. We have talked
to move that upstream, but time spent in testing is really really
scant.

A few years back there was a big effort to clean up the LIT tests from
duplicates and speed up inefficient code, and a lot of tests are
removed. If we just add the e2e today and they never catch anything
relevant, they'll be the next candidates to go.

The delta that e2e can test is really important, but really small and
fairly rare. So running it less frequent (every few dozen commits)
will most likely be enough for anything we can possibly respond to
upstream.

My main point is that we need to be realistic with what we can do
upstream, which is very different from which a big company can do
downstream.

Past experiences have, over and over, shown us that new shiny CI toys
get rusty, noisy, and dumped.

We want to have the tests, in a place anyone can test, that the bots
*will* test periodically, and that don't annoy developers often enough
to be a target.

In a nutshell:
  * We still need src2src tests, to ensure connection points (mainly
IR) are canonical and generic, avoiding hidden contracts
  * We want the end2end tests to *add* coverage, not overlap with or
replace existing tests
  * We don't want those tests to become a burden to developers by
breaking on unrelated changes and making bots red for obscure reasons
  * We don't want them to be a burden to our CI efforts, slowing down
regular LIT testing and becoming a target for removal

The orders of magnitude for number of commits we want to run tests are:
  * LIT base, linker, compiler-RT, etc: ~1
  * Test-suite correctness, end-2-end: ~10
  * Multi-stage build, benchmarks: ~100

We already have that ratio (somewhat) with buildbots, so it should be
simple to add e2e to the test suite at the right scale.


The last thing we want is to create direct paths from front-ends to
back-ends and make LLVM IR transformation less flexible.

I'm not sure I follow.  Can you explain this a bit?

Right, I had written a long paragraph about it but deleted in the
final version of my email. :)

The main point is that we want to avoid hidden contracts between the
front-end and the back-end.

We want to make sure all front-ends can produce canonical IR, and that
the middle-end can optimise the IR and that the back-end can lower
that to asm in a way that runs correctly on the target. As we have
multiple back-ends and are soon to have a second official front-end,
we want to make sure we have good coverage on the multi-step tests
(AST to IR, IR to asm, etc).

If we add e2e tests that are not covered by piece-wise tests, we risk
losing that clarity.

I think e2e tests have to expose more complex issues, like front-end
changes, pass manager order, optimisation levels, linking issues, etc.
They can check for asm, run on the target, or both. In the test-suite
we have more budget to do a more complete job at it than in LIT
check-all.

Hope this helps.

cheers,
--renato
___
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] [llvm-dev] RFC: End-to-end testing

[Philip Reames via lldb-dev]

On 10/8/19 9:49 AM, David Greene via llvm-dev wrote:

[ I am initially copying only a few lists since they seem like
   the most impacted projects and I didn't want to spam all the mailing
   lists.  Please let me know if other lists should be included. ]

I submitted D68230 for review but this is not about that patch per se.
The patch allows update_cc_test_checks.py to process tests that should
check target asm rather than LLVM IR.  We use this facility downstream
for our end-to-end tests.  It strikes me that it might be useful for
upstream to do similar end-to-end testing.

Now that the monorepo is about to become the canonical source of truth,
we have an opportunity for convenient end-to-end testing that we didn't
easily have before with svn (yes, it could be done but in an ugly way).
AFAIK the only upstream end-to-end testing we have is in test-suite and
many of those codes are very large and/or unfocused tests.

With the monorepo we have a place to put lit-style tests that exercise
multiple subprojects, for example tests that ensure the entire clang
compilation pipeline executes correctly.  We could, for example, create
a top-level "test" directory and put end-to-end tests there.  Some of
the things that could be tested include:

- Pipeline execution (debug-pass=Executions)
- Optimization warnings/messages
- Specific asm code sequences out of clang (e.g. ensure certain loops
   are vectorized)
- Pragma effects (e.g. ensure loop optimizations are honored)
- Complete end-to-end PGO (generate a profile and re-compile)
- GPU/accelerator offloading
- Debuggability of clang-generated code

Each of these things is tested to some degree within their own
subprojects, but AFAIK there are currently no dedicated tests ensuring
such things work through the entire clang pipeline flow and with other
tools that make use of the results (debuggers, etc.).  It is relatively
easy to break the pipeline while the individual subproject tests
continue to pass.

I realize that some folks prefer to work on only a portion of the
monorepo (for example, they just hack on LLVM).  I am not sure how to
address those developers WRT end-to-end testing.  On the one hand,
requiring them to run end-to-end testing means they will have to at
least check out and build the monorepo.  On the other hand, it seems
less than ideal to have people developing core infrastructure and not
running tests.

I don't yet have a formal proposal but wanted to put this out to spur
discussion and gather feedback and ideas.  Thank you for your interest
and participation!


The two major concerns I see are a potential decay in component test 
quality, and an increase in difficulty changing components. The former 
has already been discussed a bit downstream, so let me focus on the later.


A challenge we already have - as in, I've broken these tests and had to 
fix them - is that an end to end test which checks either IR or assembly 
ends up being extraordinarily fragile.  Completely unrelated profitable 
transforms create small differences which cause spurious test failures.  
This is a very real issue today with the few end-to-end clang tests we 
have, and I am extremely hesitant to expand those tests without giving 
this workflow problem serious thought.  If we don't, this could bring 
development on middle end transforms to a complete stop.  (Not kidding.)


A couple of approaches we could consider:

1. Simply restrict end to end tests to crash/assert cases.  (i.e. no
   property of the generated code is checked, other than that it is
   generated)  This isn't as restrictive as it sounds when combined
   w/coverage guided fuzzer corpuses.
2. Auto-update all diffs, but report them to a human user for
   inspection.  This ends up meaning that tests never "fail" per se,
   but that individuals who have expressed interest in particular tests
   get an automated notification and a chance to respond on list with a
   reduced example.
3. As a variant on the former, don't auto-update tests, but only inform
   the *contributor* of an end-to-end test of a failure. Responsibility
   for determining failure vs false positive lies solely with them, and
   normal channels are used to report a failure after it has been
   confirmed/analyzed/explained.

I really think this is a problem we need to have thought through and 
found a workable solution before end-to-end testing as proposed becomes 
a practically workable option.


Philip

___
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: linear history vs merge commits

[Philip Reames via lldb-dev]

Strongly in favor of #1.

If we decide to move away from #1, I strongly believe it should be done 
well after the github migration.  (i.e. lets not change everything at once!)


Philip

On 1/29/19 2:33 PM, Tom Stellard via cfe-dev wrote:

Hi,

As part of the migration of LLVM's source code to github, we need to update
our developer policy with instructions about how to interact with the new git
repository.  There are a lot of different topics we will need to discuss, but
I would like to start by initiating a discussion about our merge commit
policy.  Should we:

1. Disallow merge commits and enforce a linear history by requiring a
rebase before push.

2. Allow merge commits.

3. Require merge commits and disallow rebase before push.

I'm going to propose that if we cannot reach a consensus that we
adopt policy #1, because this is essentially what we have now
with SVN.

What does everyone think?

Thanks,
Tom
___
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] [llvm-dev] [cfe-dev] FYI: Landing the initial draft for an LLVM Code of Conduct

[Philip Reames via lldb-dev]

+1.

On 06/30/2016 04:01 PM, Hal Finkel via llvm-dev wrote:

- Original Message -

From: "Aaron Ballman via cfe-dev" 
To: "Chandler Carruth" 
Cc: "llvm-dev" , "cfe-dev" , 
"openmp-dev
(openmp-...@lists.llvm.org)" , "LLDB" 

Sent: Thursday, June 30, 2016 5:34:13 PM
Subject: Re: [cfe-dev] FYI: Landing the initial draft for an LLVM Code of   
Conduct

Thank you for your continuing efforts on the Code of Conduct! I
appreciate the efforts and strongly support this direction.

~Aaron

+1

  -Hal


On Thu, Jun 30, 2016 at 2:55 PM, Chandler Carruth via cfe-dev
 wrote:

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

___
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