Home
last modified time | relevance | path

Searched refs:weeks (Results 1 – 25 of 25) sorted by relevance

/openbmc/openbmc/poky/meta/recipes-core/glib-2.0/glib-2.0/
H A Dskip-timeout.patch24 g_test_add_func ("/timeout/weeks-overflow", test_weeks_overflow);
/openbmc/linux/Documentation/nvdimm/
H A Dmaintainer-entry-profile.rst51 patch set requires more than 2 weeks of review, -rc4 is already too late
/openbmc/linux/Documentation/devicetree/bindings/
H A Dsubmitting-patches.rst79 maintainers after a few weeks, go ahead and take it.
/openbmc/linux/Documentation/process/
H A Dmaintainer-netdev.rst42 to Linus for merging into the mainline tree. After the two weeks, the
77 The accumulated new content of the past ~10 weeks will be passed onto
92 Shortly after the two weeks have passed (and vX.Y-rc1 is released), the
387 too long (weeks) between postings either as it will make it harder for reviewers
H A Dhowto.rst252 linux-next for a few weeks. The preferred way to submit big changes
256 - After two weeks a -rc1 kernel is released and the focus is on making the
270 process should last around 6 weeks.
294 two weeks, but it can be longer if there are no pressing problems. A
H A Dhandling-regressions.rst49 for most regressions should be merged within two weeks, but some need to be
127 into the issue weeks, months, or years later. These tags are also crucial for
144 than three weeks after the regression's culprit was identified. Ideally it
180 within the next three weeks. One or two Sundays later are acceptable, if the
480 three weeks means that I will revert, and I will stop pulling apparmor
H A Dstable-kernel-rules.rst126 Cc: <stable@vger.kernel.org> # after 4 weeks in mainline
H A D2.Process.rst49 The merge window lasts for approximately two weeks. At the end of this
57 Over the next six to ten weeks, only patches which fix problems should be
H A Dsubmitting-patches.rst375 weeks with the word "RESEND" added to the subject line::
703 weeks, months or even years later, it can give the reader the needed
H A Dcoding-style.rst469 to understand what you did 2 weeks from now.
/openbmc/docs/tof/
H A Dcontract.md84 the next TOF meeting agenda after 2 weeks.
/openbmc/linux/Documentation/maintainer/
H A Dfeature-and-driver-maintainers.rst37 to as long as a few weeks in slower moving parts of the kernel.
/openbmc/docs/
H A Dmeta-layer-guidelines.md48 process. If the Yocto process has gone several weeks without responses,
/openbmc/linux/Documentation/driver-api/media/
H A Dmaintainer-entry-profile.rst201 to ping if you don't get a feedback in a couple of weeks or to ask
/openbmc/bmcweb/redfish-core/include/utils/extern/
H A Ddate.h194 using weeks = std::chrono::duration variable
5785 auto wn = duration_cast<weeks>(ld - st).count() + 1;
5833 auto wn = duration_cast<weeks>(ld - st).count() + 1;
5910 auto wn = duration_cast<weeks>(ld - st).count() + 1;
7730 (Monday-Thursday) + weeks{V-1} +
7749 weeks{U-1} +
7768 weeks{W-1} +
7823 auto V_trial = duration_cast<weeks>(sd - start).count() + 1;
7831 auto U_trial = floor<weeks>(sys_days(ymd) - start).count() + 1;
7838 auto W_trial = floor<weeks>(sys_days(ymd) - start).count() + 1;
/openbmc/linux/Documentation/admin-guide/
H A Dreporting-regressions.rst227 should be fixed within two weeks.
281 weeks later this solution can become impossible, as some software might have
H A Dreporting-issues.rst815 In about two out of every nine to ten weeks, mainline might point you to a
840 take a few days or weeks. Another reason: the fix you hope for might be too
1407 In these cases wait two (better: three) weeks before sending a friendly
1418 After the reminder wait three more weeks for replies. If you still don't get a
1640 weeks, but sometimes it takes a bit longer.
H A Dquickly-build-trimmed-linux.rst754 a few weeks. You can automate this with `modprobed-db
/openbmc/u-boot/doc/uImage.FIT/
H A Dsignature.txt463 <n>w = key expires in n weeks
/openbmc/u-boot/tools/patman/
H A DREADME445 1. When you change back to the us-cmd branch days or weeks later all your
/openbmc/linux/Documentation/filesystems/
H A Dxfs-self-describing-metadata.rst33 to analyse and so that analysis blows out towards weeks/months of forensic work.
/openbmc/linux/Documentation/power/
H A Dswsusp.rst334 broken in weeks later and sensitive data which you thought were
/openbmc/qemu/docs/devel/
H A Dsubmitting-a-patch.rst579 resolve the problems. It may take a couple of weeks between when your
/openbmc/linux/Documentation/bpf/
H A Dbpf_devel_QA.rst239 During those two weeks of merge window, we might ask you to resend
/openbmc/openbmc/poky/meta/recipes-bsp/lrzsz/lrzsz-0.12.20/
H A Dautotools-update.patch970 - This was necessary since a change in _nl_find_msg several weeks