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

2020-04-21 Thread Richard Smith via lldb-dev
On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev < 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 < > cfe-...@lists.llvm.org > wrote: > > > > +1 to Jam

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

2020-04-21 Thread Tom Stellard via lldb-dev
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 n

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

2020-04-21 Thread 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 pr

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

2020-04-21 Thread Richard Smith via lldb-dev
On Tue, 21 Apr 2020 at 11:04, Philip Reames via cfe-dev < 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

[lldb-dev] LLVM 10.0.1 Release Schedule

2020-04-21 Thread Tom Stellard via lldb-dev
Hi, Here is the proposed 10.0.1 release schedule. If there are no objections, I'll put it on the website. May 18: 10.0.1-rc1 Jun 18: 10.0.1-rc2 Jun 25: 10.0.1-final -Tom ___ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin

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

2020-04-21 Thread 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 g

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

2020-04-21 Thread David Blaikie via lldb-dev
All things being equal, I'd prefer Richard Smith's proposal that doesn't involve needing a new/old numbering scheme, but lets us keep a single numbering/redirection (& I doubt we need the first 200 bugs in any case - has anyone referred to bugs that early in the last 5 years, say? But wouldn't mind

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

2020-04-21 Thread Anton Korobeynikov via lldb-dev
Hi James, > Please could we replace the "llvm-tools" with a single label for each LLVM > tool (i.e. labels for llvm-ar, llvm-as, llvm-cxxfilt, llvm-objdump etc etc). Sorry, I missed the subcomponents for the tools when I did the migration of the labels. Will add them! -- With best regards, Anto

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

2020-04-21 Thread James Henderson via lldb-dev
Please could we replace the "llvm-tools" with a single label for each LLVM tool (i.e. labels for llvm-ar, llvm-as, llvm-cxxfilt, llvm-objdump etc etc). As mentioned on multiple occasions now, this is much more user-friendly both for people filing issues, and for those like myself who are only inter

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

2020-04-21 Thread Anton Korobeynikov via lldb-dev
> On 04/20/2020 04:08 PM, James Y Knight 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 d