linux-kernel - Re: New tree for linux-next

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:	Thu, 21 Mar 2013 00:09:53 +0000
From:	Grant Likely <grant.likely@...retlab.ca>
To:	Stephen Rothwell <sfr@...b.auug.org.au>
Cc:	Alexandre Courbot <gnurou@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	linux-next <linux-next@...r.kernel.org>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: New tree for linux-next

On Wed, Mar 20, 2013 at 11:47 PM, Stephen Rothwell <sfr@...b.auug.org.au> wrote:
> Hi Alexandre,
>
> On Wed, 20 Mar 2013 23:02:14 +0900 Alexandre Courbot <gnurou@...il.com> wrote:
>>
>> I am currently trying to get rid of the GENERIC_GPIO config option in
>> order to center GPIO support around gpiolib. The patch series has been
>> rather welcome and I collected a few acks, but since the change is
>> rather intrusive and affects a lot of of architectures, it has been
>> suggested that I submit it as a separate branch on linux-next to see
>> how it (mis)behaves (full discussion is visible at
>> https://lkml.org/lkml/2013/3/13/74 ).
>
> OK, that seems sensible.
>
>> So I have set up a branch on github on
>> git://github.com/Gnurou/linux.git , for_next branch. Could you include
>> it in linux-next to see if people start complaining about broken
>> builds? I also actually have a couple questions about the submission
>> process:
>
> Added from today.  I have called it gen-gpio and you are the only listed
> contact (in case I have problems with it).
>
>> - My branch is based on the latest stable, similarly to what I have
>> seen elsewhere. One of the patches triggers a merge conflict on
>> today's linux-next due to a whitespace change. Is there something I
>> can do to fix this?
>
> Do not worry about merge conflicts, that is my and Linus' job.

Latest stable? As in based on one of the linux-stable point releases
(That Greg does) or based on Linus' tree? It must be based on Linus'
tree to be mergable into mainline.

>
>> - By the meantime, another person has submited a new patch that
>> re-uses the option I am trying to remove. Is there a way for me to
>> base on given next release to fix this as well? Or should I contact
>> that person to ask him not to use this option anymore?
>
> The latter.  Also if you could supply me (and them) with any hints on how
> to cope with the merge problem, that would help.
>
> One point:  if this branch is meant to be merged by others, it *must not*
> be rebased or rewritten, it can only be appended to.

Eventually I will want to pull this into my gpio-next tree, but I'll
give it a bit to see how it shakes out. Regardless I'll let you know
when I want to do so and so you'll know when it can no longer be
rebased.

g.
--
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/