[Openmp-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]
Philip Reames via Openmp-dev
openmp-dev at lists.llvm.org
Wed Apr 22 14:52:29 PDT 2020
On 4/22/20 2:35 PM, Richard Smith wrote:
> On Wed, 22 Apr 2020 at 09:45, Philip Reames via cfe-dev
> <cfe-dev at lists.llvm.org <mailto: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 <mailto: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>
>> <mailto: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.
We have an auto-updater for most llc scripts, but point taken. My main
point was this was one time, not that the one time was trivial.
>
> (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 :)]
Agreed, history rewrite as a solution here should be rejected out of
hand. :)
>
>> 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>
>> <mailto: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>
>> <mailto: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>
>> <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>
>> <mailto: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>
>> <mailto: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>
>> <mailto: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>
>> <mailto: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
>> >
>>
>> _______________________________________________
>> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/openmp-dev/attachments/20200422/020635a5/attachment-0001.html>
More information about the Openmp-dev
mailing list