[cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues
Whisperity via cfe-dev
cfe-dev at lists.llvm.org
Thu Mar 26 02:27:07 PDT 2020
They're not. Each repository(!) has its own autoincrement number for issues
and pull requests – together. This also means issues in forks are numbered
separately. To cross-reference, we can use the "owner/repo#xx" format,
which on GitHub creates a clickable link. Outside GitHub, the user-friendly
option is most likely only a full URL being pasted. The former version is
understood by GitHub as a reference and will create a note in the referred
issue to the referring one.
On Thu, 26 Mar 2020, 03:38 Hubert Tong via cfe-dev, <cfe-dev at lists.llvm.org>
wrote:
> On Wed, Mar 25, 2020 at 7:41 PM Tom Stellard via cfe-dev <
> cfe-dev at lists.llvm.org> wrote:
>
>> On 03/16/2020 07:53 AM, Aaron Ballman wrote:
>> > On Mon, Mar 16, 2020 at 10:44 AM Tom Stellard via cfe-dev
>> > <cfe-dev at 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. 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.
>>
>> Is there anything we could do to make having active issues in both
>> trackers easier to deal with?
>>
> You asked for if there was "anything". I am not sure how feasible a
> unified full text search and view portal would be. Also, I had already
> suggested that there should be an agreed convention on how to refer to bugs
> in either. If GitHub issues are not uniquely numbered across "projects"
> (meaning non-monorepo projects get their own "namespace"), then that
> convention might be ugly.
>
>
>>
>> -Tom
>>
>> >
>> > ~Aaron
>> >
>> >>
>> >> Thanks,
>> >> Tom
>> >>
>> >>
>> >>> -Tom
>> >>>
>> >>>>
>> >>>>
>> >>>> On Thu, Jan 30, 2020 at 1:32 PM Tom Stellard via llvm-dev <
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at 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-dev at lists.llvm.org <mailto:cfe-dev at 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> <
>> 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-bugs at llvm.org <mailto:
>> llvm-bugs at llvm.org> <mailto:llvm-bugs at llvm.org <mailto:llvm-bugs at 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-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> >>>> >>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >>>> >>>
>> >>>> >>
>> >>>> >> _______________________________________________
>> >>>> >> cfe-dev mailing list
>> >>>> >> cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>
>> >>>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> >>>> >
>> >>>>
>> >>>> _______________________________________________
>> >>>> LLVM Developers mailing list
>> >>>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
>> >>>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >>>>
>> >>>
>> >>
>> >> _______________________________________________
>> >> cfe-dev mailing list
>> >> cfe-dev at lists.llvm.org
>> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>> >
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200326/b8fab784/attachment-0001.html>
More information about the cfe-dev
mailing list