linux-kernel - Re: linux-next: manual merge of the msm tree with the arm 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] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 18 Oct 2010 13:37:31 -0700
From:	Daniel Walker <dwalker@...o99.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Nicolas Pitre <nico@...xnic.net>,
	Russell King <rmk@....linux.org.uk>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	linux-next@...r.kernel.org, linux-kernel@...r.kernel.org,
	Jeremy Kerr <jeremy.kerr@...onical.com>,
	Jeff Ohlstein <johlstei@...eaurora.org>
Subject: Re: linux-next: manual merge of the msm tree with the arm tree

On Mon, 2010-10-18 at 22:19 +0200, Arnd Bergmann wrote:
> On Monday 18 October 2010 22:12:54 Daniel Walker wrote:
> > On Mon, 2010-10-18 at 15:29 -0400, Nicolas Pitre wrote:
> > 
> > > > Ok, well in that case why not accept this immediately after the merge
> > > > window? A point when everything is quiet, and most of the tree's are
> > > > empty?
> > > 
> > > RMK has his own merge window which closes about at the same time as 
> > > Linus' one opens.  We thought this was happening last week and therefore 
> > > this change was supposed to be the last one.
> > 
> > It seems like that could potentially make these kinds of problem worse,
> > since your merging things immediately before sending them to Linus. Like
> > right now we only have a fairly short amount of time to correct this
> > conflict. 
> 
> What Nicolas was talking about is the *end* of the merge window, not the
> start. This is how all sensible maintainer trees work: you get to
> merge stuff into the maintainer tree for a number of weeks (some start
> at -rc1, other start a bit later). When Linus tells people to get ready
> for the release, the subsystem goes into regression fix mode and when
> Linus opens his merge window, everything should be reasonably stable.

I think the term "merge window" is a little mis-leading here.. Your
describing development. To me the term merge window is indicating a
short period when you get changes in, not the whole -rc cycle.

> > > > Well how about I merge this change into my tree ?
> > > 
> > > If you ask RMK to merge your tree in his that would be much simpler to 
> > > add this change in a single pass afterwards.
> > 
> > I can do that , but would I still be able to merge stuff into my tree?
> > Seems like I could, Russell would just clean up the conflict and my tree
> > would just move forward like it has been already , and I would send the
> > whole thing to Linus.
> 
> When you know that Russell does not rebase his tree, you can pull his
> tree into yours whenever a change hits his tree that impacts you in
> a major way. You shouldn't do this too frequently, but it's a good way
> to resolve conflicts like this one.

If I did that all of Russell's changesets would get mixed with mine when
I send the pull request .. That would just create confusion .. It's OK
if Russell sends my commits to Linus, but I'm not going to send
Russell's commits.

Daniel

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/