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
<llvm-...@lists.llvm.org> 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 
> <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
>> > <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 <http://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 
>> >>> <mailto: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-triage,
>> >>>  https://forge.rust-lang.org/release/triage-procedure.html#issue-triage).
>> >>>
>> >>> 2. Bug migration
>> >>>
>> >>> /After/ the initial switchover, we do want to investigate two 
>> >>> possibilities for migrating issues and turning off the bugzilla server. 
>> >>> I expect which one is chosen will come down mostly to feasibility of 
>> >>> implementation.
>> >>>
>> >>> Possibility 1: Migrate /all/ the existing bugs into a secondary 
>> >>> "llvm-bugs-archive" github repository, and then turn off bugzilla. 
>> >>> Github offers the ability to move bugs from one repository to another, 
>> >>> and so we can use this to move bugs that are still relevant afterwards 
>> >>> (potentially this could be done automatically upon any activity). Then, 
>> >>> shut down bugzilla, and leave behind only a redirect script.
>> >>>
>> >>> Possibility 2: Create the ability to import an individual bug from 
>> >>> Bugzilla into the llvm-project repository by pressing a "migrate this 
>> >>> bug to github" button. Then, leave bugzilla running only as a static 
>> >>> snapshot -- as static as possible while leaving the "migrate this bug to 
>> >>> github" button operational.
>> >>>
>> >>> In both cases, we'd want to support a redirect script to take you from 
>> >>> the old bug ids to the migrated bug page. In both cases, we would 
>> >>> /preserve/ the entire archive of existing bugs, but would not import the 
>> >>> entire set into the "llvm-project" github repository.
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> LLVM Developers mailing list
>> >>> llvm-...@lists.llvm.org
>> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >>>
>> >>
>> >> _______________________________________________
>> >> cfe-dev mailing list
>> >> cfe-...@lists.llvm.org
>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> >
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> 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

Reply via email to