[lldb-dev] Reporting source errors from MCCodeEmitter::encodeInstruction() ?
We have a backend for a target that at present only detects some assembler errors when emitting instructions (basically because the platform has configurable properties with dependencies between instructions and it was easier to check for their interaction late than try to detect them earlier, e.g. through custom encoder methods and tablegen). Emitting diagnostics through SourceManager::PrintMessage() "works" in the limited sense of communicating the problem to a human, however it doesn't prevent generation of an incorrect output file or change the process exit code. We'd prefer not to resort to report_fatal_error() since that isn't a polite way to diagnose problems in the source. Is there a sensible way to properly signal a source error from the level of encodeInstruction()? Or is it expected that all such errors are reported earlier? ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Call for GSoC 2020 projects
Hi, sorry for the late response. Yes, my question is answered. I hadn't any doubt that LLVM will participate in GSoC and my question aimed on knowing if it's too late to propose a project - sorry for being unclear here. Thanks for organising LLVM's GSoC participation! Cheers, David > On 29. Jan 2020, at 11:24, Anton Korobeynikov wrote: > > Hello David, > I believe Johannes already answered your questions, but just to > clarify the things fully: yes, we are going to submit an application > to participate in GSoC this year as usual. I will take care of > necessary paperwork and stuff. > Currently we're collecting the list of summer projects here and there. > It's perfectly fine to have the lists from sub-projects to be posted > on their respective websites as a part of corresponding "Open > Projects" pages. > On Fri, Jan 24, 2020 at 2:52 PM David Tellenbach > wrote: > > > > Hi all, > > > > may I ask about the current status of this? > > > > The deadline for organizations to apply is February 5, 2020; has an > > application > > already been made? > > > > Another thing: https://llvm.org/OpenProjects.html states that MLIR related > > projects can be found on > > https://mlir.llvm.org/getting_started/openprojects/. I > > suggest adding these projects (including some more background information) > > to > > our common list, just like other sub-projects do. > > > > Cheers, > > David > > > > > On 23. Dec 2019, at 11:00, Anton Korobeynikov via llvm-dev wrote: > > > > > > Dear prospective LLVM GSoC Mentors, > > > > > > The organization application period for GSoC 2020 will open on > > > January, 14. This means that we're having some time to prepare the > > > list of project ideas for the next year. > > > > > > When proposing the project please keep in mind the following criteria: > > > 1. The project should serve both LLVM as a project and provide the > > > relevant LLVM knowledge to the student. > > > 2. The project should contribute directly to LLVM, clang or LLVM > > > compiler infrastructure subproject (e.g. not related to some > > > out-of-tree 3rd party project just using LLVM). > > > 3. There should be well-defined scope of the project and some set of > > > "deliverables" at the end of the project. > > > 4. The project should be either developed in the LLVM mainline or be > > > ready to be committed to LLVM at the end of GSoC period. > > > > > > The Open Projects page was just updated to include the necessary > > > boilerplate, so feel free to propose the projects there. > > > > > > Thanks! > > > > > > -- > > > With best regards, Anton Korobeynikov > > > Department of Statistical Modelling, Saint Petersburg State University > > > ___ > > > LLVM Developers mailing list > > > llvm-...@lists.llvm.org > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > -- > With best regards, Anton Korobeynikov > Department of Statistical Modelling, Saint Petersburg State University > ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues
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?
-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-large projects
> using it quite successfully (e.g. rust-lang/rust) -- so I believe it should
> be good for us, as well. Importantly, Github Issues is significantly less
> user-hostile than our bugzilla is, for new contributors and downstream
> developers who just want to tell us about bugs!
>
>
> Proposal
>
> We propose to enable Github issues for the llvm-project repository in
> approximately two weeks from now, and instruct everyone to start filing new
> issues there, rather than in bugzilla.
>
> Some things we'd like to get in place before turning on Github's Issue
> tracker:
> 1. Updated documentation.
> 2. An initial set of issue tags we'd like to use for triaging/categorizing
> issues.
> 3. Maybe setup an initial issue template. Or maybe multiple templates. Or
> maybe not.
>
> But more important are the things we do /not/ want to make prerequisites for
> turning on Github issues:
>
> We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to migrate the
> existing issues to GitHub as a prerequisite for switching. We will thus
> expect that people continue using bugzilla for commenting on the existing
> bugs -- for the moment.
>
> We do /not/ want to build supplementary notification systems to make github
> issues send additional emails that it is unable to send itself. We will only
> support what GitHub supports. That means:
> - You can subscribe to notification emails for activity in the entire
> llvm-project repository.
> - You can subscribe to notification emails on an individual issue.
> - Someone else can CC you on an individual issue to get your attention, and
> you will get notifications from that (unless you opt-out).
> - No emails will be sent to llvm-b...@llvm.org
> for github issues.
> - There is no builtin way for users to subscribe to emails for bugs that have
> a given label (for example, all "clang" issues, or all x86 issues).
>
> Further steps
>
> After we migrate, there's still things we want to do:
>
> 1. Discuss and setup new and better procedures around bug triage and
> prioritization.
>
> What we have been doing up until now has not been great in any case.
> Switching bug-trackers is a great opportunity to try to do something better.
> E.g., like what the rust project has done
> (https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#issue-
Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues
On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
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?
~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-large projects
> > using it quite successfully (e.g. rust-lang/rust) -- so I believe it should
> > be good for us, as well. Importantly, Github Issues is significantly less
> > user-hostile than our bugzilla is, for new contributors and downstream
> > developers who just want to tell us about bugs!
> >
> >
> > Proposal
> >
> > We propose to enable Github issues for the llvm-project repository in
> > approximately two weeks from now, and instruct everyone to start filing new
> > issues there, rather than in bugzilla.
> >
> > Some things we'd like to get in place before turning on Github's Issue
> > tracker:
> > 1. Updated documentation.
> > 2. An initial set of issue tags we'd like to use for triaging/categorizing
> > issues.
> > 3. Maybe setup an initial issue template. Or maybe multiple templates. Or
> > maybe not.
> >
> > But more important are the things we do /not/ want to make prerequisites
> > for turning on Github issues:
> >
> > We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to migrate the
> > existing issues to GitHub as a prerequisite for switching. We will thus
> > expect that people continue using bugzilla for commenting on the existing
> > bugs -- for the moment.
> >
> > We do /not/ want to build supplementary notification systems to make github
> > issues send additional emails that it is unable to send itself. We will
> > only support what GitHub supports. That means:
> > - You can subscribe to notification emails for activity in the entire
> > llvm-project repository.
> > - You can subscribe to notification emails on an individual issue.
> > - Someone else can CC you on an individual issue to get your attention, and
> > you will get notifications from that (unless you opt-out).
> > - No emails will be sent to llvm-b...@llvm.org
> > for github issues.
> > - There is no builtin way for users to subscribe to emails for bugs that
> > have a given label (for example, all "clang" issues, or all x86 issues).
> >
> > Further steps
> >
> > After we migrate, there's still things we want to do:
> >
> > 1. Discuss and setup new an
Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues
On 01/30/2020 10:24 AM, Aaron Ballman wrote:
> On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev
> 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-large projects
>>> using it quite successfully (e.g. rust-lang/rust) -- so I believe it should
>>> be good for us, as well. Importantly, Github Issues is significantly less
>>> user-hostile than our bugzilla is, for new contributors and downstream
>>> developers who just want to tell us about bugs!
>>>
>>>
>>> Proposal
>>>
>>> We propose to enable Github issues for the llvm-project repository in
>>> approximately two weeks from now, and instruct everyone to start filing new
>>> issues there, rather than in bugzilla.
>>>
>>> Some things we'd like to get in place before turning on Github's Issue
>>> tracker:
>>> 1. Updated documentation.
>>> 2. An initial set of issue tags we'd like to use for triaging/categorizing
>>> issues.
>>> 3. Maybe setup an initial issue template. Or maybe multiple templates. Or
>>> maybe not.
>>>
>>> But more important are the things we do /not/ want to make prerequisites
>>> for turning on Github issues:
>>>
>>> We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to migrate the
>>> existing issues to GitHub as a prerequisite for switching. We will thus
>>> expect that people continue using bugzilla for commenting on the existing
>>> bugs -- for the moment.
>>>
>>> We do /not/ want to build supplementary notification systems to make github
>>> issues send additional emails that it is unable to send itself. We will
>>> only support what GitHub supports. That means:
>>> - You can subscribe to notification emails for activity in the entire
>>> llvm-project repository.
>>> - You can subscribe to notification emails on an individual issue.
>>> - Someone else can CC you on an individual issue to get your attention, and
>>> you will get notifications fr
Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues
My concern about switching is that I will now need to use two issue
trackers instead of one when doing things like searching for related bugs.
~Aaron
On Thu, Jan 30, 2020, 1:31 PM Tom Stellard 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
> > 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-large
> projects using it quite successfully (e.g. rust-lang/rust) -- so I believe
> it should be good for us, as well. Importantly, Github Issues is
> significantly less user-hostile than our bugzilla is, for new contributors
> and downstream developers who just want to tell us about bugs!
> >>>
> >>>
> >>> Proposal
> >>>
> >>> We propose to enable Github issues for the llvm-project repository in
> approximately two weeks from now, and instruct everyone to start filing new
> issues there, rather than in bugzilla.
> >>>
> >>> Some things we'd like to get in place before turning on Github's Issue
> tracker:
> >>> 1. Updated documentation.
> >>> 2. An initial set of issue tags we'd like to use for
> triaging/categorizing issues.
> >>> 3. Maybe setup an initial issue template. Or maybe multiple templates.
> Or maybe not.
> >>>
> >>> But more important are the things we do /not/ want to make
> prerequisites for turning on Github issues:
> >>>
> >>> We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to
> migrate the existing issues to GitHub as a prerequisite for switching. We
> will thus expect that people continue using bugzilla for commenting on the
> existing bugs -- for the moment.
> >>>
> >>> We do /not/ want to build supplementary notification systems to make
> github issues send additional emails that it is unable to send itself. We
> will only support what GitHub supports. That means:
> >>> - You can subscribe to notification emails
Re: [lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues
On 01/30/2020 10:48 AM, Mehdi AMINI wrote:
> Hi,
>
>
>
>
> On Thu, Jan 30, 2020 at 10:21 AM 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.
>
>
> Do we have a way for individuals to get individually automatically subscribed
> on all the bugs created for a given tag?
> Mailing-lists seem fairly rigid in terms of granularity with respect to tags.
>
When I said cc lists, I really meant auto-subscribe lists, I didn't mean
that we would start sending issue emails to mailing lists.
From what I can tell, there are a couple different ways to auto-subscribe
people using github actions. I think the most simple would be to use
the assignee field, but I think it's also possible by @ mentioning people
directly in a comment or @ mentioning teams.
I was planning to experiment more with this over the next few days.
-Tom
> --
> Mehdi
>
>
>
>
>
>
> What does everyone think about this?
>
> -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-large
> projects using it quite successfully (e.g. rust-lang/rust) -- so I believe it
> should be good for us, as well. Importantly, Github Issues is significantly
> less user-hostile than our bugzilla is, for new contributors and downstream
> developers who just want to tell us about bugs!
> >
> >
> > Proposal
> >
> > We propose to enable Github issues for the llvm-project repository in
> approximately two weeks from now, and instruct everyone to start filing new
> issues there, rather than in bugzilla.
> >
> > Some things we'd like to get in place before turning on Github's Issue
> tracker:
> > 1. Updated documentation.
> > 2. An initial set of issue tags we'd like to use for
> triaging/categorizing issues.
> > 3. Maybe setup an initial issue template. Or maybe multiple templates.
> Or maybe not.
> >
> > But more important are the things we do /not/ want to make
> prerequisites for turning on Github issues:
> >
> > We do /not/ yet plan to turn off Bugzilla, and do /not/ plan to migrate
> the existing issues to GitHub as a prerequisite for switching. We will thus
> expect that people continue using bugzilla for commenting on the existing
> bugs -- for the moment.
> >
> >
[lldb-dev] [10.0.0 Release] Release Candidate 1 is here
Hello everyone, It took a bit longer than planned due to master being a somewhat unstable at the branch point, but Release Candidate 1 has now been tagged as llvmorg-10.0.0-rc1. Source code and docs are available at https://prereleases.llvm.org/10.0.0/#rc1 Pre-built binaries will be added there as they become available. Please file bug reports for any issues you find as blockers of https://llvm.org/pr44555 Release testers: please start your engines, run the script, share your results, and upload binaries. Release Candidate 2 was previously scheduled for February 2. Because of the late RC1, I've pushed this back a bit to the 11th. Thanks, Hans ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] Call for GSoC 2020 projects
Sure, feel free to propose a project! On Thu, Jan 30, 2020 at 12:55 PM David Tellenbach wrote: > Hi, > > sorry for the late response. Yes, my question is answered. > > I hadn't any doubt that LLVM will participate in GSoC and my question > aimed on knowing if it's too late to propose a project - sorry for being > unclear here. > > Thanks for organising LLVM's GSoC participation! > > Cheers, > David > > On 29. Jan 2020, at 11:24, Anton Korobeynikov > wrote: > > Hello David, > I believe Johannes already answered your questions, but just to > clarify the things fully: yes, we are going to submit an application > to participate in GSoC this year as usual. I will take care of > necessary paperwork and stuff. > Currently we're collecting the list of summer projects here and there. > It's perfectly fine to have the lists from sub-projects to be posted > on their respective websites as a part of corresponding "Open > Projects" pages. > On Fri, Jan 24, 2020 at 2:52 PM David Tellenbach > wrote: > > > > Hi all, > > > > may I ask about the current status of this? > > > > The deadline for organizations to apply is February 5, 2020; has an > application > > already been made? > > > > Another thing: https://llvm.org/OpenProjects.html states that MLIR > related > > projects can be found on > https://mlir.llvm.org/getting_started/openprojects/. I > > suggest adding these projects (including some more background > information) to > > our common list, just like other sub-projects do. > > > > Cheers, > > David > > > > > On 23. Dec 2019, at 11:00, Anton Korobeynikov via llvm-dev wrote: > > > > > > Dear prospective LLVM GSoC Mentors, > > > > > > The organization application period for GSoC 2020 will open on > > > January, 14. This means that we're having some time to prepare the > > > list of project ideas for the next year. > > > > > > When proposing the project please keep in mind the following criteria: > > > 1. The project should serve both LLVM as a project and provide the > > > relevant LLVM knowledge to the student. > > > 2. The project should contribute directly to LLVM, clang or LLVM > > > compiler infrastructure subproject (e.g. not related to some > > > out-of-tree 3rd party project just using LLVM). > > > 3. There should be well-defined scope of the project and some set of > > > "deliverables" at the end of the project. > > > 4. The project should be either developed in the LLVM mainline or be > > > ready to be committed to LLVM at the end of GSoC period. > > > > > > The Open Projects page was just updated to include the necessary > > > boilerplate, so feel free to propose the projects there. > > > > > > Thanks! > > > > > > -- > > > With best regards, Anton Korobeynikov > > > Department of Statistical Modelling, Saint Petersburg State University > > > ___ > > > LLVM Developers mailing list > > > llvm-...@lists.llvm.org > > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > > > -- > With best regards, Anton Korobeynikov > Department of Statistical Modelling, Saint Petersburg State University > > > -- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues
> Do we have a way for individuals to get individually automatically subscribed > on all the bugs created for a given tag? > Mailing-lists seem fairly rigid in terms of granularity with respect to tags. No, all notifications are essentially all-or-nothing thing. Github folks knows about this issue and planned to work on them, but there was no ETA on this. -- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues
> Will you be able to start numbering in github at a number larger than the > largest bug in bugzilla? It would be annoying to have overlapping bug > numbers. Bug numbers exist in code comments, list archives, etc., etc. If > someone reads 'clang bug #1234' somewhere it will be ambiguous, which would > be a real shame. This won't work in general, unfortunately as there are already a bunch of PRs and issues opened... And github uses consecutive numbering for all PRs, issues and such... So, there is already overlap here. -- With best regards, Anton Korobeynikov Department of Statistical Modelling, Saint Petersburg State University ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
Re: [lldb-dev] [llvm-dev] [cfe-dev] RFC: Switching from Bugzilla to Github Issues
I tend to support this – after 10.0.0 seems like a proper timeline.
And we already have some set of tags from bugzilla, so we could simply add them.
On Thu, Jan 30, 2020 at 8:49 PM David Major via llvm-dev
wrote:
>
> Would it make sense to wait until 10.0.0 is released, in order to keep all
> the blockers in one place?
>
>
>
> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev
> 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
>> > 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-large
>> >>> projects using it quite successfully (e.g. rust-lang/rust) -- so I
>> >>> believe it should be good for us, as well. Importantly, Github Issues is
>> >>> significantly less user-hostile than our bugzilla is, for new
>> >>> contributors and downstream developers who just want to tell us about
>> >>> bugs!
>> >>>
>> >>>
>> >>> Proposal
>> >>>
>> >>> We propose to enable Github issues for the llvm-project repository in
>> >>> approximately two weeks from now, and instruct everyone to start filing
>> >>> new issues there, rather than in bugzilla.
>> >>>
>> >>> Some things we'd like to get in place before turning on Github's Issue
>> >>> tracker:
>> >>> 1. Updated documentation.
>> >>> 2. An initial set of issue tags we'd like to use for
>> >>> triaging/categorizing issues.
>> >>> 3. Maybe setup an initial issue template. Or maybe multiple templates.
>> >>> Or maybe not.
>> >>>
>> >>> But more important are the things we do /not/ want to make prerequisites
>> >>> for turning on Github issues:
>> >>>
>> >>> We do /not/ yet plan to turn
