Re: [lldb-dev] [10.0.0 Release] Release Candidate 4 is here

[Hans Wennborg via lldb-dev]

On Fri, Mar 13, 2020 at 8:09 PM Hans Wennborg  wrote:
>
> Hello everyone,
>
> Release Candidate 4 was tagged earlier today as llvmorg-10.0.0-rc4 on
> the release branch at b406eab8880. It contains 12 commits since the
> previous release candidate.
>
> If no new problems arise, this is what the final release will look like.
>
> Source code and docs are available at
> https://prereleases.llvm.org/10.0.0/#rc4 and
> https://github.com/llvm/llvm-project/releases/tag/llvmorg-10.0.0-rc4
>
> Pre-built binaries will be added as they become ready.

Windows binaries are ready. They were built with the attached batch file.

$ sha256sum LLVM-10.0.0-rc4-win*.exe
4f599fbc38afc0031e8766c39c8e00673d51f6d0e5bbd5a98fdf71507a35d332
LLVM-10.0.0-rc4-win32.exe
15d5b9b6c71ef5078c40bf49026128358bb9a03608f836173ab29cf5b523aac7
LLVM-10.0.0-rc4-win64.exe


build_llvm_1000-rc4._bat_
Description: Binary data
___
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] RFC: Switching from Bugzilla to Github Issues

[Tom Stellard via lldb-dev]

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.  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.

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'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.

What does everyone think?

Thanks,
Tom


> -Tom
> 
>>
>>
>> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev 
>> mailto:llvm-...@lists.llvm.org>> wrote:
>>
>> On 01/30/2020 10:24 AM, Aaron Ballman wrote:
>> > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
>> > mailto:cfe-...@lists.llvm.org>> wrote:
>> >>
>> >> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
>> >>> We held a round-table at the llvm dev conference about what other 
>> pieces of Github infrastructure we may want to use. This thread in 
>> particular is about switching to github issue tracking. Use of other parts 
>> of Github functionality was also discussed -- but that should be for other 
>> email threads.
>> >>>
>> >>> Most of the ideas here were from other people. I /believe/ this 
>> proposal represents the overall feeling of the folks at the round-table, in 
>> spirit if not in exact details, but nobody else has reviewed this text, so I 
>> can't make any specific such claim as to who the "we" represents, other than 
>> myself. Just assume all the good ideas here were from others, and all the 
>> bad parts I misremembered or invented.
>> >>>
>> >>>
>> >>
>> >> Hi,
>> >>
>> >> I want to restart this discussion.  There seemed to be support for 
>> this,
>> >> but we got held up trying to decide on the appropriate set of tags to
>> >> use to classify issues.
>> >>
>> >> I propose that we move forward with this proposal and disable 
>> creation of
>> >> new bugs in bugzilla on Feb 11, and require all new bugs be filed via 
>> GitHub
>> >> issues from that date forward.
>> >>
>> >> I think that for choosing the tags to use, we should just take 
>> requests
>> >> from the community over the next week and add whatever is asked for.  
>> The main
>> >> purpose of adding tags is so we can setup cc lists for bugs, so I 
>> think this
>> >> is a good way to ensure that we have tags people care about.  We can 
>> always
>> >> add more tags later if necessary.
>> >>
>> >> What does everyone think about this?
>> >
>> > What did we decide to do with all the existing issues in Bugzilla?
>> >
>>
>> This is undecided.  The first step of this  proposal only affects new 
>> issues.
>> Existing issues will remain in bugzilla and will be updated there too.  
>> At
>> some point in the future bugzilla will become read-only and/or the 
>> issues will
>> be migrated somewhere else, but no decision has been made about how to 
>> do that yet.
>>
>> -Tom
>>
>> > ~Aaron
>> >
>> >>
>> >> -Tom
>> >>
>> >>
>> >>> Background
>> >>> 
>> >>> Our bugzilla installation is...not great. It's been not-great for a 
>> long time now.
>> >>>
>> >>> Last year, I argued against switching to github issues. I was 
>> somewhat optimistic that it was possible to improve our bugzilla in some 
>> incremental ways...but we haven't. Additionally, the upstream bugzilla 
>> project was supposed to make a new release of bugzilla ("harmony"), based on 
>> bugzilla.mozilla.org  
>> 's fork, which is much nicer. I thought we 
>> would be able to upgrade to that. But there has been no such release, and 
>> not much apparent progress towards such. I can't say with any confidence 
>> that there will ever be. I no longer believe it really makes sense to 
>> continue using bugzilla.
>> >>>
>> >>> This year, we again discussed switching. This time, nobody really 
>> spoke up in opposition. So, this time, instead of debating /whether/ we 
>> should switch, we discussed /how/ we should switch. And came up with a plan 
>> to switch quickly.
>> >>>
>> >>> GitHub issues may not be perfect, but I see other similarly

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

