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
> t
> 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, whi
> 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
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 -
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
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
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
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 t
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 swit
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
> functionali
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.
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.
12 matches
Mail list logo
