On Oct 20, 2008, at 7:11 PM, Benjamin Herrenschmidt wrote:

On Mon, 2008-10-20 at 13:04 -0500, Kumar Gala wrote:
Please pull from 'for-2.6.28' branch of

master.kernel.org:/pub/scm/linux/kernel/git/galak/powerpc.git for-2.6.28

to receive the following updates:

Ok so I'm not too happy. Kumar, you need to be a little bit more careful
with your git tree. Here are a few things that are causing me problems
at the moment and making me not pull this one. Some of them I already
sent separate emails for but let's put it all together:

- First, please try to keep a consistent merge branch. Even if it ends
up merging separate branches from you internally.

Yeah, I got the message.

- Please use git request-pull or at least provide me with the merge
base in the email if it's not my current master or next HEAD, and since it makes my life a bit harder too, please try to have your tree based on
mine unless you have some conflicts to sort out.

will do.

- Please spend a bit more time cleaning up the cset subjects and
comments. For example:

        "powerpc: remove device_type = "boad_control"

There are a few problems with this one. Not everybody knows what
"device_type" is, it's not obvious that it's a device-tree change, and
you may notice that I've been trying to keep the first character after
the category: uppercase. I would have preferred something like:

powerpc: Remove device_type = "board_control" properties in .dts files

Another one that doesn't pass my criteria is:

        OF: SPI: specify chip select active high

I don't like caps, and it's not the generally accepted format. It should
be something like:

        of/spi: Provide a way to specify chip select polarity

Nicer heh ?

If you had conventions on naming this is the first I've heard of them. I know Paul asked about the [POWERPC] to powerpc: change on list.

I almost always rewrite subjects and sometimes fixup descriptions when I
merge patches. Please do so too.

I do so as well. As stated above, if there are naming conventions that are desired I'm happy to conform but just need to know what they are.

- Finally, the Kconfig change shouldn't have been in your tree at all,
or at least not without my or paulus ack and prior argeement that it
should be merged that way. No big deal with this obviously correct
patch but where do we put the limit ?


The limit is based on trust. I submitted all the other cleanup patches to remove PPC_MERGE. I think I can handle such a patch going via my tree.

- k
_______________________________________________
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev

Reply via email to