Generally sounds pretty good to me - only variation on the theme (& certainly imho dealer's choice at this point - if you/whoever ends up doing this doesn't like the sound of it, they shouldn't feel they have to do it this way) - maybe creating blank issues up to the current bugzilla PR number (& maybe some padding) in a single/quick-ish (no idea how quickly those can be created) window might help reduce the need for race conditions/shutting down bug reporting, etc
On Wed, Apr 29, 2020 at 8:25 AM Tom Stellard via cfe-dev < cfe-...@lists.llvm.org> wrote: > Hi, > > Thanks to everyone who provided feedback. I would like to propose a > more detailed plan based on the everyone's comments. It seems like there > was a strong > preference to maintain the bug ID numbers, so this proposal tries to > address that. > > TLDR; This proposes to maintain bug ID numbers by overwriting existing > GitHub issues > instead of creating new ones. e.g. github.com/llvm/llvm-project/issues/1 > will > be overwritten with data from llvm.org/PR1. There will be some bugs that > end up having their data copied into pull requests, which may be strange, > but the data will be preserved and the IDs will be preserved and this would > only happen to very old bugs. > > Proposal: > > Detailed steps for doing the migration: > > > * Weeks or days before the migration: > > 1. Create a new GitHub repository called llvm-bug-archive and import bug > data from bugzilla. > > This step should not be under any kind of time pressure, so that the > conversion > process can be debugged and refined. > > 2. Install label notification system using GitHub actions and enable web > hook > to send emails to llvm-bugs list. > > * Day before the migration: > > 3. Make bugzilla readonly. > > 4. Import any new bugs created since the last import. > > There may be commit access disruption during the migration, so > completing these steps the day before will limit the amount of down time. > > 5. Temporarily re-enable issues in the llvm-project repo and copy existing > issues > to the llvm-bug-archive repo so they get higher IDs numbers than any > existing PR. Disable issues when done. > > Note that we will copy issues instead of moving them, which means the > original > issue will remain in tact. This will allow us to retain the bug IDs > for future use and not 'lose' a bug ID. > > * Day of migration: > > 6. Lockdown the repo as much as possible to prevent people from creating > issues or pull requests. > > Temporarily making the repo private may be one way to achieve this. Other > suggestions welcome. > > 7. Copy issues with overlapping issues IDs from the llvm-bug-archive repo > into the llvm-project repo. > > Issues from the llvm-bug-archive repo that have the same ID number as > existing issues in the llvm-project repo will be manually copied from > the former to the later. This will allow us to preserve the PR numbers > from bugzilla. Here is an example for how this would work: > > - Delete comments and description from llvm-project issue #1. > - Copy comments and description from llvm-bug-archive issue #1 into > llvm-project issue #1. > > Since GitHub issue and pull requests share the same numbering sequence, any > PR# from bugzilla that maps to a pull request in the llvm-project repo will > need to have it's comments copied into a pull request. These issues will > look slightly > strange since there will be random commits attached to the issue. However, > all data will be preserved and more importantly the bug ID will be > preserved. > > The issues URL can be used to access pull requests e.g. > pull request #84 is accessible via github.com/llvm/llvm-project/issues/84 > so even with bugzilla data stored in pull requests, we will still be able > to do a simple redirect > from llvm.org/PR### <http://llvm.org/PR#%23%23> to > github.com/llvm/llvm-project/issues/### > <http://github.com/llvm/llvm-project/issues/#%23%23> > > > 8. Once all the overlapping Issue IDs have been copied. Move the rest of > the issues > from the llvm-bug-archive repo to the llvm-project repo. > > This should be faster than doing the copies since we do not need to > overwrite existing > issues and can just move the issues from one repo to the other. > > The end result of this is that we have all the old bugs from bugzilla > present as issues > in the llvm-project repository with all of their ID numbers preserved. > > > * Other action items: > > - We need volunteers to help create bug templates to simplify the process > of submitting > bugs. If you are interested in helping with this, let me know. > > - Continue to iterate on the set of issue labels. This should not block > the migration since > labels can be changed at any time, but there were some suggested > improvements that should > be discussed. > > > Please reply to this proposal with your questions, comments, praise, or > concerns. > > Thanks, > Tom > > > [1] > https://help.github.com/en/github/building-a-strong-community/about-issue-and-pull-request-templates > > > > > On 04/20/2020 12:30 PM, Tom Stellard via llvm-dev 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. > > > > > > 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 > > 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