Hi Mauro, On Sun, Aug 12, 2012 at 6:15 PM, Mauro Carvalho Chehab <mchehab@xxxxxxxxxx> wrote: > Yes, that's the "changes requested": to submit it together with the > driver, when you're ready for that. > > While "changes requested" is not an exact match for "postpone submission", > it fits a little better than rejected/accepted/under review/rfc/obsoleted/... > > Keeping it as "new" doesn't make sense, as I need to cleanup my pending > queue. > > I might have created yet-another-status-tag for patchwork for this case, > but having a lot of status is confusing for everybody. > > Also, at the time you'll be re-submitting it, you may need to rebase the > patch, as it might conflict with some other changes. So, changes may be > needed anyway. > > So, what I do is, when someone, including me, requests any type of action > from the driver's author (in this case, to put it together with the patches > that require those API additions, when you're done), I mark it as > "changes requested". OK, that all looks good. Again, thanks for the explanations! Regards, -Ilyes > Regards, > Mauro > > PS.: I'm following this logic since when we started with patchwork; the > only thing that changed is that patchwork is now posting e-mails to > help developers to track on what's the merging status of their work. > >> >> -Ilyes >> >>> This email is a notification only - you do not need to respond. >>> >>> - >>> >>> Patches submitted to linux-media@xxxxxxxxxxxxxxx have the following >>> possible states: >>> >>> New: Patches not yet reviewed (typically new patches); >>> >>> Under review: When it is expected that someone is reviewing it (typically, >>> the driver's author or maintainer). Unfortunately, patchwork >>> doesn't have a field to indicate who is the driver maintainer. >>> If in doubt about who is the driver maintainer please check the >>> MAINTAINERS file or ask at the ML; >>> >>> Superseded: when the same patch is sent twice, or a new version of the >>> same patch is sent, and the maintainer identified it, the first >>> version is marked as such; >>> >>> Obsoleted: patch doesn't apply anymore, because the modified code doesn't >>> exist anymore. >>> >>> Changes requested: when someone requests changes at the patch; >>> >>> Rejected: When the patch is wrong or doesn't apply. Most of the >>> time, 'rejected' and 'changes requested' means the same thing >>> for the developer: he'll need to re-work on the patch. >>> >>> RFC: patches marked as such and other patches that are also RFC, but the >>> patch author was not nice enough to mark them as such. That includes: >>> - patches sent by a driver's maintainer who send patches >>> via git pull requests; >>> - patches with a very active community (typically from developers >>> working with embedded devices), where lots of versions are >>> needed for the driver maintainer and/or the community to be >>> happy with. >>> >>> Not Applicable: for patches that aren't meant to be applicable via >>> the media-tree.git. >>> >>> Accepted: when some driver maintainer says that the patch will be applied >>> via his tree, or when everything is ok and it got applied >>> either at the main tree or via some other tree (fixes tree; >>> some other maintainer's tree - when it belongs to other subsystems, >>> etc); >>> >>> If you think any status change is a mistake, please send an email to the ML. >>> >>> - >>> >>> This is an automated mail sent by the patchwork system at >>> patchwork.linuxtv.org. To stop receiving these notifications, edit >>> your mail settings at: >>> http://patchwork.linuxtv.org/mail/ > -- To unsubscribe from this list: send the line "unsubscribe linux-media" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
