linux-kernel - Re: HTC Dream aka. t-mobile g1 support

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: <20090611140038.GB11199@atomide.com>
Date:	Thu, 11 Jun 2009 07:00:39 -0700
From:	Tony Lindgren <tony@...mide.com>
To:	Russell King - ARM Linux <linux@....linux.org.uk>
Cc:	Alan Cox <alan@...rguk.ukuu.org.uk>,
	David Miller <davem@...emloft.net>, swetland@...gle.com,
	pavel@....cz, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.arm.linux.org.uk, san@...roid.com,
	rlove@...gle.com
Subject: Re: HTC Dream aka. t-mobile g1 support

* Russell King - ARM Linux <linux@....linux.org.uk> [090611 06:38]:
> On Thu, Jun 11, 2009 at 06:21:35AM -0700, Tony Lindgren wrote:
> > We've done this for two merge windows now for omap patches where the
> > patches have been posted to linux-arm-kernel, then they go into the
> > for-next tree, and then Russell merges them in.
> > 
> > It has worked OK, although Russell had some comments about having hard
> > time keeping track on what he had reviewed already.
> 
> Yes, as I understand it, there was a closed room discussion between
> several folk about how you'd handle sending your next round of patches
> to me.

Yes, this was to coordinate the merge conflicts that we knew were going
to happen.
 
> What you apparantly decided (and I'm saying this from how it appeared
> on the receiving end and sort-of had it confirmed by Kevin in conference)
> is that you'd send a patch set for me to review, I'd review it, and then
> you'd merge it within your git tree into a branch for me.  You'd then do
> the same thing with the next patch set, and so forth.
> 
> Eventually, near the merge window, you sent a pull request for the
> entire lot, by which time I looked at the list of changes and wondered
> whether that encompassed everything you'd asked me to review, or whether
> it contained extra stuff, or whether it was for something quite different,
> or what.

Hmm, well it was what was posted to the list, and I kept piling it up
into for-next as the patchsets got reviewed.
 
> So by separating the review from the merge by weeks or even months, it
> created additional problems.

Yeah this can be a problem as at that point you have to pull or check
the patches again if you don't trust people to send you the stuff that got
posted earlier.

You suggested pulling each set as they get reviewed into some omap branch
in your tree, do you want to try that the next merge window?

What I can easily see happening with this approach is that we end up waiting
1 - 2 weeks between each set before you pull, which can make merging painfully
slow as we may have let's say five 10 patch sets to merge.

Also, what do we do with the sets that you don't have time to review or
don't want to review?

Regards,

Tony
--
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/