Hi Kalle, On Wed, Mar 16, 2016 at 8:42 PM, Julian Calaby <julian.calaby@xxxxxxxxx> wrote: > Hi Kalle, > > On Wed, Mar 16, 2016 at 8:22 PM, Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote: >> Julian Calaby <julian.calaby@xxxxxxxxx> writes: >> >>> Hi Kalle, >>> >>> On Mon, Feb 1, 2016 at 7:21 PM, Kalle Valo <kvalo@xxxxxxxxxxxxxx> wrote: >>>> Sudip Mukherjee <sudipm.mukherjee@xxxxxxxxx> writes: >>>> >>>>> Sure, I am starting that way. I checked in patchwork and I do not see >>>>> any checkpatch related patch pending (except staging, which Greg will >>>>> handle). I think you must have cleared all of them. >>>> >>>> They are in deferred state. The search functionality in patchwork is not >>>> that intuitive and they are not easy to find so here's a direct link: >>>> >>>> https://patchwork.kernel.org/project/linux-wireless/list/?state=10&order=date >>> >>> I'm currently going through that list and producing a bundle of >>> "applyable" patches. >> >> Nice. > > Thanks, I figured that checking the deferred list on patchwork at some > point would be a good plan. After a release seemed like a good time to > do it. > >>> My criteria is: >>> 1. The change is sane. >>> 2. It's either obviously correct, I can review it, or someone else has >>> reviewed or acked it. >>> 3. No changes other than rebasing and fixing commit messages are >>> required to apply it. >> >> BTW, 'git am -s -3' is the best way to apply a patch. The three way >> merge is awesome (if the submitter has sent the patch correctly). >> >>> Some of these patches need work on their commit messages, some are >>> complicated enough that I feel I should be providing review notes so >>> someone else can double check my review, and all of them should be >>> rebased and compile tested. Also, some are controversial, so I'll be >>> segregating them from the main set. >>> >>> How would you like me to communicate this list to you? I'm happy to >>> provide branches you can pull from or I could just post updated >>> versions to the list and give reviewed-by tags to those that don't >>> need more work. >>> >>> Every patch will get an email on linux-wireless regardless. >> >> I guess posting the patches to linux-wireless is the easiest for >> everyone? I have a script which automatically takes patches from >> patchwork so that's very easy for me. But remember to use Signed-off-by >> instead of Reviewed-by as you are resending the patches. > > If they end up being exactly identical to the original, I'll just add > reviewed-bys to the original patches, otherwise I'll do exactly that. I'm going to just repost everything as it'll just be easier at my end. Git tree: https://github.com/SkUrRiEr/wireless-drivers-pending I've split the pending patches into 4 sets: 1. Cleanup: patches that weren't reviewed or were just forgotten. 2. Detail: patches that needed a detailed review 3. More Work: patches that only partially fix a problem 4. Controversial: patches people hated but fit my criteria I'll go into a lot more detail in my cover letter. At this point, everything in patchwork that's deferred is either: 1. Unreviewable by me (I poked the authors of most of the older patches yesterday) 2. An earlier version of a patch I picked up 3. Too "new" (less than a couple of months old) I'll start sending stuff shortly. Thanks, -- Julian Calaby Email: julian.calaby@xxxxxxxxx Profile: http://www.google.com/profiles/julian.calaby/ -- To unsubscribe from this list: send the line "unsubscribe kernel-janitors" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
