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

[James Henderson via lldb-dev]

Quite possibly. I am one of the current self-volunteered triagers on each
of the GNU-equivalent LLVM binutils, and somebody who is therefore on the
CC list for several bugzilla components with small numbers. I don't have
the expertise to triage 95% of issues that come in elsewhere so me being in
some kind of high-level bug triager group would simply not work (I don't
have the time or desire to sift through other bugs). Similarly, do we
expect the people in this proposed triager group to have sufficient
knowledge about all parts of LLVM to redirect things appropriately? And how
would they redirect things? They could assign an llvm-readelf issue to me
or one of the other active maintainers in the corresponding area, for
example, but that doesn't mean I'm going to do anything about it (I'll
triage incoming bugs, but not necessarily fix most of them - I get paid to
work with LLVM, so if there's no business need from my company's point of
view, it's unlikely I'll ever look at it beyond the initial triage). That
would therefore imply we need a component for the issue to be assigned to
so that interested parties can fix it, people who are trying to find out
whether something is a known issue can find it, etc.

I agree that each component should have its own group of triagers so that
things don't fall into an unacknowledged black hole, but I think these need
to be focused components on small areas. A clear breakdown to me is a
component for each "project" where I define a project to be something that
appears in Visual Studio as such, which in turn translates into each
library and each executable (with some obvious exceptions where the library
is used by only a single executable or similar such situation).

What is wrong with component tags that aren't necessarily used all that
often?

On Mon, 16 Mar 2020 at 16:24, James Y Knight  wrote:

> I think we ought to setup some sort of organized scheme for volunteers to
> do triage of incoming issues, to make sure they've got enough actionable
> info, and direct to the correct people as needed.
>
> (This would actually be a really nice thing to have, regardless of which
> bugtracking system we have.)
>
> On Mon, Mar 16, 2020 at 11:41 AM James Henderson via cfe-dev <
> cfe-...@lists.llvm.org> wrote:
>
>>
>>
>> On Mon, 16 Mar 2020 at 15:08, Tom Stellard  wrote:
>>
>>> On 03/16/2020 08:00 AM, James Henderson wrote:
>>> >
>>> >
>>> > On Mon, 16 Mar 2020 at 14:44, Tom Stellard via cfe-dev <
>>> cfe-...@lists.llvm.org > wrote:
>>> >
>>> > On 02/10/2020 07:40 PM, Tom Stellard wrote:
>>> > > On 01/30/2020 12:47 PM, David Major wrote:
>>> > >> Would it make sense to wait until 10.0.0 is released, in order
>>> to keep all the blockers in one place?
>>> > >>
>>> > >
>>> > > Yes, I think this makes sense, let's postpone until then.
>>> > >
>>> >
>>> > Hi,
>>> >
>>> > 10.0.0-rc4 was just released, and I think we are at the point in
>>> the release cycle
>>> > where it is safe to begin the migration to GitHub issues.
>>> >
>>> > I would like to propose doing the migration in one week (March
>>> 23).  This means
>>> > making the existing bugzilla read-only, and updating the
>>> documentation to tell users
>>> > to file issues at GitHub.
>>> >
>>> >
>>> > Don't forget to update the URL used in crash messages to point at the
>>> right location.
>>> >
>>> >
>>> > We are still trying to figure out the best way to import bugs
>>> > from bugzilla into GitHub, so this step will be done at a later
>>> date.
>>> >
>>> >
>>> > Making bugzilla read-only seems like a bad idea until all existing
>>> issues have been migrated. What if people need to update an existing bug
>>> once the migration to using Github issues has happened before importing has
>>> also happened?
>>> >
>>>
>>> This was a mistake on my part.  The plan is to disable creation of new
>>> bugs in bugzilla and not
>>> to make it read-only.  If you look at the original RFC, it says GitHub
>>> issues
>>> would be used for new issues, and existing issues will continue to be
>>> updated in bugzilla,
>>> and this is what I'm proposing.
>>>
>>> >
>>> >
>>> > For the initial list of tags, I propose we generate the list based
>>> on the most commonly
>>> > used categories in bugzilla.  This should be enough to get us
>>> started and we can always
>>> > add more tags as we go.
>>> >
>>> >
>>> > I'd like this list to be fleshed out before migration is agreed. I'm
>>> concerned different people will have wildly different ideas of what
>>> "commonly used" might mean, which could in turn have an impact on the
>>> viability of this tag list.
>>> >
>>>
>>> Most commonly used here means categories with the most bugs.  So, this
>>> would be
>>> based on raw bug counts and not just someone's opinion.
>>>
>>> -Tom
>>>
>>
>> That's what I thought might be the case, and where I take issue with it.
>> I've said this on several previous occasions - I thin

[lldb-dev] LLDB problem with TAB

