On 04/21/2020 06:50 PM, Richard Smith wrote:
> On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev 
> <llvm-...@lists.llvm.org <mailto: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> 
> <mailto: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.)
> 

Having a new number scheme does not mean we have to break all the
llvm.org/PR#### links.  These could still be used to look up old
bugs even if we change bug notation to GH-####.

> 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.
> 

This is a good point and not something that I had thought of.
I think maintaining the bug links in the bugs is something that could
be done during the import.   e.g replace references to bug# xxxxx with
links to llvm.org/PRXXXX.  We will have to investigate this more.

Thanks,
Tom

> (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> 
> <mailto: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> 
> <mailto: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> <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> 
> <mailto: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> 
> <mailto: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> 
> <mailto: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> 
> <mailto: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 <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
> 

_______________________________________________
lldb-dev mailing list
lldb-dev@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev

Reply via email to