Next btrfs development cycle open - 5.6

Next btrfs development cycle open - 5.6

[David Sterba]

From: David Sterba <dsterba@suse.cz>

Hi,

a friendly reminder of the timetable and what's expected at this phase.

5.3 - current
5.4 - upcoming, urgent regression fixes only
5.5 - development closed, pull request in prep, fixes or regressions only
5.6 - development open, until 5.5-rc5 (at least)

(https://btrfs.wiki.kernel.org/index.php/Developer%27s_FAQ#Development_schedule)


Current status
--------------

Branch misc-5.5 has been forked off misc-next (based on 5.4-rc8) and contains
the first pull request changes.


Hilights of 5.5 changes
------------------------

New checksum algorithms, 3- and 4-copy raid1 (RAID1C34).  Tree checker has
again learned some new tricks.  And as usual there are many cleanups and
refactoring.


Merge outlook
-------------

The async discard patchset looks in a good shape, but please have a look if you
have some spare cycles. The feature adjusts access to block groups but
otherwise is isolated and has to be explicitly selected so this lowers the
risks.

Otherwise there are several (read: many) proposals for smaller-sized features.
Reviews will start or continue and we'll see what we can merge.


Git development repos
---------------------

  k.org: https://git.kernel.org/pub/scm/linux/kernel/git/kdave/linux.git
  devel1: https://gitlab.com/kdave/btrfs-devel
  devel2: https://github.com/kdave/btrfs-devel


Usual points
------------

* the current patch queue (as is in misc-next) looks stable, so no big
  changes are going to be applied at this time. The usual exceptions are
  bugfixes or obvious cleanups.

* the base of the patches should be the last announced pull request,
  which is going to be named 'for-5.5' in my k.org tree.  Reviewed
  patches will be collected in a branch that's usually named 'misc-next'
  in my devel git repos and is part of the for-next at k.org git repo.

* merging of new patches to misc-next will be slow during the
  merge window, btrfs-progs release is planned for that period

* review other developer patches, test them, find bugs before they are in a
  released kernel