[Aaron Ballman via lldb-dev]

On Mon, Mar 16, 2020 at 10:44 AM Tom Stellard via cfe-dev
 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.  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.
>
> 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'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.
>
> What does everyone think?

I am uncomfortable switching to GitHub issues unless the initial
result is that we have ONE set of bugs to track (I do not want to have
to search and maintain separate bug lists). Moving bugs from Bugzilla
at an unspecified future time is a deal-breaker for me, so -1.

~Aaron

>
> Thanks,
> Tom
>
>
> > -Tom
> >
> >>
> >>
> >> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev 
> >> mailto:llvm-...@lists.llvm.org>> wrote:
> >>
> >> On 01/30/2020 10:24 AM, Aaron Ballman wrote:
> >> > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
> >> > mailto:cfe-...@lists.llvm.org>> wrote:
> >> >>
> >> >> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
> >> >>> We held a round-table at the llvm dev conference about what other 
> >> pieces of Github infrastructure we may want to use. This thread in 
> >> particular is about switching to github issue tracking. Use of other parts 
> >> of Github functionality was also discussed -- but that should be for other 
> >> email threads.
> >> >>>
> >> >>> Most of the ideas here were from other people. I /believe/ this 
> >> proposal represents the overall feeling of the folks at the round-table, 
> >> in spirit if not in exact details, but nobody else has reviewed this text, 
> >> so I can't make any specific such claim as to who the "we" represents, 
> >> other than myself. Just assume all the good ideas here were from others, 
> >> and all the bad parts I misremembered or invented.
> >> >>>
> >> >>>
> >> >>
> >> >> Hi,
> >> >>
> >> >> I want to restart this discussion.  There seemed to be support for 
> >> this,
> >> >> but we got held up trying to decide on the appropriate set of tags 
> >> to
> >> >> use to classify issues.
> >> >>
> >> >> I propose that we move forward with this proposal and disable 
> >> creation of
> >> >> new bugs in bugzilla on Feb 11, and require all new bugs be filed 
> >> via GitHub
> >> >> issues from that date forward.
> >> >>
> >> >> I think that for choosing the tags to use, we should just take 
> >> requests
> >> >> from the community over the next week and add whatever is asked 
> >> for.  The main
> >> >> purpose of adding tags is so we can setup cc lists for bugs, so I 
> >> think this
> >> >> is a good way to ensure that we have tags people care about.  We 
> >> can always
> >> >> add more tags later if necessary.
> >> >>
> >> >> What does everyone think about this?
> >> >
> >> > What did we decide to do with all the existing issues in Bugzilla?
> >> >
> >>
> >> This is undecided.  The first step of this  proposal only affects new 
> >> issues.
> >> Existing issues will remain in bugzilla and will be updated there too. 
> >>  At
> >> some point in the future bugzilla will become read-only and/or the 
> >> issues will
> >> be migrated somewhere else, but no decision has been made about how to 
> >> do that yet.
> >>
> >> -Tom
> >>
> >> > ~Aaron
> >> >
> >> >>
> >> >> -Tom
> >> >>
> >> >>
> >> >>> Background
> >> >>> 
> >> >>> Our bugzilla installation is...not great. It's been not-great for 
> >> a long time now.
> >> >>>
> >> >>> Last year, I argued against switching to github issues. I was 
> >> somewhat optimistic that it was possible to improve our bugzilla in some 
> >> incremental ways...but we haven't. Additionally, the upstream bugzilla 
> >> project was supposed to make a new release of bugzilla ("harmony"), based 
> >> on bugzilla.mozilla.org  
> >> 's fork, which is much nicer. I thought we 
> >> would be 

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

