Lines Matching refs:patches

14  - don't post large series (> 15 patches), break them up
15  - don't repost your patches within one 24h period
88 RFC patches sent for review only are obviously welcome at any time
140                    patches set to ``Awaiting upstream`` in netdev's patchwork
148                    pw-bot can automatically set patches to this state based
161 about the history of the state of patches, therefore having multiple
176 completely. Maintainers will classify and update the state of the patches
180 The use of the bot is restricted to authors of the patches (the ``From:``
192 Generally speaking, the patches get triaged quickly (in less than
211   with A, should I do B and repost the patches?
246 patches such that it is clear this is the latest and greatest set of patches
247 that can be applied. Do not try to resend just the patches which changed.
249 Handling misapplied patches
258 the patches the way they would look like if your latest patch series was to be
291 alongside kernel patches. This gives reviewers a chance to see
297 to a public repo where user space patches can be seen.
300 reviewed on netdev  (e.g. patches to ``iproute2`` tools) kernel and
301 user space patches should form separate series (threads) when posted
329 :ref:`Documentation/process/submitting-patches.rst <submittingpatches>`
344 Dividing work into patches
351 Avoid sending series longer than 15 patches. Larger series takes longer
396 Clean-up patches
399 Netdev discourages patches which perform simple clean-ups, which are not in
423 The new version of patches should be posted as a separate thread,
451 **Do not** post your patches just to run them through the checks.
452 You must ensure that your patches are ready by testing them locally
476 Reviewing other people's patches on the list is highly encouraged,