| Message ID | CAOesGMjHN-pvVfMN0o3AD238m8wEiRS-D4ArjV_2VAGTuwPfBw@mail.gmail.com |
|---|---|
| State | New |
| Headers | show |
On Sunday 14 August 2011, Olof Johansson wrote: > > Hi Arnd, > > Please pull the first set of tegra/board patches for 3.2: > > > The following changes since commit e6a99d312687a42c077a9b8cb5e757f186edb1b9: > > Merge branch 'slab/urgent' of > git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6 > (2011-08-09 08:42:16 -0700) > > are available in the git repository at: > > git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git boards-for-3.2 > Hi Olof, The contents all look good, but I'm undecided whether we should have branches that are not based on a -rc release. In your case, it's halfway between -rc1 and -rc2. Do others have an opinion? If we decide to take development branches only when they are based on a proper -rc, I'll do the simple rebase of the patches and push them out, otherwise I'll push them as they are. Arnd
On Tue, 16 Aug 2011, Arnd Bergmann wrote: > On Sunday 14 August 2011, Olof Johansson wrote: > > > > Hi Arnd, > > > > Please pull the first set of tegra/board patches for 3.2: > > > > > > The following changes since commit e6a99d312687a42c077a9b8cb5e757f186edb1b9: > > > > Merge branch 'slab/urgent' of > > git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6 > > (2011-08-09 08:42:16 -0700) > > > > are available in the git repository at: > > > > git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git boards-for-3.2 > > > > Hi Olof, > > The contents all look good, but I'm undecided whether we should have > branches that are not based on a -rc release. In your case, it's > halfway between -rc1 and -rc2. > > Do others have an opinion? If we decide to take development branches > only when they are based on a proper -rc, I'll do the simple rebase > of the patches and push them out, otherwise I'll push them as they are. Although this might be a nicety, I personally don't particularly care about the base being set on a tag. I think that keeping the original committer info intact is more valuable. Nicolas
On Tue, 16 Aug 2011, Nicolas Pitre wrote: > On Tue, 16 Aug 2011, Arnd Bergmann wrote: > > > On Sunday 14 August 2011, Olof Johansson wrote: > > > > > > Hi Arnd, > > > > > > Please pull the first set of tegra/board patches for 3.2: > > > > > > > > > The following changes since commit e6a99d312687a42c077a9b8cb5e757f186edb1b9: > > > > > > Merge branch 'slab/urgent' of > > > git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6 > > > (2011-08-09 08:42:16 -0700) > > > > > > are available in the git repository at: > > > > > > git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git boards-for-3.2 > > > > > > > Hi Olof, > > > > The contents all look good, but I'm undecided whether we should have > > branches that are not based on a -rc release. In your case, it's > > halfway between -rc1 and -rc2. > > > > Do others have an opinion? If we decide to take development branches > > only when they are based on a proper -rc, I'll do the simple rebase > > of the patches and push them out, otherwise I'll push them as they are. > > Although this might be a nicety, I personally don't particularly care > about the base being set on a tag. I think that keeping the original > committer info intact is more valuable. Right. In general having a devel branch based on a tag is a good thing, but as long as it's not some random commit from the middle of the merge window, it's fine. Thanks, tglx
On Tue, Aug 16, 2011 at 7:48 AM, Arnd Bergmann <arnd@arndb.de> wrote: > On Sunday 14 August 2011, Olof Johansson wrote: >> >> Hi Arnd, >> >> Please pull the first set of tegra/board patches for 3.2: >> >> >> The following changes since commit e6a99d312687a42c077a9b8cb5e757f186edb1b9: >> >> Merge branch 'slab/urgent' of >> git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6 >> (2011-08-09 08:42:16 -0700) >> >> are available in the git repository at: >> >> git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git boards-for-3.2 >> > > Hi Olof, > > The contents all look good, but I'm undecided whether we should have > branches that are not based on a -rc release. In your case, it's > halfway between -rc1 and -rc2. > > Do others have an opinion? If we decide to take development branches > only when they are based on a proper -rc, I'll do the simple rebase > of the patches and push them out, otherwise I'll push them as they are. I guess it depends on what you and others prefer -- if you want to aggregate the branches in arm-soc.git through the development weeks, or if you prefer to get most of the merge requests when platform maintainers are getting ready for the merge window and feeding things up? Either is fine with me -- if it's easier for me to hold off the merge requests a while, then I'll start a for-next branch and ask Stephen to add it, and rebase it a few times up until when the merge request to arm-soc is sent. Maybe it's just easier for everyone to do it that way -- the drawback is that there's less visibility about what's about to go in until the merge requests start to drop in late in the cycle. The git history won't be quite as wide then either. -Olof
On Tuesday 16 August 2011 12:30:50 Olof Johansson wrote: > On Tue, Aug 16, 2011 at 7:48 AM, Arnd Bergmann <arnd@arndb.de> wrote: > > > > The contents all look good, but I'm undecided whether we should have > > branches that are not based on a -rc release. In your case, it's > > halfway between -rc1 and -rc2. > > > > Do others have an opinion? If we decide to take development branches > > only when they are based on a proper -rc, I'll do the simple rebase > > of the patches and push them out, otherwise I'll push them as they are. > > I guess it depends on what you and others prefer -- if you want to > aggregate the branches in arm-soc.git through the development weeks, > or if you prefer to get most of the merge requests when platform > maintainers are getting ready for the merge window and feeding things > up? I definitely want to have the patches as early as possible, but not more than one pull request per branch per week or -rc ideally. > Either is fine with me -- if it's easier for me to hold off the merge > requests a while, then I'll start a for-next branch and ask Stephen to > add it, and rebase it a few times up until when the merge request to > arm-soc is sent. Maybe it's just easier for everyone to do it that way > -- the drawback is that there's less visibility about what's about to > go in until the merge requests start to drop in late in the cycle. The > git history won't be quite as wide then either. I would prefer to have all branches that I send to Linus go into the -next through the arm-soc tree as well, not get sent there individually. Basically, when you consider patches stable and ready for upstream and expect no further changes, I'll pull the patches into arm-soc.git and you can add further patches on top of the branch that I have already pulled (not on an aggregated branch) and I can pull that again. If you have unrelated changes, then I'd prefer them to be on top of an -rc release for the next pull request. Arnd
On Tue, Aug 16, 2011 at 2:12 PM, Arnd Bergmann <arnd@arndb.de> wrote: > On Tuesday 16 August 2011 12:30:50 Olof Johansson wrote: >> On Tue, Aug 16, 2011 at 7:48 AM, Arnd Bergmann <arnd@arndb.de> wrote: >> > >> > The contents all look good, but I'm undecided whether we should have >> > branches that are not based on a -rc release. In your case, it's >> > halfway between -rc1 and -rc2. >> > >> > Do others have an opinion? If we decide to take development branches >> > only when they are based on a proper -rc, I'll do the simple rebase >> > of the patches and push them out, otherwise I'll push them as they are. >> >> I guess it depends on what you and others prefer -- if you want to >> aggregate the branches in arm-soc.git through the development weeks, >> or if you prefer to get most of the merge requests when platform >> maintainers are getting ready for the merge window and feeding things >> up? > > I definitely want to have the patches as early as possible, but not > more than one pull request per branch per week or -rc ideally. That sounds reasonable. > I would prefer to have all branches that I send to Linus go into the > -next through the arm-soc tree as well, not get sent there individually. > > Basically, when you consider patches stable and ready for upstream > and expect no further changes, I'll pull the patches into arm-soc.git > and you can add further patches on top of the branch that I have already > pulled (not on an aggregated branch) and I can pull that again. If you > have unrelated changes, then I'd prefer them to be on top of an -rc > release for the next pull request. Ok. Sounds like there might be some use for a temporary "work in progress" branch for linux-next for patches that are nearly ready to go but not quite that needs air time, but not really for anything beyond that. None of the ones in this case apply to this scenario so I'll resend a fresh pull request based on -rc3 as soon as the branch rebase has propagated out from master.kernel.org. -Olof
On Thu, Aug 25, 2011 at 10:23:21PM -0700, Olof Johansson wrote: > Ok. Sounds like there might be some use for a temporary "work in > progress" branch for linux-next for patches that are nearly ready to > go but not quite that needs air time, but not really for anything > beyond that. Bad idea. linux-next's policy is that everything in linux-next should be ready for mainline - not nearly ready. Linus is threatening at the next merge window to ignore pull requests from maintainers, and just pull the entire linux-next tree into his at the beginning. Anything in linux-next which is "work in progress" will therefore find its way immediately into mainline in whatever state it's in. So, everyone needs to ensure that linux-next only contains code that's 100% ready for merging during the next merge window. Everything else should not be in linux-next.
On Fri, Aug 26, 2011 at 09:32:52AM +0100, Russell King - ARM Linux wrote: > On Thu, Aug 25, 2011 at 10:23:21PM -0700, Olof Johansson wrote: > > Ok. Sounds like there might be some use for a temporary "work in > > progress" branch for linux-next for patches that are nearly ready to > > go but not quite that needs air time, but not really for anything > > beyond that. > > Bad idea. > > linux-next's policy is that everything in linux-next should be ready > for mainline - not nearly ready. > > Linus is threatening at the next merge window to ignore pull requests > from maintainers, and just pull the entire linux-next tree into his at > the beginning. Anything in linux-next which is "work in progress" will > therefore find its way immediately into mainline in whatever state it's > in. Are you referring to: > In fact, I'm seriously considering a rather draconian measure for next > merge window: I'll fetch the -next tree when I open the merge window, > and if I get anything but trivial fixes that don't show up in that "next > tree at the point of merge window open", I'll just ignore that pull > request. Because clearly people are just not being careful enough. I understood that he wants to check if the contents of a pull request are already in -next and otherwise just refuses to pull. SO nothing changes, except that you have to make sure your patches are in -next before the merge window opens. There may be something else on the lists I missed... Sascha
Hi Arnd, Please pull the first set of tegra/board patches for 3.2: The following changes since commit e6a99d312687a42c077a9b8cb5e757f186edb1b9: Merge branch 'slab/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/penberg/slab-2.6 (2011-08-09 08:42:16 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/olof/tegra.git boards-for-3.2 Marc Dietrich (5): ARM: tegra: paz00: add support serial port on JP1 ARM: tegra: paz00: enable rfkill for internal wifi card ARM: tegra: paz00: enable wifi led ARM: tegra: paz00: reorder the SDHCI channel init ARM: tegra: paz00: add clocks required for usb operation Stephen Warren (4): ARM: Tegra: Harmony: Add USB device ARM: Tegra: Seaboard board updates for audio ARM: Tegra: Seaboard: Add USB devices ARM: Tegra: Force PORT_TEGRA as the UART type arch/arm/mach-tegra/board-harmony.c | 5 +- arch/arm/mach-tegra/board-paz00-pinmux.c | 3 + arch/arm/mach-tegra/board-paz00.c | 62 ++++++++++++++++++++- arch/arm/mach-tegra/board-paz00.h | 16 ++++- arch/arm/mach-tegra/board-seaboard-pinmux.c | 6 +- arch/arm/mach-tegra/board-seaboard.c | 81 ++++++++++++++++++++++++++- arch/arm/mach-tegra/board-seaboard.h | 12 +++- arch/arm/mach-tegra/board-trimslice.c | 3 +- 8 files changed, 173 insertions(+), 15 deletions(-)