From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 865BF1365 for ; Tue, 18 Sep 2018 20:20:22 +0000 (UTC) Received: from mx1.suse.de (mx2.suse.de [195.135.220.15]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 686137F4 for ; Tue, 18 Sep 2018 20:20:20 +0000 (UTC) Date: Tue, 18 Sep 2018 22:20:17 +0200 Message-ID: From: Takashi Iwai To: Mark Brown In-Reply-To: <20180918161200.GL2471@sirena.org.uk> References: <1536142432.8121.6.camel@HansenPartnership.com> <20180905113715.GJ9781@sirena.org.uk> <20180905150315.GA10819@linux.vnet.ibm.com> <20180905115008.22e3d21f@gandalf.local.home> <20180905162007.GO4225@linux.vnet.ibm.com> <1536165914.3627.17.camel@HansenPartnership.com> <1536176428.3627.28.camel@HansenPartnership.com> <20180918161200.GL2471@sirena.org.uk> MIME-Version: 1.0 (generated by SEMI 1.14.6 - "Maruoka") Content-Type: text/plain; charset=US-ASCII Cc: James Bottomley , "ksummit-discuss@lists.linuxfoundation.org" Subject: Re: [Ksummit-discuss] [MAINTAINER SUMMIT] Distribution kernel bugzillas considered harmful List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , On Tue, 18 Sep 2018 18:12:01 +0200, Mark Brown wrote: > > On Tue, Sep 18, 2018 at 09:43:08AM -0400, Martin K. Petersen wrote: > > > 1. I could just always revert instead of dropping the patches. The > > downside is that we end up with a pretty messy history because, as I > > pointed out above, it's usually a matter of dropping tens of patches > > at a time and not reverting a single offending commit. In addition, > > having a messy history makes it harder on distro kernel people to > > track driver updates. > > I used to deal with this by using topic branches heavily and making my > -next be an automated merge of those branches, if something went badly I > could just throw away the branch. I stopped for a while because Linus > didn't like the number of branches I was creating, though it wasn't a > problem with the approach in general. I think that the topic branch approach would work well if you merge topic branches back to the main branch more often. That is, each topic branch lives only for a relatively short time (e.g. a few weeks), and not merging the whole branches in a shot at the end of the development cycle. Basically the merge to the main branch "fixates" the developments of the given topic, hence other people can start working on the commits safely. Meanwhile the not-yet-merged branches can be still thrown away if they are really bad. Takashi