From: Dave Chinner <david@fromorbit.com>
To: linux-xfs@vger.kernel.org
Subject: [5.19 cycle] Planning and goals
Date: Tue, 5 Apr 2022 12:03:12 +1000 [thread overview]
Message-ID: <20220405020312.GU1544202@dread.disaster.area> (raw)
Hi folks,
I'd really like to try getting the merge bottlenecks we've had
recently unstuck, so there are a few patchsets I want to try to get
reviewed, tested and merged for 5.19. Hopefully not too many
surprises will get in the way and so some planning to try to
minimises surprised might be a good thing. Hence I want to have a
rough plan for the work I'd like to acheive during this 5.19 cycle,
and so that everyone has an idea of what needs to be done to (maybe)
achieve those goals over the next few weeks.
First of all, a rough timeline that I'm working with:
5.18-rc1: where we are now
5.18-rc2: Update linux-xfs master branch to 5.19-rc2
5.18-rc4: At least 2 of the major pending works merged
5.18-rc6: Last point for new work to be merged
5.18-rc6+: Bug fixes only will be merged
I'm assuming a -rc7 kernel will be released, hence this rough
timeline gives us 2 weeks of testing/stabilisation time before 5.19
merge window opens.
Patchsets for review should be based on either 5.17.0 or the
linux-xfs master branch once it has been updated to 5.19-rc2. If
there are important bug fixes for the 5.18 cycle, I may move the
master branch forwards to a more recent release.
In terms of merge process, I plan to keep each major set of work in
a separate topic branch so that once it has been merged the commit
IDs remain stable. I will then merge the topic branches into the
for-next branch. Hence the for-next tree may still rebase (e.g. if I
need to send fixes for 5.18-rcX), but I hope to keep the individual
commits that make up the for-next branch as stable as possible. Bug
fixes for patchsets will get appended to the topic branches and the
for-next branch rebuilt via a new set of merges.
The major patchsets that I'm hoping to get reviewed and merged this
cycle:
- large extent counts V8 (Chandan)
- Merge criteria and status:
- review complete: 95%
- no regressions when not enabled: 70%
- no major regressions when enabled: 0%
- Open questions:
- Experimental tag for the first couple of cycles?
(Darrick says "YES" on #xfs)
- Needs more QA, but signs are good so far.
- Almost ready to merge.
- Logged attributes V28 (Allison)
- I haven't looked at this since V24, so I'm not sure what
the current status is. I will do that discovery later in
the week.
- Merge criteria and status:
- review complete: Not sure
- no regressions when not enabled: v24 was OK
- no major regressions when enabled: v24 had issues
- Open questions:
- not sure what review will uncover
- don't know what problems testing will show
- what other log fixes does it depend on?
- is there a performance impact when not enabled?
- DAX + reflink V11 (Ruan)
- Merge criteria and status:
- review complete: 75%
- no regressions when not enabled: unknown
- no major regressions when enabled: unknown
- Open questions:
- still a little bit of change around change
notification?
- Not sure when V12 will arrive, hence can't really
plan for this right now.
- external dependencies?
- xlog_write() rework V8
- Merge criteria and status:
- review complete: 100%
- No regressions in testing: 100%
- Open questions:
- unchanged since last review/merge attempt,
reverted because of problems with other code that
was merged with it that isn't in this patchset
now. Does it need re-reviewing?
- Ready to merge.
- Intent Whiteouts V3
- Merge criteria and status:
- review complete: 0%
- No regressions in testing: 100%
- Open questions:
- will it get reviewed in time?
- what bits of the patchset does LARP depend on?
- Is LARP perf without intent whiteouts acceptible
(Experimental tag tends to suggest yes).
- Functionally complete and tested, just needs review.
Have I missed any of the major outstanding things that are nearly
ready to go?
Do the patchset authors have the time available in the next 2-3
weeks to make enough progress to get their work merged? I'd kinda
like to have the xlog_write() rework and the large extent counts
merged ASAP so we have plenty of time to focus on the more
complex/difficult pieces. If you don't have time in the next few
weeks, then let me know so I can adjust the plan appropriately for
the cycle.
What does everyone think of the plan?
Cheers,
Dave.
--
Dave Chinner
david@fromorbit.com
next reply other threads:[~2022-04-05 2:53 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-05 2:03 Dave Chinner [this message]
2022-04-07 3:11 ` [5.19 cycle] Planning and goals Darrick J. Wong
2022-04-07 5:49 ` Dave Chinner
2022-04-07 22:40 ` Alli
2022-04-11 1:50 ` Dave Chinner
2022-04-11 3:59 ` Dave Chinner
2022-04-11 7:31 ` Dave Chinner
2022-04-11 8:50 ` Dave Chinner
2022-04-11 20:00 ` Alli
2022-04-11 19:38 ` Alli
2022-04-10 18:21 ` Darrick J. Wong
2022-04-11 1:51 ` Dave Chinner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20220405020312.GU1544202@dread.disaster.area \
--to=david@fromorbit.com \
--cc=linux-xfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox