[RFC] Sending NILFS2 patches into upstream

[RFC] Sending NILFS2 patches into upstream

[Viacheslav Dubeyko]

Hi Ryusuke,

Currently, you ask Andrew Morton of sending NILFS2 patches into
upstream. But Andrew is busy and it makes the whole workflow
complicated and unpredictable.

I am sending HFS/HFS+ patches to upstream. So, I can create the
dedicated NILFS2 kernel tree on kernel.org and I can send NILFS2
patches upstream. I believe that it can make the whole patch management
workflow more flexible and predictable. Also, additional maintainer is
better than to have only one.

We already had some discussion privately. So, let's continue the
discussion in the email list. What do you think?

Thanks,
Slava.

Re: [RFC] Sending NILFS2 patches into upstream

[Ryusuke Konishi]

On Tue, Nov 4, 2025 at 5:37 AM Viacheslav Dubeyko wrote:
>
> Hi Ryusuke,
>
> Currently, you ask Andrew Morton of sending NILFS2 patches into
> upstream. But Andrew is busy and it makes the whole workflow
> complicated and unpredictable.
>
> I am sending HFS/HFS+ patches to upstream. So, I can create the
> dedicated NILFS2 kernel tree on kernel.org and I can send NILFS2
> patches upstream. I believe that it can make the whole patch management
> workflow more flexible and predictable. Also, additional maintainer is
> better than to have only one.
>
> We already had some discussion privately. So, let's continue the
> discussion in the email list. What do you think?
>
> Thanks,
> Slava.

Hi Viacheslav,

Yes, thanks for the suggestion.

As I replied to you privately earlier, I'd welcome your help both with
upstreaming and setting up the git tree on kernel.org.

First, I'll start by adding you as a maintainer.
To do this, I'd like to send a patch with changes to the maintainers
file to Andrew.

Currently, bug fix patches and patches for the next merge window are
being sent to Andrew, so to avoid confusion, I think it would be best
to switch the upstreaming path after the next merge window is over.

I'd like patches after the next merge window to be upstreamed via you.
What do you think about this timing?

As for switching the git repository in the MAINTAINERS file, how about
after 6.19-rc1, again to avoid confusion?

Next, as for upstreaming, one option is for you to directly pick up
patches sent to this mailing list, and I can review and test them.
However, I think it's better to change the maintenance flow gradually,
so initially I would like to pick up patches, add my Signed-of-by tag,
and complement them with appropriate tags such as Fixes or Cc: stable.

To do this, I think it would be best to relay patches or their series
to the repository you set up on kernel.org via my current GitHub
repository.

In practice, I will push the collected patches, signed, with tags like
fixes-6.19-<serial number> or for-6.20-<serial number> to my current
GitHub repository, so please cherry pick them to receive them
initially.

Patches with tags starting with fixes- prefix are intended to be sent
as bug fixes in that cycle, while patches with tags starting with
for-<version number>- prefix are intended to be sent for the merge
window of the next cycle.
It would be ideal if I could automate the notification of pushes, but
initially I will send you an email.

Next, regarding the operation of the repository to be set up on
kernel.org, I think you should create a main branch of the nilfs2
project to send pull requests to Linus.

I haven't created a main branch for the nilfs2 project so far, but I
think it's better to have one when collaborating.

In this regard, how do you maintain the HFS/HFS+ tree?

Thanks,
Ryusuke Konishi

Re: [RFC] Sending NILFS2 patches into upstream

[Viacheslav Dubeyko]

Hi Ryusuke,

