On Fri, 2011-04-08 at 18:24 +0100, Peter Maydell wrote: > 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: [...] > > >> 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. -- Guilherme Salgado <https://launchpad.net/~salgado>
signature.asc
Description: This is a digitally signed message part
_______________________________________________ linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev
