> Really, patches get dropped *all the time* to the point where pings are > a regular part of the development process. That's a huge waste of time > for everyone.It's only a waste of time if your workflow is entirely synchronous with patch review. Most of us have a number of things that we can work on, so letting a patch chill for a while on the list isn't a big deal because we just go on and do something else. Also, this situation has piqued my interest and so I am researching the issues involved. Could you give me some links (or thread titles) for dropped patches, so that I can take a look at them and try to puzzle out how the development process ended up in them being dropped? Nothing big, maybe 5 or so is probably enough. Thanks. -- Sean Silva On Fri, Nov 16, 2012 at 4:11 PM, <dag at cray.com> wrote:> Eric Christopher <echristo at gmail.com> writes: > >> This is right. The highest barrier to entry for patches is that >> they >> are not seen. >> >> >> >> >> This is opinion. I see everyone's patches, but my review time is >> precious and the patch may not hit the criteria of what I'm willing to >> spend my time on. > > That's valid, but code owners should at least acknowledge the patch and > say, "I don't have time to review this" with some estimate of how long > it might take before they get around to it. I say "code owners" because > we shouldn't require everyone on the list to acknowledge a patch they > won't review. :) > > As a contributor, my time is precious too. I would like to have some > way of knowing that *someone* is looking at the patch, that it hasn't > just dropped on the floor. A patch queue would at least allow me to > track progress and not have to save a bunch of e-mails of patches I > submitted and need to ping four days from now. > > Really, patches get dropped *all the time* to the point where pings are > a regular part of the development process. That's a huge waste of time > for everyone. > > -David > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
Sean Silva <silvas at purdue.edu> writes:>> Really, patches get dropped *all the time* to the point where pings are >> a regular part of the development process. That's a huge waste of time >> for everyone. > > It's only a waste of time if your workflow is entirely synchronous > with patch review. Most of us have a number of things that we can work > on, so letting a patch chill for a while on the list isn't a big deal > because we just go on and do something else.Of course, that's easier with git. :)> Also, this situation has piqued my interest and so I am researching > the issues involved. Could you give me some links (or thread titles) > for dropped patches, so that I can take a look at them and try to > puzzle out how the development process ended up in them being dropped? > Nothing big, maybe 5 or so is probably enough. Thanks.Really? Ok... http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121105/155173.html Ping Request (couldn't find an actual review) http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121105/155174.html Ping Request (couldn't find an actual review) http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121105/155233.html Never reviewed? http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121105/155267.html Never reviewed? http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121105/155318.html Ping Request (looks like it got reviewed shortly after the ping) http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121105/155389.html Reviewed five days later (I think). The mailing list interface makes it difficult to look for the things you requested, but all of these examples occurred just last week. -David
<dag at cray.com> writes:> Sean Silva <silvas at purdue.edu> writes: > >>> Really, patches get dropped *all the time* to the point where pings are >>> a regular part of the development process. That's a huge waste of time >>> for everyone. >> >> It's only a waste of time if your workflow is entirely synchronous >> with patch review. Most of us have a number of things that we can work >> on, so letting a patch chill for a while on the list isn't a big deal >> because we just go on and do something else. > > Of course, that's easier with git. :)Just to follow up, I agree that people shouldn't be stuck for days waiting for their patch to be reviewed. The cost is more subtle than that. - I have to *remember* I submitted the patch (not hard, but it is a cost). - I have to save that e-mail from llvm-commits so I can refer to it when the inevitable ping is necessary. - 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. - I have to send a ping e-mail. - Now I have to look for responses to *two* e-mails. In short, e-mail is a very poor vehicle for managing this kind of process. I hope that the patch queue in testing helps alleviate the poor response time problem. Even just an acknowlegement, "hey I got your patch but it will be a few days before I can review it", would help a lot. -David