[James Henderson via lldb-dev]

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?


>
> 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.


>
> 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.
>
> What does everyone think?
>
> Thanks,
> Tom
>
>
> > -Tom
> >
> >>
> >>
> >> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <
> llvm-...@lists.llvm.org > wrote:
> >>
> >> On 01/30/2020 10:24 AM, Aaron Ballman wrote:
> >> > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
> >> > mailto:cfe-...@lists.llvm.org>> wrote:
> >> >>
> >> >> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
> >> >>> We held a round-table at the llvm dev conference about what
> other pieces of Github infrastructure we may want to use. This thread in
> particular is about switching to github issue tracking. Use of other parts
> of Github functionality was also discussed -- but that should be for other
> email threads.
> >> >>>
> >> >>> Most of the ideas here were from other people. I /believe/ this
> proposal represents the overall feeling of the folks at the round-table, in
> spirit if not in exact details, but nobody else has reviewed this text, so
> I can't make any specific such claim as to who the "we" represents, other
> than myself. Just assume all the good ideas here were from others, and all
> the bad parts I misremembered or invented.
> >> >>>
> >> >>>
> >> >>
> >> >> Hi,
> >> >>
> >> >> I want to restart this discussion.  There seemed to be support
> for this,
> >> >> but we got held up trying to decide on the appropriate set of
> tags to
> >> >> use to classify issues.
> >> >>
> >> >> I propose that we move forward with this proposal and disable
> creation of
> >> >> new bugs in bugzilla on Feb 11, and require all new bugs be
> filed via GitHub
> >> >> issues from that date forward.
> >> >>
> >> >> I think that for choosing the tags to use, we should just take
> requests
> >> >> from the community over the next week and add whatever is asked
> for.  The main
> >> >> purpose of adding tags is so we can setup cc lists for bugs, so
> I think this
> >> >> is a good way to ensure that we have tags people care about.  We
> can always
> >> >> add more tags later if necessary.
> >> >>
> >> >> What does everyone think about this?
> >> >
> >> > What did we decide to do with all the existing issues in Bugzilla?
> >> >
> >>
> >> This is undecided.  The first step of this  proposal only affects
> new issues.
> >> Existing issues will remain in bugzilla and will be updated there
> too.  At
> >> some point in the future bugzilla will become read-only and/or the
> issues will
> >> be migrated somewhere else, but no decision has been made about how
> to do that yet.
> >>
> >> -Tom
> >>
> >> > ~Aaron
> >> >
> >> >>
> >> >> -Tom
> >> >>
> >> >>
> >> >>> Background
> >> >>> 
> >> >>> Our bugzilla installation is...not great. It's been not-great
> for a long time now.
> >> >>>
> >> >>> Last year, I argued against switching to github issues. I was
> somewhat optimistic that it was possible to improve our bugzilla in some
> incremental ways...but we haven't. Additionally, the upstream bugzilla
> project w

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

[Tom Stellard via lldb-dev]

On 03/16/2020 08:00 AM, James Henderson wrote:
> 
> 
> On Mon, 16 Mar 2020 at 14:44, Tom Stellard via cfe-dev 
> mailto: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