On Tue, 2025-11-04 at 19:41 +0900, Ryusuke Konishi wrote:
> On Tue, Nov 4, 2025 at 5:37 AM Viacheslav Dubeyko wrote:
> > 
> > Hi Ryusuke,
> > 
> > Currently, you ask Andrew Morton of sending NILFS2 patches into
> > upstream. But Andrew is busy and it makes the whole workflow
> > complicated and unpredictable.
> > 
> > I am sending HFS/HFS+ patches to upstream. So, I can create the
> > dedicated NILFS2 kernel tree on kernel.org and I can send NILFS2
> > patches upstream. I believe that it can make the whole patch
> > management
> > workflow more flexible and predictable. Also, additional maintainer
> > is
> > better than to have only one.
> > 
> > We already had some discussion privately. So, let's continue the
> > discussion in the email list. What do you think?
> > 
> > Thanks,
> > Slava.
> 
> Hi Viacheslav,
> 
> Yes, thanks for the suggestion.
> 
> As I replied to you privately earlier, I'd welcome your help both
> with
> upstreaming and setting up the git tree on kernel.org.
> 
> First, I'll start by adding you as a maintainer.
> To do this, I'd like to send a patch with changes to the maintainers
> file to Andrew.

Sounds good! Probably, I can create the NILFS2 kernel tree on
kernel.org at first. And, then this patch can be sent with adding the
link to this kernel tree into MAINTAINERS file.

> 
> Currently, bug fix patches and patches for the next merge window are
> being sent to Andrew, so to avoid confusion, I think it would be best
> to switch the upstreaming path after the next merge window is over.
> 
> I'd like patches after the next merge window to be upstreamed via
> you.
> What do you think about this timing?
> 
> As for switching the git repository in the MAINTAINERS file, how
> about
> after 6.19-rc1, again to avoid confusion?

Yes, makes sense. I am having the same in mind. Because, anyway,
preparing the whole workflow will require some time.

> 
> Next, as for upstreaming, one option is for you to directly pick up
> patches sent to this mailing list, and I can review and test them.
> However, I think it's better to change the maintenance flow
> gradually,
> so initially I would like to pick up patches, add my Signed-of-by
> tag,
> and complement them with appropriate tags such as Fixes or Cc:
> stable.
> 
> To do this, I think it would be best to relay patches or their series
> to the repository you set up on kernel.org via my current GitHub
> repository.
> 
> In practice, I will push the collected patches, signed, with tags
> like
> fixes-6.19-<serial number> or for-6.20-<serial number> to my current
> GitHub repository, so please cherry pick them to receive them
> initially.

I assume that, currently, NILFS2 hasn't active development and to send
patches for the first merge window in the cycle (for-6.20-rc1, for
example) could be completely enough.

> 
> Patches with tags starting with fixes- prefix are intended to be sent
> as bug fixes in that cycle, while patches with tags starting with
> for-<version number>- prefix are intended to be sent for the merge
> window of the next cycle.
> It would be ideal if I could automate the notification of pushes, but
> initially I will send you an email.

Makes sense. We can use this model of operations.

> 
> Next, regarding the operation of the repository to be set up on
> kernel.org, I think you should create a main branch of the nilfs2
> project to send pull requests to Linus.
> 
> I haven't created a main branch for the nilfs2 project so far, but I
> think it's better to have one when collaborating.
> 
> In this regard, how do you maintain the HFS/HFS+ tree?

So, I have two branches for-next and for-linux. I am resetting it to
the last rc1 tag. And, then, I am collecting patches in the for-next
branch at first by means of b4 am <MSG ID> + git am -s <mbox file>.
When I have enough patches for a merge window, then I execute these
steps:

$ git checkout for-linus
$ git rebase for-next
$ echo -e "hfs updates for v6.18\n" > ../hfs-v6.18-changes.txt
$ git log --pretty=format:"- %s" v6.17-rc1..HEAD >> ../hfs-v6.18-
changes.txt
$ git tag -s hfs-v6.18-tag1 for-linus # (paste the contents of "hfs-
v6.18-changes.txt" here)
$ git push origin --all
$ git push origin --tags
$ git request-pull master
git://git.kernel.org/pub/scm/linux/kernel/git/vdubeyko/hfs.git hfs-
v6.18-tag1 > ../hfs-v6.18-pull-request.txt
$ git branch for-v6.18
$ git push origin --all
$ git push origin --tags

Finally, I am sending hfs-v6.18-pull-request.txt by email as pull
request.

So, I could have the same two branches for-next and for-linux for the
case of NILFS2. The for-next branch could receive patches from github,
the rest steps could be the same. I simply need to elaborate the
steps/commands to cherry pick the patches from github's repository into
the for-next branch.

