On Sat, 2011-06-04 at 23:05 -0700, Keith Packard wrote:
> I'm trying to formalize the process for merging code into the drm/i915
> driver. Here's a first draft, please send along your comments.
Okay so you made the same mistake a lot of people make, the merge window
for -next from me to Linus is from when he releases a .x release.
However the merge window for you to me, should happen before this,
multiple -next merges are allowed before Linus releases a kernel, though
I'd really like to close the door around -rc6 in general. Generally I've
found though with graphics we are crunch time for late found regression
around rc6 time so I rarely push back too hard as I'd rather the kernel
release with no regressions than worry overly about -next.
So when Linus is releasing rc4/5 you should really be cutting down stuff
going into your -next, and getting the tree ready for me to take. We can
probably add your tree direct to the -next git list as well so that we
can get the benefits of -next testing earlier.
Some misc stuff inline:
<snip>
> The part I'm less sure about is how to deal with patches that
> affect both drm/i915 and drm itself. In that case, we may have
> patches on both drm-intel-fixes and drm-fixes which work
> together to resolve an issue. I think the right thing will be to
> have drm-intel-fixes get merged into drm and from there be
> merged into master. That's what I've done with a set of fixes
> posted after 3.0-RC1.
Yes if you have any interdepends then you need to coordinate with me,
hopefully outside of -next we don't have that sort of work happening, as
generally individual drm patches should be in my tree anyways.
> I'm interested in hearing comments about whether this will cause
> too many additional issues with merges from other parts of the
> kernel, or whether we'll end up far behind other trees somehow.
Linus rule is to avoid misc merges, however if you are only getting fast
forwards then it seems like it should be fine as we are getting people
testing from a better base.
>
> drm-intel-next
>
> While the merge window is closed, this tree will be accumulating
> patches in preparation for the subsequent merge window. However,
> to reduce the divergence from drm-intel-fixes, I'm proposing
> that drm-intel-fixes get merged to drm-intel-next whenever it is
> merged to master. I fully expect this to cause merge conflicts,
> but resolving those within our own tree before they are sent
> upstream should reduce the conflicts at that level. As
> drm-intel-fixes is periodically fast-forwarded to points along
> master, those merges will get pulled across to drm-intel-next.
>
> At the opening of the merge window, drm-intel-next should
> contain all of drm-intel-fixes from the release, and most of the
> rest of the release as well.
Just make sure any merge commits are documented in the commit, this
generally means having to git commit --amend the merge commit since most
of the time it doesn't allow you to write anything unless you get a
conflict, esp if its a strange non i915 commit (like say some ACPI or
bluetooth commit that fixes a test laptop).
Otherwise sounds good.
Dave.
On Sat, 04 Jun 2011 23:05:23 -0700
"Keith Packard" <[email protected]> wrote:
> 1) drm-intel-next
>
> This contains work destined for the 'next' release, it may include
> new functionality and performance enhancements. It may also cause
> regressions on some hardware. The tip of this tree will be sent
> to Dave Airlie for inclusion in the kernel during the next
> merge window. I've already sent all of what is on this branch
> to him for 3.0
>
> This tree should be tested during the development process to try and
> catch bugs and regressions before they are merged. The most critical
> time for testing this is just *before* the release of the current RC
> kernel version as that is when it should have most of the code
> planned for the *next* release.
>
> 2) drm-intel-fixes
>
> This contains bug fixes after the merge window has closed. I will
> fast-forwarded to each RC when possible so that we test the fully
> integrated kernel for regressions.
>
> This tree should be tested during the stabilization process after RC1
> comes out as patches are applied.
Can you keep drm-intel-next fairly up to date with respect to the fixes
branch? I.e. keep it a superset of drm-intel-fixes for the most part?
In PCI-land, this means re-basing my -next tree periodically before the
merge window opens (though not right before the merge window unless
something unexpected happens, like a patch needing to be dropped; in
that case I'll delay the merge window push a bit to allow for more
testing).
Downstream PCI developers requested this since it makes feature
development much easier (you get all the bug fixes destined for Linus
while working on a new feature for the next window), and as a
downstream gfx developer I'd like to see this on the Intel side as
well, unless other developers have big objections...
Thanks,
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, 06 Jun 2011 16:24:46 -0700
Keith Packard <[email protected]> wrote:
> On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes <[email protected]> wrote:
>
> > Can you keep drm-intel-next fairly up to date with respect to the fixes
> > branch? I.e. keep it a superset of drm-intel-fixes for the most part?
>
> Yes, I wanted to do that now, but -fixes is not a fast-forward from
> -next and I thought I shouldn't be doing rebases.
You shouldn't if your downstream is using git trees and you're pulling
from them, but it depends on your downstream. In my particular case,
I'm ok with rebases if it means I get fixes. :)
--
Jesse Barnes, Intel Open Source Technology Center
On Mon, 6 Jun 2011 16:30:25 -0700
Jesse Barnes <[email protected]> wrote:
> On Mon, 06 Jun 2011 16:24:46 -0700
> Keith Packard <[email protected]> wrote:
>
> > On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes <[email protected]> wrote:
> >
> > > Can you keep drm-intel-next fairly up to date with respect to the fixes
> > > branch? I.e. keep it a superset of drm-intel-fixes for the most part?
> >
> > Yes, I wanted to do that now, but -fixes is not a fast-forward from
> > -next and I thought I shouldn't be doing rebases.
>
> You shouldn't if your downstream is using git trees and you're pulling
> from them, but it depends on your downstream. In my particular case,
> I'm ok with rebases if it means I get fixes. :)
Oh and the other big reason is testing. rebase generally voids
previous testing since you have new bits, so Linus really hates to see
a rebase just before a pull request, and I think Dave does too.
But rebasing for good reason (e.g. to make your -next branch a superset
of your -fixes branch) on occasion is fine.
--
Jesse Barnes, Intel Open Source Technology Center