Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1455532 > unrolled thread

linux-next: please clean up the livepatching tree

Back to article view | Back to linux.kernel

Contents

  linux-next: please clean up the livepatching tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-08-03 01:40 +0200
    Re: linux-next: please clean up the livepatching tree Jiri Kosina <jikos@kernel.org> - 2016-08-03 02:00 +0200
      Re: linux-next: please clean up the livepatching tree Stephen Rothwell <sfr@canb.auug.org.au> - 2016-08-03 03:40 +0200
        Re: linux-next: please clean up the livepatching tree Jiri Kosina <jikos@kernel.org> - 2016-08-03 12:50 +0200
          Re: linux-next: please clean up the livepatching tree Takashi Iwai <tiwai@suse.de> - 2016-08-05 09:10 +0200
            Re: linux-next: please clean up the livepatching tree Jiri Kosina <jikos@kernel.org> - 2016-08-05 15:20 +0200

#1455532 — linux-next: please clean up the livepatching tree

Hi Jiri,

The livepatching tree
(git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching#for-next)
today consists of only lots of merges (and a patch that is also reverted).
Please just reset it to somewhere in Linus' tree.

-- 
Cheers,
Stephen Rothwell

[toc] | [next] | [standalone]

#1455539

Hi Stephen

On Wed, 3 Aug 2016, Stephen Rothwell wrote:

> The livepatching tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching#for-next)
> today consists of only lots of merges 

This is a part we keep discussing from time to time, and I still don't 
understand why it bothers you so much. The only reason is to keep the 
branch non-rebasing, because it has downstreams. Code-wise, it's always 
equivalent to what end up being merged, but without the actual superfluous 
merge commits.

> (and a patch that is also reverted).

This of course is a good justification to rebase for-next exceptionally; 
so I've just that.

Thanks,

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1455569

Hi Jiri,

On Wed, 3 Aug 2016 01:41:17 +0200 (CEST) Jiri Kosina <jikos@kernel.org> wrote:
>
> On Wed, 3 Aug 2016, Stephen Rothwell wrote:
> 
> > The livepatching tree
> > (git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching#for-next)
> > today consists of only lots of merges   
> 
> This is a part we keep discussing from time to time, and I still don't 
> understand why it bothers you so much. The only reason is to keep the 
> branch non-rebasing, because it has downstreams. Code-wise, it's always 
> equivalent to what end up being merged, but without the actual superfluous 
> merge commits.

The problem from my point of view is that git seems to take more time
to merge the tree into linux-next (I know this isn't much for just one
tree, but I currently have over 200 trees to merge each day).  Also,
having all those extra merges complicates the structure of my tree and
presumably makes it harder for git to merge other trees.  Its also
possible (I have seen this in other trees) for the merge commits
themselves to generate conflicts with (merge) commits in Linus' and
other trees.

Also, I am not sure why you have a branch that ask Linus to merge
separate from the branch you have me merge?

> > (and a patch that is also reverted).  
> 
> This of course is a good justification to rebase for-next exceptionally; 
> so I've just that.

Thanks.

-- 
Cheers,
Stephen Rothwell

[toc] | [prev] | [next] | [standalone]

#1455739

On Wed, 3 Aug 2016, Stephen Rothwell wrote:

> > This is a part we keep discussing from time to time, and I still don't 
> > understand why it bothers you so much. The only reason is to keep the 
> > branch non-rebasing, because it has downstreams. Code-wise, it's 
> > always equivalent to what end up being merged, but without the actual 
> > superfluous merge commits.
> 
> The problem from my point of view is that git seems to take more time
> to merge the tree into linux-next (I know this isn't much for just one
> tree, but I currently have over 200 trees to merge each day).  

Because of merge commits the number of which is below 100? That's an 
interesting observation and quite unexpected bottleneck in git.

> Also, having all those extra merges complicates the structure of my tree 
> and presumably makes it harder for git to merge other trees.  Its also 
> possible (I have seen this in other trees) for the merge commits 
> themselves to generate conflicts with (merge) commits in Linus' and 
> other trees.
> 
> Also, I am not sure why you have a branch that ask Linus to merge 
> separate from the branch you have me merge?

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?

If this is so bothering for you, I'd just start instructing for-next 
downstreams to stop using that branch so that it could be easily rebased.

Thanks,

-- 
Jiri Kosina
SUSE Labs

[toc] | [prev] | [next] | [standalone]

#1456904

On Wed, 03 Aug 2016 11:29:02 +0200,
Jiri Kosina wrote:
> 
> On Wed, 3 Aug 2016, Stephen Rothwell wrote:
> 
> > > This is a part we keep discussing from time to time, and I still don't 
> > > understand why it bothers you so much. The only reason is to keep the 
> > > branch non-rebasing, because it has downstreams. Code-wise, it's 
> > > always equivalent to what end up being merged, but without the actual 
> > > superfluous merge commits.
> > 
> > The problem from my point of view is that git seems to take more time
> > to merge the tree into linux-next (I know this isn't much for just one
> > tree, but I currently have over 200 trees to merge each day).  
> 
> Because of merge commits the number of which is below 100? That's an 
> interesting observation and quite unexpected bottleneck in git.
> 
> > Also, having all those extra merges complicates the structure of my tree 
> > and presumably makes it harder for git to merge other trees.  Its also 
> > possible (I have seen this in other trees) for the merge commits 
> > themselves to generate conflicts with (merge) commits in Linus' and 
> > other trees.
> > 
> > Also, I am not sure why you have a branch that ask Linus to merge 
> > separate from the branch you have me merge?
> 
> 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?


Takashi

[toc] | [prev] | [next] | [standalone]

#1457089

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web