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]
Message-ID: <1287434251.5588.23.camel@c-dwalke-linux.qualcomm.com>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