[llvm-dev] [cfe-dev] Phabricator -> GitHub PRs?
Doerfert, Johannes via llvm-dev
llvm-dev at lists.llvm.org
Wed Jan 15 19:45:06 PST 2020
On 01/15, Renato Golin wrote:
> On Wed, 15 Jan 2020 at 18:23, Doerfert, Johannes <jdoerfert at anl.gov> wrote:
> > That is not what I am saying, or at least you seem to interpret it
> > differently than I indented it to be read. In the part you cropped I
> > mention that *both sides* provide *helpful advice* to improve the setup
> > of people. I argue the problems need to be clarified for that. *Forcing
> > to worsen* happens when we say we *move* but also when we *do not move*.
> > Emails that just say we should move or not are therefore problematic.
> So far I have seen good and bad arguments on both sides, but you keep
> saying no one is providing good arguments on the other side.
I did not try to say that and I do not recall what I said that could be
interpreted as such. I don't think the above contains such a claim, nor
could I find such a claim in the last email I send. If you interpret
what I wrote in such a way I can understand why you might be upset.
Please feel free to point out things I could formulate better to avoid
making this impression, either via the list or in a private mail.
> It seems to me that the arguments against Phab are not a problem for
> you, or you have a solution that works for you, and are therefore, not
> good enough as an argument (or you need better ones).
I actually did not try to argue for Phab even though I am fairly happy
with Phab. I did questions the reason for a move and I asked for
problems to be described (by either side) so we can find solutions.
Whenever I said that something is not a problem for me I explained
myself, e.g., my setup. I also explained how I use Phab, and given that
I don't know enough about GH PRs, I did not attack it willingly.
> What I'm saying is that the solutions you have may not be relevant or
> good enough to them, and don't solve their problem.
Sure. What I'm saying is that we should try to offer them in a
constructive way nevertheless.
> In the end, both GitHub and Phab have benefits and problems, and this
> will be more a choice of opinion than technical.
> Trying to invalidate opinions just because they're not a big deal for
> you is not helpful.
> I spent many years doing code review on emails, then even more on
> Phab, GitHub, Gerrit. My personal opinion is that GitHub is the least
> bad in user experience, but also the simplest one, and not in the best
> way. But the best part for me is that I can do almost everything from
> the command line, using just plain git. That improves my productivity
> Phab is a major pain for me because I have trouble remembering all the
> bells and whistles. I tried getting Arcanist to work, then it stops
> working, then I have to do it all over again. The UI is super
> counter-intuitive to me and even having used it for many years, it's
> still alien. I make many mistakes, random ones, and that makes me
> spend less time reviewing LLVM patches, not more.
> It may be a problem just for me, maybe it's to do with how my brain is
> wired, which granted, is a minority. That's why I have accepted it as
> a fact of life to use Phab. But if there are people out there that
> feel like me, then well, I'll support.
> Regarding actual issues, we had enough already on both sides, I agree
> with most of them, and I have already stated some myself. Tooling is
> one of them, so proposing a tooling fix won't help me. i have to work
> on multiple different environments, from Arch Linux, to Ubuntu, WSL
> and Windows and no single tool, other than Git, can support the same
> framework across the board (or at least it would be a massive job).
> So, my vote is for *any* review process that I can do via Git, with
> minimal use of web interfaces or specialised tools.
> But I'm happy with whatever makes most people's lives easier. If
> that's Phab, phab. I'll keep scratching my nails on the blackboard.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 228 bytes
Desc: not available
More information about the llvm-dev