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. 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 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... * 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' '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. 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. * 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. * 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] 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. PS: upstream's git URL for the benefit of automatic 'this patch got committed' script: git://git.qemu.org/qemu.git thanks -- PMM _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
