[cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
Richard Smith via cfe-dev
cfe-dev at lists.llvm.org
Wed Apr 22 14:35:02 PDT 2020
On Wed, 22 Apr 2020 at 09:45, Philip Reames via cfe-dev <
cfe-dev at lists.llvm.org> wrote:
> On 4/21/20 6:50 PM, Richard Smith wrote:
>
> On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev <
> llvm-dev at 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-dev at lists.llvm.org <mailto:cfe-dev at 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 worth some investment now
>> to avoid that problem. And it doesn't seem like it really requires much
>> investment.
>> >
>> > Here's another path we could take:
>> >
>> > 1) Fork the llvm repository to a private "bugs" repository. Mirror the
>> bugzilla issues there. Iterate until we're happy, as per James's proposal.
>> > 2) Sync the forked repository to the llvm repository, delete the llvm
>> repository, rename "bugs" to "llvm", and make it public.
>> >
>> > Then we'll have the first N bugs in llvm-project/llvm being *exactly*
>> the bugzilla bugs, and we'll have excised the existing github issues that
>> we want to pretend never existed anyway.
>> >
>> >
>> > I think we've missed an important step in the planning here: we've not
>> agreed on a set of goals for the transition. Here are mine:
>> >
>> > * We end up with one single issue tracking system containing all
>> issues, both old and new, both open and closed.
>> > * All links and references to existing bugs still work.
>> > * We have a single bug numbering system covering all bugs, and old
>> bugs retain their numbers.
>>
>> Why are the bug numbers important?
>
>
> These numbers appear all over our codebase. PR[0-9] appears 3592 times in
> Clang testcases, plus 45 times in Clang source code and 119 times more as
> the file names of Clang testcases. If we add inconvenience to looking up
> all of those, that makes maintenance harder each time someone wants to look
> one of those up. (That's probably a ~weekly occurrence for me.)
>
> For this use case, a simple script and bulk change to update references in
> source repo means the numbering can change arbitrarily. ~4k small
> mechanical changes is just not that much to review for a one time update
> assuming you trust the number remapping script and are just looking for
> overly aggressive regex matches.
>
It's not quite as straightforward as you're suggesting: such a simple
script would break a bunch of our CodeGen tests that match mangled names,
if the length of any bug identifier changes. A grep for '_Z.*PR[0-9]'
indicates that there are at least 254 of those that might need manual
updating if we took this path.
(I don't have any quick fixes for your other mentioned cases.)
>
Another case I didn't think of before, but that seems very important: bug
numbers appear in commit messages, and are primary context in understanding
what the commit is doing and why. [We *could* go on a bulk history editing
spree to fix those commit messages up (git filter-branch actually makes
this fairly easy) -- but that too would create a little churn as everyone
would needs to rebase all their work in progress on the rewritten master,
and honestly, that sounds a lot scarier than any of the other things we've
considered in this thread :)]
Also, bug numbers appear in other bugs. I would assume we're not going to
> be able to reliably figure out which numbers appearing in a bug are bug
> numbers during the import process, so those numbers will persist into the
> github issues world.
>
> (In addition, I'm sure multiple groups have their own tracking systems,
> web pages, documentation, etc. that contain references to LLVM PR numbers.
> But maybe we shouldn't worry too much about that.)
>
> Could you help give some example use cases that require having
>> a non-intersecting set of bug numbers for bugzilla bugs and github issues?
>>
>
> It makes conversing about bug numbers more difficult if you need to
> clarify which system you're talking about. As a minor example, we'd have to
> avoid saying "PR" for the new system in order to avoid confusion, and get
> used to some new terminology, and probably not use "bug 1234" to describe
> either system, because that would be ambiguous. None of these individual
> factors seems like a huge disruption, but they all seem like inconvenience
> we should prefer to avoid if possible.
>
> -Tom
>>
>>
>> >
>> > It sounds like we don't all agree that the last point is important, but
>> if we can achieve it without any significant additional cost, why not do so?
>> >
>> > 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 github. This has a few benefits:
>> >> 1. If the migration is messed up, the repo can be deleted, and the
>> process run again, until we get a result we like.
>> >> 2. The numbering can be fully-controlled.
>> >> Once the bugs are migrated to /some/ github repository, individual
>> issues can then be "moved" between repositories, and github will redirect
>> from the movefrom-repository's bug to the target repository's bug.
>> >>
>> >> We could also just have llvm.org/PR### <http://llvm.org/PR#%23%23>
>> <http://llvm.org/PR#%23%23> be the url only for legacy bugzilla issue
>> numbers -- and have it use a file listing the mappings of bugzilla id ->
>> github id to generate the redirects. (GCC just did this recently for svn
>> revision number redirections,
>> https://gcc.gnu.org/pipermail/gcc/2020-April/232030.html).
>> >>
>> >> Then we could introduce a new naming scheme for github issue
>> shortlinks.
>> >>
>> >> On Mon, Apr 20, 2020 at 3:50 PM Richard Smith via llvm-dev <
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> >>
>> >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev <
>> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote:
>> >>
>> >> Hi,
>> >>
>> >> I wanted to continue discussing the plan to migrate from
>> Bugzilla to Github.
>> >> It was suggested that I start a new thread and give a
>> summary of the proposal
>> >> and what has changed since it was originally proposed in
>> October.
>> >>
>> >> == Here is the original proposal:
>> >>
>> >>
>> http://lists.llvm.org/pipermail/llvm-dev/2019-October/136162.html
>> >>
>> >> == What has changed:
>> >>
>> >> * You will be able to subscribe to notifications for a
>> specific issue
>> >> labels. We have a proof of concept notification system
>> using github actions
>> >> that will be used for this.
>> >>
>> >> * Emails will be sent to llvm-bugs when issues are opened
>> or closed.
>> >>
>> >> * We have the initial list of labels:
>> https://github.com/llvm/llvm-project/labels
>> >>
>> >> == Remaining issue:
>> >>
>> >> * There is one remaining issue that I don't feel we have
>> consensus on,
>> >> and that is what to do with bugs in the existing
>> bugzilla. Here are some options
>> >> that we have discussed:
>> >>
>> >> 1. Switch to GitHub issues for new bugs only. Bugs filed
>> in bugzilla that are
>> >> still active will be updated there until they are closed.
>> This means that over
>> >> time the number of active bugs in bugzilla will slowly
>> decrease as bugs are closed
>> >> out. Then at some point in the future, all of the bugs
>> from bugzilla will be archived
>> >> into their own GitHub repository that is separate from the
>> llvm-project repo.
>> >>
>> >> 2. Same as 1, but also create a migration script that
>> would allow anyone to
>> >> manually migrate an active bug from bugzilla to a GitHub
>> issue in the llvm-project
>> >> repo. The intention with this script is that it would be
>> used to migrate high-traffic
>> >> or important bugs from bugzilla to GitHub to help increase
>> the visibility of the bug.
>> >> This would not be used for mass migration of all the bugs.
>> >>
>> >> 3. Do a mass bug migration from bugzilla to GitHub and
>> enable GitHub issues at the same time.
>> >> Closed or inactive bugs would be archived into their own
>> GitHub repository, and active bugs
>> >> would be migrated to the llvm-project repo.
>> >>
>> >>
>> >> Can we preserve the existing bug numbers if we migrate this
>> way? There are lots of references to "PRxxxxx" in checked in LLVM artifacts
>> and elsewhere in the world, as well as links to llvm.org/PRxxxxx <
>> http://llvm.org/PRxxxxx>, and if we can preserve all the issue numbers
>> this would ease the transition pain substantially.
>> >>
>> >>
>> >> The key difference between proposal 1,2 and 3, is when
>> bugs will be archived from bugzilla
>> >> to GitHub. Delaying the archiving of bugs (proposals 1
>> and 2) means that we can migrate
>> >> to GitHub issues sooner (within 1-2 weeks), whereas trying
>> to archive bugs during the
>> >> transition (proposal 3) will delay the transition for a
>> while (likely several months)
>> >> while we evaluate the various solutions for moving bugs
>> from bugzilla to GitHub.
>> >>
>> >>
>> >> The original proposal was to do 1 or 2, however there were
>> some concerns raised on the list
>> >> that having 2 different places to search for bugs for some
>> period of time would
>> >> be very inconvenient. So, I would like to restart this
>> discussion and hopefully we can
>> >> come to some kind of conclusion about the best way forward.
>> >>
>> >> Thanks,
>> >> Tom
>> >>
>> >> _______________________________________________
>> >> 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
>> >>
>> >> _______________________________________________
>> >> 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
>> >>
>> >>
>> >> _______________________________________________
>> >> 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
>> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>> >
>>
>> _______________________________________________
>> LLVM Developers mailing list
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20200422/7a9499db/attachment-0001.html>
More information about the cfe-dev
mailing list