On 8 April 2011 17:15, James Westby <james.wes...@linaro.org> wrote: > 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.
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. >> 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. 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. >> * 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? 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. So "waiting for review" means "patch has gone on list and hasn't had any comments"; "will put into next pull req" means "patch has gone on list, had no comments but it's been a couple of weeks so I consider it to have passed review by default"; "pull request sent" means "I've sent upstream a pull request email but am waiting for upstream to actually pull (or deny, as the case may be)". "committed" means "actually got into upstream's git tree". 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. >> 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. Looks like you can, yes. So not being able to do that from the project page is just a UI inconsistency. >> * 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? 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. >> * 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. 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 :-) >> 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? 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. -- PMM _______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
