Thread (13 messages) flat view 13 messages, 4 authors, 2012-02-27

at91: pm.h cleanup

From: Nicolas Ferre <hidden>
Date: 2012-01-27 09:43:18

On 01/27/2012 12:34 AM, Russell King - ARM Linux :
On Thu, Jan 26, 2012 at 08:33:50PM +0000, Russell King - ARM Linux wrote:
quoted
On Thu, Jan 26, 2012 at 05:18:21PM +0100, Nicolas Ferre wrote:
quoted
Daniel,

I have rebased your patch series on top of:

- at91 late device/board patches that are planned for 3.3
- at91-fixes branch (should go also in 3.3)
* rmk/for-next branch (with a merge conflict resolved)
* the removal of CAP9 SoC family

You can find the resulting code in our git tree:

git://github.com/at91linux/linux-at91.git at91-pm_cleanup

I hope that I will be able to send this branch to arm-soc soon with a
minimum of future rebase (when the two first series cited above will be
in Linus' tree actually).
No you won't, not if you're including rmk/for-next in it.

Take a moment to think about that: rmk/for-next is NOT a topic branch.
It is purely a branch published for the sake of SFR.  It gets torn down
and regenerated regularly.  You can't base work off it.  It's all explained
here:

	http://www.arm.linux.org.uk/developer/git-arm.php
As a follow-up to this, your action has put in jeopardy two things:

1. The ability for me to publish patches in my git tree for people to be
   able to test large patch sets.

2. The ability to publish patches which are ready for mainline but have
   not yet had all the acks etc received.

The official position on the publication of git commits is that once
they're published, they can't be changed - with the exception of the
linux-next tree.

What that means is that if I followed that rule, I would not publish very
many changes until the last minute for the simple reason that people in
the ARM community absolutely suck to the back teeth giving acks and so
forth to large patch sets.  Example: had I followed that guidance, the
restart changes would not have gone in during the last merge window.

So, either *EVERYONE* understands how I run my tree and they DO NOT
EVER include any branch into their own tree without FIRST TALKING TO
ME, or I withdraw my tree from public access.  It's that simple.  It's
not something ANYONE can make a mistake over.  You make a mistake and
it causes BIG PROBLEMS.

SFR _has_ noticed and _is_ complaining about this.  It's only time
before it gets noticed elsewhere.

So, I've withdrawn the highly unstable devel-3.3 branch from public
view as of NOW.  I'm going to remove anything in for-next which isn't
100% ready.  That includes the mach-types update, because I intend
to redo it at some later time.

Congratulations.  And thanks for causing this situation through your
lack of due dilligence.
Russell,

So many problems on my shoulders!

I was just trying to anticipate the git branch that you are putting in
place for 3.4 development (your have now published one with "for-armsoc"
if I am following correctly the plans).

I was mentioning in my email that this at91-pm_cleanup branch may be
rebased and I *never* thought of making a pull request out of it.

My mistake was to push it to our at91-next which ends up being included
in linux-next. Yes it was dumb and I will ask Stephen to remove the
at91-next branch from his pull list.
AT91 will rely on arm-soc to get exposure in linux-next which is simpler
and less prone to errors.

Best regards,
-- 
Nicolas Ferre
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help