linux-next: stats (Was: Linux 6.3-rc1)

linux-next: stats (Was: Linux 6.3-rc1)

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 2575 bytes --]

Hi all,

As usual, the executive friendly graph is at
http://neuling.org/linux-next-size.html :-)

(No merge commits counted, next-20230220 was the first linux-next after
the merge window opened.)

Commits in v6.3-rc1 (relative to v6.2):            12717
Commits in next-20230220:                          12390
Commits with the same SHA1:                        11749
Commits with the same patch_id:                      317 (1)
Commits with the same subject line:                   12 (1)

(1) not counting those in the lines above.

So commits in -rc1 that were in next-20230220:     12078 94%

Some breakdown of the list of extra commits (relative to next-20230220)
in -rc1:

Top ten first word of commit summary:

     66 net
     43 drm
     32 scsi
     28 cifs
     25 asoc
     24 dt-bindings
     19 risc-v
     18 alpha
     17 rtc
     17 riscv

Top ten authors:

     19 dhowells@redhat.com
     16 viro@zeniv.linux.org.uk
     15 miquel.raynal@bootlin.com
     14 atishp@rivosinc.com
     12 edumazet@google.com
     12 broonie@kernel.org
      8 paulb@nvidia.com
      8 arnd@arndb.de
      7 vladimir.oltean@nxp.com
      7 torvalds@linux-foundation.org

Top ten commiters:

     44 davem@davemloft.net
     36 kuba@kernel.org
     34 stfrench@microsoft.com
     33 alexander.deucher@amd.com
     32 martin.petersen@oracle.com
     32 broonie@kernel.org
     23 palmer@rivosinc.com
     21 pabeni@redhat.com
     21 alexandre.belloni@bootlin.com
     20 stefan@datenfreihafen.org

There are also 312 commits in next-20230220 that didn't make it into
v6.3-rc1.

Top ten first word of commit summary:

     37 fs
     29 habanalabs
     22 nvmem
     17 arm
     13 btrfs
     12 dmapool
     11 dt-bindings
     10 virtio_ring
     10 soc
     10 iio

Top ten authors:

     16 almaz.alexandrovich@paragon-software.com
     15 krzysztof.kozlowski@linaro.org
     14 arnd@arndb.de
     11 michael@walle.cc
     11 dhowells@redhat.com
     10 xuanzhuo@linux.alibaba.com
      8 xu.xin16@zte.com.cn
      8 kbusch@kernel.org
      7 josef@toxicpanda.com
      7 ericvh@kernel.org

Top ten commiters:

     32 srinivas.kandagatla@linaro.org
     32 almaz.alexandrovich@paragon-software.com
     30 akpm@linux-foundation.org
     29 ogabbay@kernel.org
     16 krzysztof.kozlowski@linaro.org
     14 jonathan.cameron@huawei.com
     13 dsterba@suse.com
     12 mst@redhat.com
     12 dhowells@redhat.com
     10 yilun.xu@intel.com

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Bagas Sanjaya]

[-- Attachment #1: Type: text/plain, Size: 1553 bytes --]

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@mit.edu/
[2]: https://lore.kernel.org/linux-next/Y%2Fk4Jvph15ugcY54@mit.edu/

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]

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

[Jan Kara]

On Mon 06-03-23 10:17:56, Bagas Sanjaya wrote:
> 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.

To be fair, the data=journal cleanups got held back only partially due to
the merge issues. Another problem is that they somehow make problems with
filesystem freezing in data=journal mode more frequent and we wanted to
understand (and hopefully fix) that. Of course if Ted could look into this
earlier or I could earlier debug these issues, we could have merged the
cleanups but that's always the case that you have to prioritize and these
cleanups don't have that high priority...

								Honza
-- 
Jan Kara <jack@suse.com>
SUSE Labs, CR

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 805 bytes --]

Hi all,

On Mon, 6 Mar 2023 13:41:34 +0100 Jan Kara <jack@suse.cz> wrote:
>
> To be fair, the data=journal cleanups got held back only partially due to
> the merge issues. Another problem is that they somehow make problems with
> filesystem freezing in data=journal mode more frequent and we wanted to
> understand (and hopefully fix) that. Of course if Ted could look into this
> earlier or I could earlier debug these issues, we could have merged the
> cleanups but that's always the case that you have to prioritize and these
> cleanups don't have that high priority...

In that case, it would be nice (for me at least) if the ext4 tree was
now reset to be v6.3-rc1 i.e. get rid of the duplicate commits and the
new stuff that is still being worked on.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Theodore Ts'o]

On Tue, Mar 07, 2023 at 09:02:03AM +1100, Stephen Rothwell wrote:
> Hi all,
> 
> On Mon, 6 Mar 2023 13:41:34 +0100 Jan Kara <jack@suse.cz> wrote:
> >
> > To be fair, the data=journal cleanups got held back only partially due to
> > the merge issues. Another problem is that they somehow make problems with
> > filesystem freezing in data=journal mode more frequent and we wanted to
> > understand (and hopefully fix) that. Of course if Ted could look into this
> > earlier or I could earlier debug these issues, we could have merged the
> > cleanups but that's always the case that you have to prioritize and these
> > cleanups don't have that high priority...
> 
> In that case, it would be nice (for me at least) if the ext4 tree was
> now reset to be v6.3-rc1 i.e. get rid of the duplicate commits and the
> new stuff that is still being worked on.

What duplicate commits?  As far as I know there aren't any.  My normal
practice is to send a secondary push to fix a few bug fixes targetted
for upcoming release (in this case, 6.3), and then I'll reset to -rc2
or -rc3 for patches that are targetted for the next merge window (in
this case, 6.4).

The data=writeback patches was dropped from dev before the pull
request, and won't show up on dev until they are ready for Linus.

Cheers,

						- Ted

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

[Stephen Rothwell]

[-- Attachment #1: Type: text/plain, Size: 960 bytes --]

Hi Theodore,

On Tue, 7 Mar 2023 11:21:37 -0500 "Theodore Ts'o" <tytso@mit.edu> wrote:
>

> What duplicate commits?  As far as I know there aren't any.  My normal
> practice is to send a secondary push to fix a few bug fixes targetted
> for upcoming release (in this case, 6.3), and then I'll reset to -rc2
> or -rc3 for patches that are targetted for the next merge window (in
> this case, 6.4).
> 
> The data=writeback patches was dropped from dev before the pull
> request, and won't show up on dev until they are ready for Linus.

Did you forget to push the dev branch out?  The version I have (and still see on git.kernel.org) has commit

  2c2dec1e86cc ("ext4: fix incorrect options show of original mount_opt and extend mount_opt2")

at its head, but what you sent to Linus has commit

  e3645d72f886 ("ext4: fix incorrect options show of original mount_opt and extend mount_opt2")

at its head.

-- 
Cheers,
Stephen Rothwell

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

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

[Theodore Ts'o]

On Wed, Mar 08, 2023 at 07:45:13AM +1100, Stephen Rothwell wrote:
> 
> Did you forget to push the dev branch out?  The version I have (and still see on git.kernel.org) has commit
> 
>   2c2dec1e86cc ("ext4: fix incorrect options show of original mount_opt and extend mount_opt2")
> 
> at its head, but what you sent to Linus has commit
> 
>   e3645d72f886 ("ext4: fix incorrect options show of original mount_opt and extend mount_opt2")
> 
> at its head.

Ah, sorry.   I had pushed the tag, but not the branch.  My bad.  Anyway, fixed.

    	       	   	      	       	   - Ted