Thanks,
Slava.

Re: [RFC] Sending NILFS2 patches into upstream

[Ryusuke Konishi]

Hi Viacheslav,

On Wed, Nov 5, 2025 at 5:10 AM Viacheslav Dubeyko wrote:
>
> Hi Ryusuke,
>
> On Tue, 2025-11-04 at 19:41 +0900, Ryusuke Konishi wrote:
> > On Tue, Nov 4, 2025 at 5:37 AM Viacheslav Dubeyko wrote:
> > >
> > > Hi Ryusuke,
> > >
> > > Currently, you ask Andrew Morton of sending NILFS2 patches into
> > > upstream. But Andrew is busy and it makes the whole workflow
> > > complicated and unpredictable.
> > >
> > > I am sending HFS/HFS+ patches to upstream. So, I can create the
> > > dedicated NILFS2 kernel tree on kernel.org and I can send NILFS2
> > > patches upstream. I believe that it can make the whole patch
> > > management
> > > workflow more flexible and predictable. Also, additional maintainer
> > > is
> > > better than to have only one.
> > >
> > > We already had some discussion privately. So, let's continue the
> > > discussion in the email list. What do you think?
> > >
> > > Thanks,
> > > Slava.
> >
> > Hi Viacheslav,
> >
> > Yes, thanks for the suggestion.
> >
> > As I replied to you privately earlier, I'd welcome your help both
> > with
> > upstreaming and setting up the git tree on kernel.org.
> >
> > First, I'll start by adding you as a maintainer.
> > To do this, I'd like to send a patch with changes to the maintainers
> > file to Andrew.
>
> Sounds good! Probably, I can create the NILFS2 kernel tree on
> kernel.org at first. And, then this patch can be sent with adding the
> link to this kernel tree into MAINTAINERS file.

Yes, it's OK to set up a git repository first.
In that case, we will only need to make the changes to the MAINTAINERS
file once, so I'll send one patch for the next merge window.

Not only do we add an M: field and switch the T: field, but the S:
field in the MAINTAINERS file should also be updated to reflect the
current status, so I'll make these changes all at once.

Please let me know where the repository is once you've set it up.

> >
> > Currently, bug fix patches and patches for the next merge window are
> > being sent to Andrew, so to avoid confusion, I think it would be best
> > to switch the upstreaming path after the next merge window is over.
> >
> > I'd like patches after the next merge window to be upstreamed via
> > you.
> > What do you think about this timing?
> >
> > As for switching the git repository in the MAINTAINERS file, how
> > about
> > after 6.19-rc1, again to avoid confusion?
>
> Yes, makes sense. I am having the same in mind. Because, anyway,
> preparing the whole workflow will require some time.
>
> >
> > Next, as for upstreaming, one option is for you to directly pick up
> > patches sent to this mailing list, and I can review and test them.
> > However, I think it's better to change the maintenance flow
> > gradually,
> > so initially I would like to pick up patches, add my Signed-of-by
> > tag,
> > and complement them with appropriate tags such as Fixes or Cc:
> > stable.
> >
> > To do this, I think it would be best to relay patches or their series
> > to the repository you set up on kernel.org via my current GitHub
> > repository.
> >
> > In practice, I will push the collected patches, signed, with tags
> > like
> > fixes-6.19-<serial number> or for-6.20-<serial number> to my current
> > GitHub repository, so please cherry pick them to receive them
> > initially.
>
> I assume that, currently, NILFS2 hasn't active development and to send
> patches for the first merge window in the cycle (for-6.20-rc1, for
> example) could be completely enough.
>
> >
> > Patches with tags starting with fixes- prefix are intended to be sent
> > as bug fixes in that cycle, while patches with tags starting with
> > for-<version number>- prefix are intended to be sent for the merge
> > window of the next cycle.
> > It would be ideal if I could automate the notification of pushes, but
> > initially I will send you an email.
>
> Makes sense. We can use this model of operations.
>
> >
> > Next, regarding the operation of the repository to be set up on
> > kernel.org, I think you should create a main branch of the nilfs2
> > project to send pull requests to Linus.
> >
> > I haven't created a main branch for the nilfs2 project so far, but I
> > think it's better to have one when collaborating.
> >
> > In this regard, how do you maintain the HFS/HFS+ tree?
>
> So, I have two branches for-next and for-linux. I am resetting it to
> the last rc1 tag. And, then, I am collecting patches in the for-next
> branch at first by means of b4 am <MSG ID> + git am -s <mbox file>.
> When I have enough patches for a merge window, then I execute these
> steps:
>
> $ git checkout for-linus
> $ git rebase for-next
> $ echo -e "hfs updates for v6.18\n" > ../hfs-v6.18-changes.txt
> $ git log --pretty=format:"- %s" v6.17-rc1..HEAD >> ../hfs-v6.18-
> changes.txt
> $ git tag -s hfs-v6.18-tag1 for-linus # (paste the contents of "hfs-
> v6.18-changes.txt" here)
> $ git push origin --all
> $ git push origin --tags
> $ git request-pull master
> git://git.kernel.org/pub/scm/linux/kernel/git/vdubeyko/hfs.git hfs-
> v6.18-tag1 > ../hfs-v6.18-pull-request.txt
> $ git branch for-v6.18
> $ git push origin --all
> $ git push origin --tags
>
> Finally, I am sending hfs-v6.18-pull-request.txt by email as pull
> request.
>
> So, I could have the same two branches for-next and for-linux for the
> case of NILFS2. The for-next branch could receive patches from github,
> the rest steps could be the same. I simply need to elaborate the
> steps/commands to cherry pick the patches from github's repository into
> the for-next branch.

