On Fri, 8 Apr 2011 18:24:03 +0100, Peter Maydell <peter.mayd...@linaro.org> wrote: > Sure. It does mean that fixing deficiencies in the system is more > important than if it's just collecting patches and only needs to > be interacted with by a few people.
Agreed. > It's a feature I'd really like to see, and upstream sounded > receptive to it: > http://lists.ozlabs.org/pipermail/patchwork/2011-January/000348.html > > so it would be great if we had the resources to do something here. Thanks for the reference. > Basically, some qemu patches I send just get committed, which > is the straightforward case. Some patches don't get any review > comments of any form, so they "time out" and I eventually try > to batch them up and resubmit them via a pull request. I want > to be able to distinguish the 'timed out' patches from the others. For your own benefit so that you know to send the pull request? It doesn't sound like we should track that for metrics? > I'm not wedded to this particular set of states but it might > be nice for my purposes to have a little more flexibility. > I'll have a go with the existing set of states for a bit and > that ought to give me a better idea of whether I really need more. That sounds good thanks. > You could mark the first patchset as 'superseded', I guess. With > the bulk-edit feature that's less effort than if it had to be done > one patch at a time. Yeah. It would be good to have "superseded by" for the metrics to do "time from first submission to acceptance" and "average number of re-works before acceptance" type things. > This case is currently sufficiently uncommon that I can probably live > with out of band tracking via wiki page if necessary. It would be nice > to know whether it's a '2 hours of coding' or '2 weeks of coding' level > feature though :-) I think that the difficulty here is that we are only tracking patches sent to patc...@linaro.org, not everything sent to the qemu list. I'm not sure how you would add someone else's patches to the system in this setup. You could send them to someone-elses-patc...@linaro.org, but then we have to have a split in the database to know whether to include patches in the metrics or not. Given this I'm not sure how much effort it would be for us, but I'm thinking that 2 weeks is a better estimate than 2 hours. Guilherme may be able to make a better assessment than me. > It's a bit variable, since I only usually have to try the pull-request > approach if other people upstream have been too busy to review/apply > anyway. It doesn't kick in often. Right, it's a little more nuanced that I thought. Thanks, James _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
