next sync updates

next sync updates

[Jarkko Sakkinen]

Hi,

In order to address in long-term the issues reported by Linus [1], in
addition to improving my workflows, I've create two branches:

1. https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=for-next-tpm
2. https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=for-next-keys

These will replace the currently mirrored branch:

https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=next

So my request is to:

1. Include the two new branches.
2. Remove the old branch.

[1] https://lore.kernel.org/linux-integrity/aeVSbVIFaCDRXf7C@kernel.org/

BR, Jarkko

Re: next sync updates

[Stephen Rothwell]

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

Hi Jarkko,

On Tue, 21 Apr 2026 21:19:14 +0300 Jarkko Sakkinen <jarkko@kernel.org> wrote:
>
> In order to address in long-term the issues reported by Linus [1], in
> addition to improving my workflows, I've create two branches:
> 
> 1. https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=for-next-tpm
> 2. https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=for-next-keys
> 
> These will replace the currently mirrored branch:
> 
> https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=next
> 
> So my request is to:
> 
> 1. Include the two new branches.
> 2. Remove the old branch.
> 
> [1] https://lore.kernel.org/linux-integrity/aeVSbVIFaCDRXf7C@kernel.org/
> 
> BR, Jarkko

Linus-next is now being taken care of by Mark Brown (cc'd).
-- 
Cheers,
Stephen Rothwell

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

Re: next sync updates

[Jarkko Sakkinen]

On Wed, Apr 22, 2026 at 09:35:28AM +1000, Stephen Rothwell wrote:
> Hi Jarkko,
> 
> On Tue, 21 Apr 2026 21:19:14 +0300 Jarkko Sakkinen <jarkko@kernel.org> wrote:
> >
> > In order to address in long-term the issues reported by Linus [1], in
> > addition to improving my workflows, I've create two branches:
> > 
> > 1. https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=for-next-tpm
> > 2. https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=for-next-keys
> > 
> > These will replace the currently mirrored branch:
> > 
> > https://git.kernel.org/pub/scm/linux/kernel/git/jarkko/linux-tpmdd.git/log/?h=next
> > 
> > So my request is to:
> > 
> > 1. Include the two new branches.
> > 2. Remove the old branch.
> > 
> > [1] https://lore.kernel.org/linux-integrity/aeVSbVIFaCDRXf7C@kernel.org/
> > 
> > BR, Jarkko
> 
> Linus-next is now being taken care of by Mark Brown (cc'd).

Thank you for forwarding this.

Mark, the goal is to address the main problem Linus was complaining
about i.e., late rewrites of Git trees (aside from late cc stable
rewrite, which could have been prevented).

for-next-tpm and for-next-keys will replace 'next', which I will
delete after the change is effective.

> -- 
> Cheers,
> Stephen Rothwell

BR, Jarkko

Re: next sync updates

[Mark Brown]

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

On Wed, Apr 22, 2026 at 12:34:04PM +0300, Jarkko Sakkinen wrote:

> Mark, the goal is to address the main problem Linus was complaining
> about i.e., late rewrites of Git trees (aside from late cc stable
> rewrite, which could have been prevented).

> for-next-tpm and for-next-keys will replace 'next', which I will
> delete after the change is effective.

I didn't see this mail until after I'd started things running for today
but I've now updated the config so the two new trees should appear from
tomorrow as tpmdd-keys and tpmdd-tpm, and the old tpmdd tree has been
removed.

Thanks for adding your subsystem tree as a participant of linux-next.  As
you may know, this is not a judgement of your code.  The purpose of
linux-next is for integration testing and to lower the impact of
conflicts between subsystems in the next merge window.

You will need to ensure that the patches/commits in your tree/series have
been:
     * submitted under GPL v2 (or later) and include the Contributor's
        Signed-off-by,
     * posted to the relevant mailing list,
     * reviewed by you (or another maintainer of your subsystem tree),
     * successfully unit tested, and
     * destined for the current or next Linux merge window.

Basically, this should be just what you would send to Linus (or ask him
to fetch).  It is allowed to be rebased if you deem it necessary.

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

Re: next sync updates

[Jarkko Sakkinen]

On Wed, Apr 22, 2026 at 01:10:57PM +0100, Mark Brown wrote:
> On Wed, Apr 22, 2026 at 12:34:04PM +0300, Jarkko Sakkinen wrote:
> 
> > Mark, the goal is to address the main problem Linus was complaining
> > about i.e., late rewrites of Git trees (aside from late cc stable
> > rewrite, which could have been prevented).
> 
> > for-next-tpm and for-next-keys will replace 'next', which I will
> > delete after the change is effective.
> 
> I didn't see this mail until after I'd started things running for today
> but I've now updated the config so the two new trees should appear from
> tomorrow as tpmdd-keys and tpmdd-tpm, and the old tpmdd tree has been
> removed.

AFAIC, this was fast response time :-) (less than 24h)
 
> Thanks for adding your subsystem tree as a participant of linux-next.  As
> you may know, this is not a judgement of your code.  The purpose of
> linux-next is for integration testing and to lower the impact of
> conflicts between subsystems in the next merge window.
> 
> You will need to ensure that the patches/commits in your tree/series have
> been:
>      * submitted under GPL v2 (or later) and include the Contributor's
>         Signed-off-by,
>      * posted to the relevant mailing list,
>      * reviewed by you (or another maintainer of your subsystem tree),
>      * successfully unit tested, and
>      * destined for the current or next Linux merge window.

Sure.

> 
> Basically, this should be just what you would send to Linus (or ask him
> to fetch).  It is allowed to be rebased if you deem it necessary.

My old topology caused more noise than necessary, and was getting
difficult to manage, as each pull request required reorg of commits
in my next branch, every time I prepared a PR.

Thanks for your trouble.

BR, Jarkko