On Fri, 8 Apr 2011 16:41:26 +0100, Peter Maydell <peter.mayd...@linaro.org> wrote: > On 8 April 2011 15:14, James Westby <james.wes...@linaro.org> wrote: > > This service is going to be used by management to get an idea of the > > number of patches going to each project over time, the number of patches > > submitted upstream by each team over time, the % of patches accepted > > upstream, the average time from submission to acceptance for each > > project, and other things like that. > > > > For this to work well, and for your work to be accurately counted, you > > are going to be expected to keep it up to date as you submit patches > > upstream. > > Hmm, that's higher-maintenance than the original "just cc this email > address" proposal.
Yes, but a system that only has that information can never provide all of the statistics that I outlined above. > In that case I'd like it to be able to replace my > manual wiki-based qemu patches page: > https://wiki.linaro.org/PeterMaydell/QemuPatchStatus > > Missing features for that: > * ability to deal with whole patchsets as a single 'line item' > in patchwork, so you can move a 10-patch patchset from state to > state without it being a huge amount of drudgery It can do this. It currently requires you to click to link the patches from the set, but we've discussed ways to do this automatically in most cases. I'm not sure if we have specific plans to improve this currently though. > For bonus marks, patchwork ought to keep the 'cover letter' email > which is the one which actually ties the patchset together and > gives the rationale... I can't say whether it does that or not, Guilherme? > * missing statuses for tracking patch progress; at the moment > patch lifecycle for me is: > 'waiting for review' > 'will put into next pull request' > 'pull request sent, not committed' It's not clear to me what these statuses mean? The patch is reviewed, and once it is accepted it then goes in to a pull request and is committed that way? > 'committed' > not all of which have patchwork statuses. There's also > 'picked up by another submaintainer but not committed yet'. > I guess I could bodge some of the existing ones like 'awaiting > upstream' for at least one of these. Yeah, it sounds like an "approved but not committed" state that would apply to most projects. If it is important for you to differentiate then we could add the extra states and map them to that state for reporting. > Things that would be nice: > * you ought to be able to change patch states from the top level > list by ticking ticky boxes; at the moment it looks like you have > to go into the individual patch page to do this. Combined with the > lack of any sensible handling of patchsets, this means that marking > a patchset as applied is just way too much work. I believe that if you go to your page listing outstanding patches you can bulk-edit. I agree that bulk editing is an important feature. > * you might want some sort of way to say "this patchset is version 2 > of that one", otherwise your statistics are going to be a bit weird > if you think all the patches in v1 are "this was never accepted" and > the patches in v2 have a time-to-commit starting from when v2 was > posted rather than from when v1 was posted. I believe this is possible, but I'm not sure how it is done. Guilherme? I agree about the need for care about reporting times when this happens. > * ability to add other people's patches (ie by non-Linaro > people) to my "need to review this patch" list and to "will put into > next pull request", etc. [I know this is a bit out of scope for > linaro's metrics tracking, but I definitely don't want to have to > track patches in more than one place if I can avoid it] Yes, I think this is out of scope for the current project. I don't know if we can do this very cheaply for you though, as I would agree that one place to do all this would be good. > On the subject of patch tracking, should I cc patches@ for pull > requests (ie when I ask upstream to commit things)? I'm guessing > not since patches@ has already seen all the patches on first submission > and doesn't need them again. It sounds like there is no need. I'm also guessing that if you have all patches reviewed first there isn't a long time between pull request and pull? Thanks, James _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