> 
> 
> 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.
> 
> What does everyone think?
> 
> Thanks,
> Tom
> 
> 
> > -Tom
> >
> >>
> >>
> >> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev 
> mailto:llvm-...@lists.llvm.org> 
> >> wrote:
> >>
> >> On 01/30/2020 10:24 AM, Aaron Ballman wrote:
> >> > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
> >> > mailto:cfe-...@lists.llvm.org> 
> >> wrote:
> >> >>
> >> >> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
> >> >>> We held a round-table at the llvm dev conference about what 
> other pieces of Github infrastructure we may want to use. This thread in 
> particular is about switching to github issue tracking. Use of other parts of 
> Github functionality was also discussed -- but that should be for other email 
> threads.
> >> >>>
> >> >>> Most of the ideas here were from other people. I /believe/ 
> this proposal represents the overall feeling of the folks at the round-table, 
> in spirit if not in exact details, but nobody else has reviewed this text, so 
> I can't make any specific such claim as to who the "we" represents, other 
> than myself. Just assume all the good ideas here were from others, and all 
> the bad parts I misremembered or invented.
> >> >>>
> >> >>>
> >> >>
> >> >> Hi,
> >> >>
> >> >> I want to restart this discussion.  There seemed to be support 
> for this,
> >> >> but we got held up trying to decide on the appropriate set of 
> tags to
> >> >> use to classify issues.
> >> >>
> >> >> I propose that we move forward with this proposal and disable 
> creation of
> >> >> new bugs in bugzilla on Feb 11, and require all new bugs be 
> filed via GitHub
> >> >> issues from that date forward.
> >> >>
> >> >> I think that for choosing the tags to use, we should just take 
> requests
> >> >> from the community over the next week and add whatever is asked 
> for.  The main
> >> >> purpose of adding tags is so we can setup cc lists for bugs, so 
> I think this
> >> >> is a good way to ensure that we have tags people care about.  
> We can always
> >> >> add more tags later if necessary.
> >> >>
> >> >> What does everyone think about this?
> >> >
>  

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

[James Henderson via lldb-dev]

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 think it makes sense for
tags/bugzilla components etc. to exist for each individual executable, as
well as the various libraries. Let's say I'm a user of a tool like
llvm-size and I find a bug. If there wasn't a tag for llvm-size, I wouldn't
know where to file it (and no, I don't think a catch-all "binutils" tag is
useful - not every developer will know what counts as a "binutils" tag). At
the time of writing there are exactly three bugs for llvm-size. That
presumably isn't going to meet any threshold imposed, so this tag wouldn't
be created, and I wouldn't know where to file my bug, so I probably would
either guess (and quite likely get it wrong), or not add a tag, which means
that developers who are focused on developing the binutils (and would
therefore have subscribed to this tag) won't see the issue. I might even
not file the bug at all.


> >
> >
> > 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.
> >
> > What does everyone think?
> >
> > Thanks,
> > Tom
> >
> >
> > > -Tom
> > >
> > >>
> > >>
> > >> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <
> llvm-...@lists.llvm.org   llvm-...@lists.llvm.org >> wrote:
> > >>
> > >> On 01/30/2020 10:24 AM, Aaron Ballman wrote:
> > >> > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
> > >> > mailto:cfe-...@lists.llvm.org>
> >> wrote:
> > >> >>
> > >> >> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
> > >> >>> We held a round-table at the llvm dev conference about
> what other pieces of Github infrastructure we may want to use. This thread
> in particular is about switching to github issue tracking. Use of other
> parts of Github functionality was also discussed -- but that should be for
> other email threads.
> > >> >>>
> > >> >>> Most of the ideas here were from other people. I
> /believe/ this proposal represents the overall feeling of the folks at the
> round-table, in spirit if not in exact details, but nobody else has
> reviewed this text, so I can't make any specific such claim as to who the
> "we" represents, other than myself. Just assume all the g

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

[James Y Knight via lldb-dev]

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 think it makes sense for
> tags/bugzilla components etc. to exist for each individual executable, as
> well as the various libraries. Let's say I'm a user of a tool like
> llvm-size and I find a bug. If there wasn't a tag for llvm-size, I wouldn't
> know where to file it (and no, I don't think a catch-all "binutils" tag is
> useful - not every developer will know what counts as a "binutils" tag). At
> the time of writing there are exactly three bugs for llvm-size. That
> presumably isn't going to meet any threshold imposed, so this tag wouldn't
> be created, and I wouldn't know where to file my bug, so I probably would
> either guess (and quite likely get it wrong), or not add a tag, which means
> that developers who are focused on developing the binutils (and would
> therefore have subscribed to this tag) won't see the issue. I might even
> not file the bug at all.
>
>
>> >
>> >
>> > 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.
>> >
>> > What does everyone think?
>> >
>> > Thanks,
>> > Tom
>> >
>> >
>> > > -Tom
>> > >
>> > >>
>> > >>
>> > >> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <
>> llvm-...@lists.llvm.org  > llvm-...@lists.llvm.org >> wrote:
>> > >>
>> > >> On 01/30/2020 10:24 AM, Aaron Ballman wrote:
>> > >> > On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
>> > >> > mailto:cfe-...@lists.llvm.org>
>> >> wrote:
>> > >> >>
>> > >> >> On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote:
>> > >> >>> We held a round-table at the llvm dev conference about
>> what other pieces of Github infrastructure we may want to use. This thread
>> i

