Messages in this thread | | | Date | Tue, 18 Jun 2013 10:45:51 +0200 | From | Nicolas Ferre <> | Subject | Re: RE : [GIT PULL] at91: soc updates for 3.11 #1 |
| |
On 17/06/2013 18:59, Olof Johansson : > On Mon, Jun 17, 2013 at 2:20 AM, Ferre, Nicolas <Nicolas.FERRE@atmel.com> wrote: >> From: Olof Johansson [olof@lixom.net] >>> Hi, >>> >>> On Fri, Jun 14, 2013 at 11:42:18PM +0200, Nicolas Ferre wrote: >>>> Arnd, Olof, >>>> >>>> A little AT91 pull-request for patches that are more targeted to SoC/boards >>>> modifications. It is prepared on top of the arm-soc/at91/cleanup branch. >>>> >>>> Thanks, best regards, >>>> >>>> The following changes since commit b3f442b0eedbc20b5ce3f4a96530588d14901199: >>>> >>>> ARM: at91: udpate defconfigs (2013-05-17 15:05:08 +0200) >>>> >>>> are available in the git repository at: >>>> >>>> git://github.com/at91linux/linux-at91.git tags/at91-soc >>>> >>>> for you to fetch changes up to 7e75545ea7fb972c3da759f92c3d0be84d1cee72: >>>> >>>> ARM: at91: drop rm9200dk board support (2013-06-14 23:34:11 +0200) >>>> >>>> ---------------------------------------------------------------- >>>> Two non critical fixes that can go in 3.11. >>>> An old board removed. >>>> >>>> ---------------------------------------------------------------- >>>> Alexandre Belloni (1): >>>> ARM: at91: Fix link breakage when !CONFIG_PHYLIB >>> >>> Fix >>> >>>> Jean-Christophe PLAGNIOL-VILLARD (1): >>>> ARM: at91: drop rm9200dk board support >>> >>> Cleanup >>> >>>> Wenyou Yang (1): >>>> ARM: at91: Change the internal SRAM memory type MT_MEMORY_NONCACHED >>> >>> Fix >>> >>> ...assuming, of course, that none of the fixes are for errors introduced in >>> some branch we already pulled, since then they should go on top of that branch. >> >> I do agree with you but: >> 1/ the fixes are non-critical ones, so I do not see the need for another branch > > We're happy to take branches with fixes that are not needed for > current release and queue them for the next one. We tend to merge > those into next/fixes-non-critical. > >> 2/ I didn't feel like touching the "cleanup" branch because we want to base all our 3.11 material on top of it, without adding new patches on top. > > Adding new patches on top of a branch that is a base for something > else is just fine, and is the way you're supposed to do things. You > don't have to rebase the dependent branches just because they're not > based on the tip of the cleanup tree any more. I.e. just send another > pull request for "cleanups2" or whatever, that's based on the old > cleanups branch/tag. After that, cleanups3 would be based on > cleanups2. Etc. Some platforms do this a lot. > > Of course, that assumes that the additional cleanups don't conflict > heavy with the later dependent branches like I already said. I don't > think that was the case this time?
Fair enough, I have just sent 2 pull-requests: - a fixes-non-critical one - a cleanup one
Bye, -- Nicolas Ferre
| |