Re: [MAINTAINERS SUMMIT] Any feedback for -next?
Arnaldo Carvalho de Melo <[email protected]>
| Newsgroups | org.kernel.vger.linux-next,dev.linux.lists.ksummit |
|---|---|
| Message-ID | <anzMNXw9_mRL-8-_@x1> |
On Wed, Aug 12, 2026 at 10:37:34AM -0700, Guenter Roeck wrote: > On 8/12/26 10:14, Arnaldo Carvalho de Melo wrote: > > On Wed, Aug 12, 2026 at 10:10:17AM -0700, Guenter Roeck wrote: > > > On 8/12/26 08:59, Lee Jones wrote: > > > > On Wed, 12 Aug 2026, Steven Rostedt wrote: > > > > > On Wed, 12 Aug 2026 04:42:21 -0700 > > > > > Breno Leitao <[email protected]> wrote: > > > > > > On Tue, Aug 11, 2026 at 05:54:59PM +0100, Mark Brown wrote: > > > > > > Would getting rid of these ephemeral commits make linux-next easier > > > > > > to work with? > > > > > > > This has come up at the Maintainers Summit in the past. I believe it is > > > > > even in the article I posted earlier in another thread. > > > > > > > https://lwn.net/Articles/1050027/ > > > > > > > We are even discussing issues about this in that other thread as well: > > > > > > > https://lore.kernel.org/all/[email protected]/ > > > > > > > I try to keep my linux-next branch clean, but I do rebase to add tags. I do > > > > > on occasion remove commits if they prove to be totally broken. That's rare > > > > > but I rather have that then having to push something to Linus where a bunch > > > > > of commits are simply reverted. > > > > > > +1 > > > > > > FWIW, I have always reserved the right to rebase in order to remove, > > > > move around, reword and otherwise fix-up commits and do so often. To > > > > that end my 'next' branches are not, have ever been, nor do I intend > > > > them to ever be, stable. > > > Same here. > > I do it as a last resort, but its better to avoid having bug+fix things > > hitting upstream, i.e. trying to help with upstream bisectability. > > That, but mostly adding tags. I do add committer notes while merging patches, that I don't do using git merge (shame on me), but then downstreamers don't hand me git repos to pull from. But in my case since documentation on how to use new features is difficult to get and I don't want to make that a requirement (shame on me), I end up testing the new feature with a before and after, recording precise set of instructions on how to use it so that at least I can go back and check how to test that feature if something looks wrong aftwerwards. - Arnaldo