On 16.03.2018 00:23, Borislav Petkov wrote: > On Fri, Mar 16, 2018 at 12:07:34AM +0100, Maciej S. Szmigiero wrote: >> Currently, it is very easy to make the AMD microcode update driver crash >> or spin on a malformed microcode container file since it does very little >> consistency checking on data loaded from such file. > > Ok, a couple of tips for the next time: > > * please send your reworked patchset for review after review of your > current patchset has been completed. We normally send patchsets once a > week. You've sent yours two days after and that's kinda too fast. I'm > sure you can imagine reviewers have other work to do too. > > So please be patient before resending next time. > > If in doubt, the whole process is documented in Documentation/process/ - > might wanna skim through it. I thought the one week absolute minimum resend time is for the case that there are no comments to a patch, or, more generally, when there is no action and not for "normal process" respins.
submitting-patches.rst says: > Once upon a time, patches used to disappear into the void without comment, > but the development process works more smoothly than that now. You should > receive comments within a week or so; if that does not happen, make sure > that you have sent your patches to the right place. Wait for a minimum of > one week before resubmitting or pinging reviewers - possibly longer during > busy times like merge windows. But I will wait a week now for respins if you say so. > * when sending your patchset, make sure all mails are sent as a reply to > the 0/N message. > > Your 0/N has: > > Message-ID: <9964a6cf-00be-78ea-cc1e-7f7062716...@maciej.szmigiero.name> > > but your 1/N has > > References: <cover.1521150415.git.m...@maciej.szmigiero.name> > > so something went wrong there. Normally git send-email does this > correctly. I've copied these messages to my mailbox first and sent them from there, so that must have overwritten the message IDs. Will submit them from git-send-email the next time. > Thx. Thanks, Maciej
