[LLVMdev] code-owner sporks
dag at cray.com
dag at cray.com
Fri Nov 16 15:50:52 PST 2012
Sean Silva <silvas at purdue.edu> writes:
>> - I have to *remember* I submitted the patch (not hard, but it is a
> If you forgot, the chances are high that the patch was unimportant. I
> do my development on local git branches, so every time I do `git
> branch`, I'm reminded. There's really no overhead.
Every time you have to check it's overhead. It may be small overhead,
but it's nonzero.
>> - I have to save that e-mail from llvm-commits so I can refer to it when
>> the inevitable ping is necessary.
> Maybe you need a better mail-reader? In gmail I just look in my "sent
> mail" or if I have sent a lot of mail recently I search "is:sent
> has:attachment". It literally takes 10 seconds.
Ok, I'll give you this one. :)
>> - I have to wade through tons and tons of commit e-mails searching for a
>> response to my patch (for some reason the mailing list software often
>> breaks threading). This is a more general problem with the current
>> review process, not strictly a timeliness issue.
> Sounds like you need a better mail reader. I have never heard of this
> even remotely being a problem in any way, at all, ever.
Really? You've never heard comments about the huge volume of mail on
llvm-commits? I just read another message about it today.
>> - I have to send a ping e-mail.
> Once again, this takes like what, 10 seconds? I find it highly
> unlikely that 10 seconds is a non-negligible amount of time compared
> to the time spent coding, building, and testing any non-obvious (i.e.
> needing review) change.
Again, it's non-zero. I have to break out of whatever I'm doing,
context switch and send the mail.
>> - Now I have to look for responses to *two* e-mails.
> You definitely need a better mail reader. In every mail reader I've
> ever seen, both mails get clustered into a thread. Maybe this is the
> root cause of your vehement dissatisfaction with the current
> email-based system?
Even if threads are clustered, one still has to look through tons of
subject lines to find it.
> Have you considered the amount of quality code that gets produced with
> the current process?
Code quality doesn't reflect how efficient the review system is. It
reflects how good the reviewers are and we are fortunate to have
I find llvm-commits daunting. So much that I hesitate to do reviews.
As Chris commented, I am not very active on that list. There's a reason
for that beyond lack of time. By definition, making the process simpler
and more organized should result in less time for reviews and thus
hopefully more review participation.
> What kind of improvements can we expect from such a system?
A one-stop shop for reviewers to find patches. Something searchable by
subsystem, file name, etc. I can't review every patch that goes by but
I certainly can review patches for files I'm currently working in. If I
could start my day by doing a patch search on whatever file I'm
currently working on, I'd make it a daily practice to do some reviews.
Right now that is tedious to do with e-mail.
> Are there advantages that email has over a more structured
> sort of review system like Phabricator?
I don't know. I would like to know if there are any. I suppose it's
super convenient to open the list of messages but beyond that I get
> Are you sure that the bottleneck
> which causes high review latency isn't elsewhere in the system?
Of course I'm not sure. I'm not sure anyone is sure. :) All I know is
that there's a problem.
> Or, as counterintuitive as it may seem, perhaps all of the things you
> are pointing to as problematic (e.g. review latency, patches getting
> dropped) are actually *beneficial* (maybe it prevents less-determined
> people from becoming contributors?
If that's our goal then I will just say right out it is not a good one.
More information about the llvm-dev