On 4/22/20 2:35 PM, Richard Smith wrote:
On Wed, 22 Apr 2020 at 09:45, Philip Reames via cfe-dev
<cfe-...@lists.llvm.org <mailto: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 <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.)
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.
We have an auto-updater for most llc scripts, but point taken. My main
point was this was one time, not that the one time was trivial.
(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 :)]
Agreed, history rewrite as a solution here should be rejected out of
hand. :)
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>
<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
_______________________________________________
cfe-dev mailing list
cfe-...@lists.llvm.org <mailto: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
