Lines Matching +refs:is +refs:post +refs:merge
13 - for fixes the ``Fixes:`` tag is required, regardless of the tree
14 - don't post large series (> 15 patches), break them up
21 netdev is a mailing list for all network-related Linux stuff. This
28 The netdev list is managed (like many other Linux mailing lists) through
39 Here is a bit of background information on
41 two week "merge window" where the main maintainers feed their new stuff
43 merge window is closed, and it is called/tagged ``-rc1``. No new
46 rc2 is released. This repeats on a roughly weekly basis until rc7
49 official vX.Y is released.
56 and note the top of the "tags" section. If it is rc1, it is early in
57 the dev cycle. If it was tagged rc7 a week ago, then a release is
58 probably imminent. If the most recent tag is a final release tag
59 (without an ``-rcN`` suffix) - we are most likely in a merge window
60 and ``net-next`` is closed.
66 driven by David Miller, the main network maintainer. There is the
68 the names, the ``net`` tree is for fixes to existing code already in the
69 mainline tree from Linus, and ``net-next`` is where the new code goes
76 merge window, the ``net-next`` tree will be closed - no new changes/features.
82 An announcement indicating when ``net-next`` has been closed is usually
87 period during which ``net-next`` tree is closed.
92 Shortly after the two weeks have passed (and vX.Y-rc1 is released), the
103 The ``net`` tree continues to collect fixes for the vX.Y content, and is
105 focus for ``net`` is on stabilization and bug fixes.
128 New, Under review pending review, patch is in the maintainer’s queue for
131 Accepted patch was applied to the appropriate networking tree, this is
134 Changes requested patch has not passed the review, new revision is expected
136 Rejected patch has been rejected and new revision is not expected
137 Not applicable patch is expected to be applied outside of the networking
176 The use of the bot is entirely optional, if in doubt ignore its existence
181 The use of the bot is restricted to authors of the patches (the ``From:``
194 48h). But be patient, if your patch is active in patchwork (i.e. it's
197 patch is a good way to ensure your patch is ignored or pushed to the
233 patches such that it is clear this is the latest and greatest set of patches
242 Making the patch disappear once it is pushed out is not possible, the commit
243 history in netdev trees is immutable.
248 In cases where full revert is needed the revert has to be submitted
251 when original change is completely wrong; incremental fixes are preferred.
257 to carry explicit ``CC: stable@vger.kernel.org`` tags that is no longer
279 how any new interface is used and how well it works.
283 or the user space project is not reviewed on netdev include a link
286 In case user space tooling lives in a separate repository but is
298 Posting as one thread is discouraged because it confuses patchwork
304 Attention to detail is important. Re-read your own work as if you were the
307 If your change is a bug fix, make sure your commit log indicates the
309 and then if necessary, explain why the fix proposed is the best way to
310 get things done. Don't mangle whitespace, and as is common, don't
311 mis-indent function arguments that span multiple lines. If it is your
323 your patch is targeting. Assuming that you use git, use the prefix
334 Put yourself in the shoes of the reviewer. Each patch is read separately
348 Comment style convention is slightly different for networking and most of
356 it is requested that you make it look like this::
380 in the domain of netdev is in the preferred format.
390 Make sure you address all the feedback in your new posting. Do not post a new
391 version of the code if the discussion about the previous version is still
422 **Do not** post your patches just to run them through the checks.
431 ``netdevsim`` is a test driver which can be used to exercise driver
434 adding new APIs, but ``netdevsim`` in itself is **not** considered
440 ``netdevsim`` is reserved for use by upstream tests only, so any