Thanks for the detailed explanation of the steps ;)
It's almost exactly what I used to do a long time ago.

Yes, in that case, I don't think there's any need to change the
method, so please operate the nilfs2 upstreaming tree in the same way
- as before, let's exchange patches without creating a main branch for
the project.

Thanks,
Ryusuke Konishi

Re: [RFC] Sending NILFS2 patches into upstream

[Viacheslav Dubeyko]

Hi Ryusuke,

On Wed, 2025-11-05 at 15:44 +0900, Ryusuke Konishi wrote:
> Hi Viacheslav,
> 
> On Wed, Nov 5, 2025 at 5:10 AM Viacheslav Dubeyko wrote:
> > 
> > Hi Ryusuke,
> > 
> > On Tue, 2025-11-04 at 19:41 +0900, Ryusuke Konishi wrote:
> > > On Tue, Nov 4, 2025 at 5:37 AM Viacheslav Dubeyko wrote:
> > > > 
> > > > Hi Ryusuke,
> > > > 
> > > > Currently, you ask Andrew Morton of sending NILFS2 patches into
> > > > upstream. But Andrew is busy and it makes the whole workflow
> > > > complicated and unpredictable.
> > > > 
> > > > I am sending HFS/HFS+ patches to upstream. So, I can create the
> > > > dedicated NILFS2 kernel tree on kernel.org and I can send
> > > > NILFS2
> > > > patches upstream. I believe that it can make the whole patch
> > > > management
> > > > workflow more flexible and predictable. Also, additional
> > > > maintainer
> > > > is
> > > > better than to have only one.
> > > > 
> > > > We already had some discussion privately. So, let's continue
> > > > the
> > > > discussion in the email list. What do you think?
> > > > 
> > > > Thanks,
> > > > Slava.
> > > 
> > > Hi Viacheslav,
> > > 
> > > Yes, thanks for the suggestion.
> > > 
> > > As I replied to you privately earlier, I'd welcome your help both
> > > with
> > > upstreaming and setting up the git tree on kernel.org.
> > > 
> > > First, I'll start by adding you as a maintainer.
> > > To do this, I'd like to send a patch with changes to the
> > > maintainers
> > > file to Andrew.
> > 
> > Sounds good! Probably, I can create the NILFS2 kernel tree on
> > kernel.org at first. And, then this patch can be sent with adding
> > the
> > link to this kernel tree into MAINTAINERS file.
> 
> Yes, it's OK to set up a git repository first.
> In that case, we will only need to make the changes to the
> MAINTAINERS
> file once, so I'll send one patch for the next merge window.
> 
> Not only do we add an M: field and switch the T: field, but the S:
> field in the MAINTAINERS file should also be updated to reflect the
> current status, so I'll make these changes all at once.
> 
> Please let me know where the repository is once you've set it up.
> 
> > 

