Sean Silva <silvas at purdue.edu> writes:
>> I think the main benefit of a scheme like this would be that a pull
request
>> tells a code owner which patches require their attention. As a
contributor
>> it would be nice to see your patch in a queue somewhere rather than
just be
>> buried down the mailing list. When patches are sent to llvm-commits it
can
>> be hard to tell if a code owner has noticed the patch because it is a
very
>> high-volume list.
>
> It might seem intimidating at first, but it will blow over really
> quick once you get one or two patches in and you learn how to do
> incremental development.
This is simply not true, IME.
> Ping at appropriate time intervals (~3 days is sane);
3 days is *not* sane. The fact that we require pings at all indicates a
broken process. I don't understand why there is such resistance to a
patch queue. I don't even care about the revision control system as
much as I do about a managed patch system. We have a system for bugs,
which are _much_ less frequent occurrences than patches.
I can't stall my work for 3 days waiting for someone not to see my
patch.
> I think the most pings I've seen before an answer is Ping^4 ("Fix
> cmake for Hexagon cross compilers"), and the reviewers were very
> apologetic about the situation.
The reviewers are *always* very apologetic. That doesn't help the
developer, unfortunately.
> Looking back at your submission history, it looks like your
> patches have been really "meaty" patches; by that I mean that
they
> affect core functionality and need a careful review by one of a small
> number of people who really understand that part of the code;
> understandably, these patches are more likely to go unanswered,
> especially if you haven't gotten a foothold in that part of the tree.
Why is that at alkl understandable? It's understandable that it might
take a while top review them but to not get an acknowledgement at all?
That is never understandable.
> It *would* be nice for a code-owner to have some way to see what needs
> to be reviewed, but a git mirror on github is not going to do that for
> them in any way.
Ok, so lets do it some other way.
-David