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? Could you help give some example use cases that require having a non-intersecting set of bug numbers for bugzilla bugs and github issues? -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> 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 > _______________________________________________ lldb-dev mailing list lldb-dev@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
