similar to: RFC: Bugzilla migration plan

> On Fri, 10 Jul 2020 at 09:11, Anton Korobeynikov via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > 3. Wipe existing issues and pull requests > Does this really wipes the "auto-increment" IDs used by PRs and issues > and starts from zero again? I will need to clarify whether we will be able to reset the counter or not > > 4. Migrate all issues from

On 4/21/20 7:00 PM, Tom Stellard via llvm-dev 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-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: >> >> +1 to James's take >> >> I'd prefer simplicity of implementation over perfection here.

On 6/22/20 2:34 AM, Manuel Klimek via llvm-dev wrote: > On Sat, Jun 20, 2020 at 1:45 AM Zachary Turner via llvm-dev > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > There’s also some feature regressions in GH vs Phab. > > You *must* initiate a review via a pull request, and pull request > by definition compares your working

How much ongoing work do you estimate Phabracitor requires? There’s the times the server falls over (e.g. database exceptions) and needs to be revived, there’s updates to Phabricator itself, there’s keeping the server updated, and probably a bunch of other work I’m not thinking of. About how much of a time commitment would keeping Phabricator going be, in your estimation? From: llvm-dev

On 05/01/2020 01:40 PM, Wyatt Childers via llvm-dev wrote: > I agree with everything said here, to me this seems like the most sane option. It seems like this approach could also be tested at a smaller scale if there are concerns about deleting a repo, to see if there is any observable effect. > > While I haven't performed this particular trick on Github, based on my experience

There’s also some feature regressions in GH vs Phab. You *must* initiate a review via a pull request, and pull request by definition compares your working copy against master. This is not very compatible with LLVMs approach to incremental development. For example, if you ask someone to break a large patch into 5 smaller patches, with Phab this is very easy because you can upload the diff

On Sat, Jun 20, 2020 at 1:45 AM Zachary Turner via llvm-dev < llvm-dev at lists.llvm.org> wrote: > There’s also some feature regressions in GH vs Phab. > > You *must* initiate a review via a pull request, and pull request by > definition compares your working copy against master. > > This is not very compatible with LLVMs approach to incremental > development. For

On Thu, Jun 25, 2020 at 2:43 AM Nikita Popov <nikita.ppv at gmail.com> wrote: > On Thu, Jun 25, 2020 at 11:22 AM Zachary Turner via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I can’t really provide a doc, but i can describe what I believe to be the >> biggest problem. >> >> In a GH PR, comments are associated with commit hashes. If a commit

On 01/22, David Greene via cfe-dev wrote: > Renato Golin via cfe-dev <cfe-dev at lists.llvm.org> writes: > > >> My understanding from other people's comments (I've not tried it myself) is that updating a patch series in github is problematic - that it sends new/separate review email rather than being able to associate each patch in the series with ongoing review

I can’t really provide a doc, but i can describe what I believe to be the biggest problem. In a GH PR, comments are associated with commit hashes. If a commit hash ceases to exist, so do all comments associated with it. The comments are quite literally destroyed and irretrievable. What this means for LLVM is that everyone will have to completely stop using history rewriting operations. No

On 01/24, Renato Golin wrote: > On Fri, 24 Jan 2020 at 17:11, Doerfert, Johannes <jdoerfert at anl.gov> wrote: > > As I understand it, the GH model is to amend a new commit to your PR > > which addresses the review comments. The "problem" is that "we" are used > > to the force push model in which each commit is always as "clean and self > >

> Will you be able to start numbering in github at a number larger than the largest bug in bugzilla? It would be annoying to have overlapping bug numbers. Bug numbers exist in code comments, list archives, etc., etc. If someone reads 'clang bug #1234' somewhere it will be ambiguous, which would be a real shame. This won't work in general, unfortunately as there are already a

On Tue, 21 Apr 2020 at 17:00, Tom Stellard via llvm-dev < llvm-dev at 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-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > > > > +1 to James's take > > > > I'd

On Fri, Jun 19, 2020 at 4:23 PM Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > I use GH daily at my current employer and i can tell you that the issues with rebasing are very real. Unless you only use merge commits you are going to have a very bad time Would it be practical to use merge commits during review (never rebasing) & then rebasing/squashing to

On Thu, 16 Jan 2020 at 19:10, David Blaikie <dblaikie at gmail.com> wrote: > Can you point to examples of that - where Phab links have been used to express non-mechanically-dependent patches? Not at the top of my head, but since that's not what we're talking about, I'll go to the next point. > Approval order isn't commit order - I'm more than happy to approve a

On 03/16/2020 08:00 AM, James Henderson wrote: > > > On Mon, 16 Mar 2020 at 14:44, Tom Stellard via cfe-dev <cfe-dev at lists.llvm.org <mailto:cfe-dev at lists.llvm.org>> wrote: > > On 02/10/2020 07:40 PM, Tom Stellard wrote: > > On 01/30/2020 12:47 PM, David Major wrote: > >> Would it make sense to wait until 10.0.0 is released, in order to

> If we are reasonably certain that no one would be opening new issues on GitHub while the migration is running... And pull requests (the numbering is common for issues and pull requests) as well. And we cannot disable pull requests at all. And I'm afraid the issues will need to be opened as well during the migration. And now the real problem: should an "extra" pull request or

On Tue, 28 Jan 2020 at 12:28, Nicolai Hähnle <nhaehnle at gmail.com> wrote: > I don't quite follow. Yes, gratuitous useless changes tend to create > merge and rebase problems and should generally be avoided. Why does it > make a difference whether they're in multiple commits though? I think you misunderstood. Our policy [1] is that independent NFC fixups on existing code

On Thu, Jan 30, 2020 at 1:21 PM Tom Stellard via cfe-dev <cfe-dev at lists.llvm.org> wrote: > > On 10/24/2019 07:54 PM, James Y Knight via llvm-dev wrote: > > We held a round-table at the llvm dev conference about what other pieces of Github infrastructure we may want to use. This thread in particular is about switching to github issue tracking. Use of other parts of Github