Re: [lldb-dev] Question about LLDB SBEvent C++ API

[Greg Clayton via lldb-dev]

> On Mar 14, 2020, at 4:13 PM, Rui Liu via lldb-dev  
> wrote:
> 
> Hi LLDB devs,
> 
> The SBEvent API has GetType() method on it, which returns a uint32_t, however 
> I didn't find any documentation on how to interpret this uint32_t... Is there 
> a enum for it somewhere?
> 
> There is a GetDescription() API to create a human-readable string, but I'd 
> rather to inspect the event type programmatically.
> 
> Overall I find the API is not documented very well, which makes it quite hard 
> to use... For example, I didn't find a place that explains what are the the 
> possible event types and what data they carry. (I didn't even find an enum!) 
> Are there any good resources that I might not discover yet?
> 
> Also any advice on how to use LLDB C++ API (without prior knowledge) would be 
> much appreciated!

A good example in python can be found at:

lldb/examples/python/process_events.py

Also the lldb-vscode plug-in shows how to use the API from a C++ perspective:

lldb/tools/lldb-vscode/lldb-vscode.cpp

Events are generated by SBBroadcaster objects or internally inside of LLDB and 
caught using SBListener objects. Every object that can generate SBEvents have 
an enumeration declared in the class header file. For example in SBProcess.h we 
see:

class LLDB_API SBProcess {
public:
  /// Broadcaster event bits definitions.
  FLAGS_ANONYMOUS_ENUM(){eBroadcastBitStateChanged = (1 << 0),
 eBroadcastBitInterrupt = (1 << 1),
 eBroadcastBitSTDOUT = (1 << 2),
 eBroadcastBitSTDERR = (1 << 3),
 eBroadcastBitProfileData = (1 << 4),
 eBroadcastBitStructuredData = (1 << 5)};

If you search for SBEvent in each header file you can see the event 
introspection functions. They are all static and take a SBEvent & argument. For 
example to see if an event is a  process event you can call:

static bool SBProcess::EventIsProcessEvent(const lldb::SBEvent &event);

It all depends on how many different kinds of events you sign up to listen to 
with your SBListener. When launching a process you _can_ provide a listener in 
the SBLaunchInfo or SBAttachInfo, but most people don't set one and all events 
delivered to the SBDebugger, which you can listen for all events from the 
SBTarget, SBProcess and SBThread. 

Once you determine what kind of event you have using:

static bool SBTarget::EventIsTargetEvent(const lldb::SBEvent &event);
static bool SBProcess::EventIsProcessEvent(const lldb::SBEvent &event);
static bool SBThread::EventIsThreadEvent(const lldb::SBEvent &event);
static bool SB*::EventIs*Event(const lldb::SBEvent &event);

Then you can use the enumerations in the appropriate header file to check the 
type and identify the event type. There are usually static functions that will 
help you extract more information from the event. For example for the 
SBProcess::eBroadcastBitStateChanged event, you can get the state from the 
event:

static lldb::StateType SBProcess::GetStateFromEvent(const lldb::SBEvent &event);

StateType tells you what the process state has changed to: eStateStopped, 
eStateRunning, eStateExited.

There definitely should be more documentation on this, but for now feel free to 
ask us any questions here.

Greg


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

[Tom Stellard via lldb-dev]

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?

-Tom

> Cheers,
> Florian

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