[Rui Hong via lldb-dev]

Hi LLDB devs,

First I want to thank you all for the very helpful advice on my former 
question! It's a really nice community.



I have a small problem now about LLDB tab completion and I haven't found any 
solutions so far. I used to have nice tab completion before. But I cannot get 
this feature to work on my LLDB 7.0.1 on linux after I enable python, where an 
actual tab is inserted after the cursor and similar for other control 
characters like Backspace. Both in lldb console and the embedded python 
interpreter??


That's very inconvenient. Is there anything wrong? I haven't changed the code 
at all, just added some necessary parameters in cmake command to enable python. 
Things worked well even last week before rebuild with python


Kind regards,
Rui___
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

[Tom Stellard via lldb-dev]

On 03/16/2020 11:09 PM, Roman Lebedev wrote:
> On Tue, Mar 17, 2020 at 6:07 AM Tom Stellard via cfe-dev
>  wrote:
>>
>> On 03/16/2020 10:13 AM, Florian Hahn wrote:
>>> Hi,
>>>
 On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev 
 mailto:llvm-...@lists.llvm.org>> wrote:

 I've also implemented a notification system using GitHub actions that will 
 make
 it possible to subscribe to individual issue tags, so we would enable this 
 on Monday
 as well.
>>>
>>> Does this include sending emails for new bugs to llvm-bugs like bugzilla 
>>> does? I am not sure how many people use llvm-bugs, but at least for me it 
>>> is how I keep up with new bug reports.
>>>
>>
>> Sending email to llvm-bugs was not planned.  Can you use GitHub 
>> notifications instead?
> How do i subscribe to only get notified about new issues, but not
> about every new change
> in every issue unless i have explicitly subscribed to the issue?

Is there a way to do this with bugzilla?

-Tom

> 
>> -Tom
> Roman
> 
>>> Cheers,
>>> Florian
>>
>> ___
>> 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

[Tom Stellard via lldb-dev]

On 03/17/2020 06:39 AM, Roman Lebedev wrote:
> On Tue, Mar 17, 2020 at 4:35 PM Tom Stellard  wrote:
>>
>> On 03/16/2020 11:09 PM, Roman Lebedev wrote:
>>> On Tue, Mar 17, 2020 at 6:07 AM Tom Stellard via cfe-dev
>>>  wrote:

 On 03/16/2020 10:13 AM, Florian Hahn wrote:
> Hi,
>
>> On Mar 16, 2020, at 14:43, Tom Stellard via llvm-dev 
>> mailto:llvm-...@lists.llvm.org>> wrote:
>>
>> I've also implemented a notification system using GitHub actions that 
>> will make
>> it possible to subscribe to individual issue tags, so we would enable 
>> this on Monday
>> as well.
>
> Does this include sending emails for new bugs to llvm-bugs like bugzilla 
> does? I am not sure how many people use llvm-bugs, but at least for me it 
> is how I keep up with new bug reports.
>

 Sending email to llvm-bugs was not planned.  Can you use GitHub 
 notifications instead?
>>> How do i subscribe to only get notified about new issues, but not
>>> about every new change
>>> in every issue unless i have explicitly subscribed to the issue?
>>
>> Is there a way to do this with bugzilla?
> That is the current behavior of llvm-bugs@ + manually subscribing to
> the bugs of interest.
> 

As I just mentioned in the other mail, looking at the llvm-bugs archive
it looks like there are more than just new bugs e.g.
http://lists.llvm.org/pipermail/llvm-bugs/2020-March/082017.html

-Tom

>> -Tom
> Roman
> 
 -Tom
>>> Roman
>>>
> Cheers,
> Florian

 ___
 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

[lldb-dev] LLVM GSoC 2020

[Anton Korobeynikov via lldb-dev]

Dear Prospective GSoC students,

As you already know, the proposal submission process recently started
and will continue until March 31 (please see GSoC website for the
complete timeline).

While one can submit the proposal to GSoC system directly, we strongly
encourage to submit proposals for discussion into the corresponding
mailing lists (e.g. llvm-dev for LLVM related projects, cfe-dev for
clang, lldb-dev for LLDB and MLIR discourse for MLIR). Previous
experience shows that the review and discussions around the proposals
contribute greatly to their overall quality and drive the success of
the project should it be accepted.

In your proposal, besides the details of the project itself, its
timeline, etc. please also provide some additional information like:
  - Any prior experience to LLVM (e.g. patches submitted, courses that
use LLVM taken, any theses, etc)
  - Any prior experience in compiler and compiler-related technologies
  - What is your motivation to contribute to LLVM, why it is
interesting for you.

Thanks and good luck!

-- 
With best regards, Anton Korobeynikov
Department of Statistical Modelling, Saint Petersburg State University
___
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev