On Wed, 22 Apr 2020 at 09:45, Philip Reames via cfe-dev < cfe-...@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-...@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 <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 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-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org>> wrote: >> >> >> >> On Mon, 20 Apr 2020 at 12:31, Tom Stellard via llvm-dev < >> llvm-...@lists.llvm.org <mailto:llvm-...@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-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> >> >> >> >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> llvm-...@lists.llvm.org <mailto:llvm-...@lists.llvm.org> >> >> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >> > _______________________________________________ >> > cfe-dev mailing list >> > cfe-...@lists.llvm.org <mailto: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 >> > _______________________________________________ > cfe-dev mailing list > cfe-...@lists.llvm.org > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev >
_______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
