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, 08 Dec 2014 09:08:34 -0700
From:	Stephen Warren <swarren@...dotorg.org>
To:	Lee Jones <lee.jones@...aro.org>, Arnd Bergmann <arnd@...db.de>
CC:	linux-arm-kernel@...ts.infradead.org,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	Olof Johansson <olof@...om.net>,
	Matthias Klein <matthias.klein@...ux.com>,
	Hauke Mehrtens <hauke@...ke-m.de>,
	Rafał Miłecki <zajec5@...il.com>,
	linux-kernel@...r.kernel.org, linux-next@...r.kernel.org
Subject: Re: linux-next: manual merge of the bcm2835 tree with the arm-soc
 tree

On 12/08/2014 06:49 AM, Lee Jones wrote:
> On Mon, 08 Dec 2014, Arnd Bergmann wrote:
>
>> On Monday 08 December 2014 13:00:09 Lee Jones wrote:
>>> On Mon, 08 Dec 2014, Arnd Bergmann wrote:
>>>
>>>> On Monday 08 December 2014 12:06:19 Stephen Rothwell wrote:
>>>>> Hi Stephen,
>>>>>
>>>>> Today's linux-next merge of the bcm2835 tree got a conflict in
>>>>> arch/arm/boot/dts/Makefile between commit 302a5ef29d49 ("ARM: BCM5301X:
>>>>> Add DT for Netgear R6300 V2") from the arm-soc tree and commit
>>>>> 6298ed17a404 ("ARM: bcm2835: Add device tree for Raspberry Pi model
>>>>> B+") from the bcm2835 tree.
>>>>>
>>>>> I fixed it up (the bcm2835 tree patch is also in the arm-soc tree as
>>>>> commit ba2a1d6959ac ("ARM: bcm2835: Add device tree for Raspberry Pi
>>>>> model B+"), so I just used the arm-soc version) and can carry the fix
>>>>> as necessary (no action is required).
>>>>
>>>> Thanks a lot for the notification!
>>>>
>>>> Lee, do you know what is going on? Did you accidentally rebase a commit
>>>> that you already sent for inclusion in arm-soc?
>>>
>>> Nope.  The branch hasn't changed at all.
>>>
>>> OOI why would a re-base affect anything?  I sent you it in patch form.
>>
>> Ah, I looked at the wrong branch and didn't see that I applied a patch
>> instead of a pull request. It's all fine then, as long as you never
>> intend to send any pull requests based on top of your current branch.
>>
>> You can possibly make Stephen's life a tiny bit simpler if you just
>> drop all patches from your for-next branch as soon as we've picked
>> them up into arm-soc.
>
> That is something I thought about, but I believe we have users of that
> branch.  I guess we could always point them to ARM-SoC, or reset the
> branch to the aforementioned.

The primary purpose of the kernel.org linux-rpi.git repo is for staging 
patches into arm-soc/linux-next. As such, just like any other similar 
repo, users should expect at least the for-xxx (e.g. for-next) branches 
to get reset as kernel versions tick over, in order to contain the 
content for the next kernel. Anyone using those branches for anything 
else (e.g. local development) simply has to be prepared to do a rebase 
themselves when that happens.

Equally, and patches that get sent to arm-soc should probably never be 
applied to linux-rpi.git; anything that gets applied to linux-rpi.git 
should get sent to arm-soc as a pull request. That avoids duplicate commits.
--
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