On Fri, 2011-04-08 at 18:24 +0100, Peter Maydell wrote:
On 8 April 2011 17:15, James Westby james.westby@linaro.org wrote:
On Fri, 8 Apr 2011 16:41:26 +0100, Peter Maydell peter.maydell@linaro.org wrote:
On 8 April 2011 15:14, James Westby james.westby@linaro.org wrote:
[...]
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.
Automatic grouping of patch series sounds like it wouldn't be a lot of work, although we'd have to be careful with versions other than the first one as their prefix ([v2,1/4], [2,1/4], etc) seem to vary.
Also, keeping the cover letter is trickier given the way patchwork parses messages, but it's certainly doable as well.
- 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.
We can very easily add new states (via the admin UI), but I don't think we'll be able to automate transitions between all these states, so you'd have to change the state manually before a patch is accepted/committed -- at which point its state should be automatically updated.
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.
This is because Patchwork only allows project maintainers to change state on patch lists, but I think we don't want that restriction, so I'll get rid of it.
- 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.
We already ignore superseded patch series when generating the metrics, so when there's a newer version of a patch/series, their submitters will just have to mark the previous one as superseded.
The only problem is when a patch/series is marked superseded after the turn of the month, as in that case the metrics will change after the end of the month.
And that's similar to the way we track state changes (as we don't keep track of the dates when they were changed), so every time a patch is marked accepted, the metrics for the month when that patch was submitted will change. This is good in the sense that we can get a better picture of the submitted/accepted ratio, but if we take these metrics out and publish them somewhere, then some data will be lost.
- 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 :-)
I think it'd require a significant amount of discussion on how to implement it first, which means it's definitely not on the '2h' category.
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.