I've created the repository today:

git://git.kernel.org/pub/scm/linux/kernel/git/vdubeyko/nilfs2.git

And I've added two branches there:

git branch --all
  for-linus
* for-next
  master
  remotes/origin/HEAD -> origin/master
  remotes/origin/for-linus
  remotes/origin/for-next
  remotes/origin/master

Thanks,
Slava.

Re: [RFC] Sending NILFS2 patches into upstream

[Ryusuke Konishi]

On Fri, Nov 7, 2025 at 4:33 AM Viacheslav Dubeyko wrote:
>
> Hi Ryusuke,
>
> On Wed, 2025-11-05 at 15:44 +0900, Ryusuke Konishi wrote:
> > Hi Viacheslav,
> >
> > On Wed, Nov 5, 2025 at 5:10 AM Viacheslav Dubeyko wrote:
> > >
> > > Hi Ryusuke,
> > >
> > > On Tue, 2025-11-04 at 19:41 +0900, Ryusuke Konishi wrote:
> > > > On Tue, Nov 4, 2025 at 5:37 AM Viacheslav Dubeyko wrote:
> > > > >
> > > > > Hi Ryusuke,
> > > > >
> > > > > Currently, you ask Andrew Morton of sending NILFS2 patches into
> > > > > upstream. But Andrew is busy and it makes the whole workflow
> > > > > complicated and unpredictable.
> > > > >
> > > > > I am sending HFS/HFS+ patches to upstream. So, I can create the
> > > > > dedicated NILFS2 kernel tree on kernel.org and I can send
> > > > > NILFS2
> > > > > patches upstream. I believe that it can make the whole patch
> > > > > management
> > > > > workflow more flexible and predictable. Also, additional
> > > > > maintainer
> > > > > is
> > > > > better than to have only one.
> > > > >
> > > > > We already had some discussion privately. So, let's continue
> > > > > the
> > > > > discussion in the email list. What do you think?
> > > > >
> > > > > Thanks,
> > > > > Slava.
> > > >
> > > > Hi Viacheslav,
> > > >
> > > > Yes, thanks for the suggestion.
> > > >
> > > > As I replied to you privately earlier, I'd welcome your help both
> > > > with
> > > > upstreaming and setting up the git tree on kernel.org.
> > > >
> > > > First, I'll start by adding you as a maintainer.
> > > > To do this, I'd like to send a patch with changes to the
> > > > maintainers
> > > > file to Andrew.
> > >
> > > Sounds good! Probably, I can create the NILFS2 kernel tree on
> > > kernel.org at first. And, then this patch can be sent with adding
> > > the
> > > link to this kernel tree into MAINTAINERS file.
> >
> > Yes, it's OK to set up a git repository first.
> > In that case, we will only need to make the changes to the
> > MAINTAINERS
> > file once, so I'll send one patch for the next merge window.
> >
> > Not only do we add an M: field and switch the T: field, but the S:
> > field in the MAINTAINERS file should also be updated to reflect the
> > current status, so I'll make these changes all at once.
> >
> > Please let me know where the repository is once you've set it up.
> >
> > >
>
> I've created the repository today:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/vdubeyko/nilfs2.git
>
> And I've added two branches there:
>
> git branch --all
>   for-linus
> * for-next
>   master
>   remotes/origin/HEAD -> origin/master
>   remotes/origin/for-linus
>   remotes/origin/for-next
>   remotes/origin/master
>
> Thanks,
> Slava.

Thank you for setting up the git repository.

I just sent a patch with the MAINTAINERS changes, including that
location, so if you'd like, please send an Ack to Andrew as a reply.

Thanks,
Ryusuke Konishi