linux-kernel - Re: linux-next: please clean up the livepatching tree

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Fri, 5 Aug 2016 15:11:07 +0200 (CEST)
From:	Jiri Kosina <jikos@...nel.org>
To:	Takashi Iwai <tiwai@...e.de>
cc:	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: linux-next: please clean up the livepatching tree

On Fri, 5 Aug 2016, Takashi Iwai wrote:

> > Exactly to avoid Linus' tree being polluted by the extra merge commits.
> > 
> > My workflow is really simple -- development happens in (a lot of) topic 
> > branches, and each and every time any of the topic branches is updated by 
> > a new commit, that topic branch gets merged into for-next.
> > 
> > Once code should go to Linus, the branches are merged at once into 
> > 'for-linus' brach, and it's guaranteed to be code-wise the same as what 
> > was gradually appearing in for-next.
> > 
> > What other workflow do you suggest for maintainers like me, who are using 
> > a lot of topic branches?
> 
> Maybe refreshing merges in for-next branch at each time (or day)
> instead of incremental merges?

That slightly breaks for for-next downstreams, but one can successfully 
counter that by the fact that topic branches should be the only ones 
having downstreams, and for-next should be upstream solely for linux-next.

I'll experiment with this during the next cycle.

Thanks,

-- 
Jiri Kosina
SUSE Labs