[lldb-dev] [cfe-dev] [llvm-dev] RFC: Switching from Bugzilla to Github Issues [UPDATED]

Wed Apr 29 13:19:57 PDT 2020

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-dev at 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-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/lldb-dev/attachments/20200429/e5948c09/attachment.html>