The state of ext4 tree merging (was Re: Linux 6.3-rc1)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Sun, Mar 05, 2023 at 03:24:41PM -0800, Linus Torvalds wrote:
> In fact, it was quite nice in a couple of ways: not only didn't I have
> a hugely compressed merge window where I felt I had to cram as much as
> possible into the first few days, but the fact that we _have_ had a
> couple of merge windows where I really asked for people to have
> everything ready when the merge window opened seems to have set a
> pattern: the bulk of everything really did come in early.
> 

Not so for me watching updates to ext4 merging hell...

In this merge window, Ted only submitted the first part of ext4 updates
[1] as noted in the resolution message [2]. The second part didn't make
through the merge window (PR not sent). As such, the data=writepage
cleanups have to wait for 6.4 merge window, and it is IMO inconvenient
for linux-next to contain ext4 tree from next-20230217 for about
seven weeks, as any enhancements and fixes applied to the tree are
holding back from testing in linux-next until this hell can be sorted
out.

In the long term, I'd like to see a co-maintainer step in to help
maintaining the tree in case Ted is busy. Of couse I'm not eligible
for that role (I played as documentation janitor instead), but
any developer with deep knowledge and experience for the fs and its
internals should fit the role.

Thanks.

[1]: https://lore.kernel.org/lkml/Y%2F2CN+FpmGsfzgdE@xxxxxxx/
[2]: https://lore.kernel.org/linux-next/Y%2Fk4Jvph15ugcY54@xxxxxxx/

-- 
An old man doll... just what I always wanted! - Clara

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Reiser Filesystem Development]     [Ceph FS]     [Kernel Newbies]     [Security]     [Netfilter]     [Bugtraq]     [Linux FS]     [Yosemite National Park]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Samba]     [Device Mapper]     [Linux Media]

  Powered by Linux