* drivers/drm/i915 maintenance process
@ 2011-06-05 6:05 Keith Packard
2011-06-05 6:23 ` Dave Airlie
2011-06-06 20:36 ` Jesse Barnes
0 siblings, 2 replies; 11+ messages in thread
From: Keith Packard @ 2011-06-05 6:05 UTC (permalink / raw)
To: dri-devel; +Cc: drivers, Intel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 8674 bytes --]
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.
-keith
Right now, I'm merging patches destined for the 3.0 release
in a kernel.org tree:
git://git.kernel.org/pub/scm/linux/kernel/git/keithp/linux-2.6.git
(yes, I need to fix the name, I'll send a note when I do).
There are two important branches here (and I'll try to keep clutter down
by pruning dead branches):
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.
If we need another tree or two to test integrated patch sequences for
major rework or new features, we can create other ones, but I hope to
keep it to just these two for ongoing work.
So, here's a typical kernel release cycle with notes on where we should
be focusing our efforts:
2.6.39
The merge window is open and patches are flowing from
drm-intel-next into Dave Airlie's drm-next branch.
Testing should focus on drm-intel-next to ensure that we
let as few bugs as possible leak into the main tree. The
drm-intel-fixes branch should be essentially idle at this time,
although if there are serious bugs in 2.6.39, fixes for those
should be tested on drm-intel-fixes and then sent along to
stable@ for integration in 2.6.39.1. I don't anticipate keeping
a drm-intel-fixes branch open for each stable release.
3.0-RC1
The merge window is closed. New features and major
non-regression bug fixes will continue to land on
drm-intel-next. Minor bug fixes and any regression fixes will
land on drm-intel-fixes. The drm-intel-fixes tree will be sent
directly to Linus for integration into the next RC or final
release.
Regressions on drm-intel-fixes will be dealt with swiftly -- if
new feature or performance work that came from drm-intel-next
cause regressions on any hardware, they must either be fixed or
the new work will be reverted from the kernel. A regression
which malingers through more than one RC is likely to be
subjected to this harsh treatment.
During early RC versions, we should focus our efforts on the
drm-intel-fixes tree to track reported bugs, especially
regressions, to make sure they are fixed as quickly as possible.
However, we cannot afford to ignore the drm-intel-next
branch. If major new code lands on that branch during this time,
we need to schedule testing of that as soon as possible;
otherwise, it will not be ready for the next kernel version.
...
3.0-RCx
As we get close to the next release, there will be an
accumulation of new code in the drm-intel-next branch and we
must ensure that it is ready before the merge window
opens. Plus, as the release gets closer, we must also ensure
that any patches we do make on drm-intel-fixes cause no further
problems. At this point, drm-intel-fixes and drm-intel-next will
be significantly different.
During later RC versions, we must split our attention between
drm-intel-fixes to track issues in the next kernel version and
drm-intel-next to ensure that code merged for the subsequent
kernel are ready. By reducing the volume of patches to
drm-intel-fixes, I hope to make this tractable.
3.0
And the merge window opens, drm-intel-next becomes our primary
focus as that is merged to drm-next and then to master.
I've been working with Dave Airlie to figure out when I can move the
base of the intel driver branches forward along master. Here's what I've
got so far:
drm-intel-fixes
After the merge window closes and no further patches from
drm-intel-next are anticipated, this branch will get pulled
forward to -RC1. There will be nothing on this branch which is
not in -RC1, so it will be a simple fast-forward (or something
is messed up and needs fixing).
Subsequently, when a PULL request is made and has been merged to
master, drm-intel-fixes will get fast-forwarded to that merge
point. If no further patches are pending between the merge point
and the subsequent -RC release, drm-intel-fixes will get fast
forwarded to that -RC.
This includes pulling drm-intel-fixes forward to the final
release in case we end up needing to prepare emergency patches
for the .1 minor release.
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.
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.
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.
During the merge window, patches that have been reviewed and
tested on drm-intel-next will be included in a PULL request to
Dave Airlie for merging into the drm tree.
For patches which involve code in the core drm, we'll have those
changes included in the drm-intel-next tree and they will get
merged to drm-next from there.
Other feature branches
I do not plan to maintain any additional branches for specific
feature work in the drm/i915 tree. Those should be done in
personal repositories, where they can be rebased as necessary
before being merged to the drm/i915 tree.
Of course, there will probably exceptions to this plan. Those should be
clearly marked and suitable comments placed in commit messages.
Patches and commit messages
As I will be reviewing a significant number of patches heading to the
kernel, I will be requiring substantive, complete and correct commit
messages from developers. If the commit message does not include a
detailed description of the problem and the fix, expect to get a request
for more information. Please add any clarification to the commit message
the next time the patch is submitted.
For inclusion in drm-intel-fixes, any patch should have an associated
bug, and the commit message should include a link to the related
bugzilla entry. Fixes for regressions should be marked clearly as
such. During the later RC sequences, patches must be short and address
the bug directly, without any fancy bits.
All patches and pull requests should be sent to the intel-gfx, dri-devel
and linux-kernel mailing lists. Long sequences of patches are best
done with a pull request instead; as review comments come in, the branch
should be rebased so that it contains all of the updates, including
Tested-by, Acked-by and Reviewed-by lines.
Pull requests should be based from the related tree, and branch from a
point close to the current tip. Patches and pulls which don't merge
cleanly should be fixed by the author and re-submitted.
--
keith.packard@intel.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: drivers/drm/i915 maintenance process
2011-06-05 6:05 drivers/drm/i915 maintenance process Keith Packard
@ 2011-06-05 6:23 ` Dave Airlie
2011-06-05 20:16 ` Keith Packard
2011-06-06 20:36 ` Jesse Barnes
1 sibling, 1 reply; 11+ messages in thread
From: Dave Airlie @ 2011-06-05 6:23 UTC (permalink / raw)
To: Keith Packard; +Cc: dri-devel, drivers, Intel, linux-kernel
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.
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: drivers/drm/i915 maintenance process
2011-06-05 6:23 ` Dave Airlie
@ 2011-06-05 20:16 ` Keith Packard
0 siblings, 0 replies; 11+ messages in thread
From: Keith Packard @ 2011-06-05 20:16 UTC (permalink / raw)
To: Dave Airlie; +Cc: dri-devel, drivers, Intel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 897 bytes --]
On Sun, 05 Jun 2011 16:23:43 +1000, Dave Airlie <airlied@redhat.com> wrote:
> 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.
Right, even earlier than I had thought. That should be pretty easy to follow.
> 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).
Thanks for your comments; I'll try to have -next ready by rc4/rc5 time
this release.
--
keith.packard@intel.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: drivers/drm/i915 maintenance process
@ 2011-06-05 20:16 ` Keith Packard
0 siblings, 0 replies; 11+ messages in thread
From: Keith Packard @ 2011-06-05 20:16 UTC (permalink / raw)
To: Dave Airlie; +Cc: dri-devel, drivers, Intel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 897 bytes --]
On Sun, 05 Jun 2011 16:23:43 +1000, Dave Airlie <airlied@redhat.com> wrote:
> 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.
Right, even earlier than I had thought. That should be pretty easy to follow.
> 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).
Thanks for your comments; I'll try to have -next ready by rc4/rc5 time
this release.
--
keith.packard@intel.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: drivers/drm/i915 maintenance process
2011-06-05 6:05 drivers/drm/i915 maintenance process Keith Packard
@ 2011-06-06 20:36 ` Jesse Barnes
2011-06-06 20:36 ` Jesse Barnes
1 sibling, 0 replies; 11+ messages in thread
From: Jesse Barnes @ 2011-06-06 20:36 UTC (permalink / raw)
To: Keith Packard; +Cc: dri-devel, drivers, Intel, linux-kernel
On Sat, 04 Jun 2011 23:05:23 -0700
"Keith Packard" <keithp@keithp.com> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: drivers/drm/i915 maintenance process
@ 2011-06-06 20:36 ` Jesse Barnes
0 siblings, 0 replies; 11+ messages in thread
From: Jesse Barnes @ 2011-06-06 20:36 UTC (permalink / raw)
To: Keith Packard; +Cc: drivers, Intel, linux-kernel, dri-devel
On Sat, 04 Jun 2011 23:05:23 -0700
"Keith Packard" <keithp@keithp.com> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: drivers/drm/i915 maintenance process
2011-06-06 20:36 ` Jesse Barnes
@ 2011-06-06 23:24 ` Keith Packard
-1 siblings, 0 replies; 11+ messages in thread
From: Keith Packard @ 2011-06-06 23:24 UTC (permalink / raw)
To: Jesse Barnes; +Cc: dri-devel, drivers, Intel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]
On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> 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.
> 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).
If a rebase around -RC1 is reasonable, then I'll do that now and move
changes over to that.
--
keith.packard@intel.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: drivers/drm/i915 maintenance process
@ 2011-06-06 23:24 ` Keith Packard
0 siblings, 0 replies; 11+ messages in thread
From: Keith Packard @ 2011-06-06 23:24 UTC (permalink / raw)
To: Jesse Barnes; +Cc: dri-devel, drivers, Intel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 787 bytes --]
On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> 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.
> 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).
If a rebase around -RC1 is reasonable, then I'll do that now and move
changes over to that.
--
keith.packard@intel.com
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: drivers/drm/i915 maintenance process
2011-06-06 23:24 ` Keith Packard
@ 2011-06-06 23:30 ` Jesse Barnes
-1 siblings, 0 replies; 11+ messages in thread
From: Jesse Barnes @ 2011-06-06 23:30 UTC (permalink / raw)
To: Keith Packard; +Cc: dri-devel, drivers, Intel, linux-kernel
On Mon, 06 Jun 2011 16:24:46 -0700
Keith Packard <keithp@keithp.com> wrote:
> On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: drivers/drm/i915 maintenance process
@ 2011-06-06 23:30 ` Jesse Barnes
0 siblings, 0 replies; 11+ messages in thread
From: Jesse Barnes @ 2011-06-06 23:30 UTC (permalink / raw)
To: Keith Packard; +Cc: dri-devel, drivers, Intel, linux-kernel
On Mon, 06 Jun 2011 16:24:46 -0700
Keith Packard <keithp@keithp.com> wrote:
> On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Intel-gfx] drivers/drm/i915 maintenance process
2011-06-06 23:30 ` Jesse Barnes
(?)
@ 2011-06-06 23:43 ` Jesse Barnes
-1 siblings, 0 replies; 11+ messages in thread
From: Jesse Barnes @ 2011-06-06 23:43 UTC (permalink / raw)
To: Keith Packard; +Cc: drivers, Intel, linux-kernel, dri-devel
On Mon, 6 Jun 2011 16:30:25 -0700
Jesse Barnes <jbarnes@virtuousgeek.org> wrote:
> On Mon, 06 Jun 2011 16:24:46 -0700
> Keith Packard <keithp@keithp.com> wrote:
>
> > On Mon, 6 Jun 2011 13:36:18 -0700, Jesse Barnes <jbarnes@virtuousgeek.org> 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
^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2011-06-06 23:50 UTC | newest]
Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-06-05 6:05 drivers/drm/i915 maintenance process Keith Packard
2011-06-05 6:23 ` Dave Airlie
2011-06-05 20:16 ` Keith Packard
2011-06-05 20:16 ` Keith Packard
2011-06-06 20:36 ` Jesse Barnes
2011-06-06 20:36 ` Jesse Barnes
2011-06-06 23:24 ` Keith Packard
2011-06-06 23:24 ` Keith Packard
2011-06-06 23:30 ` Jesse Barnes
2011-06-06 23:30 ` Jesse Barnes
2011-06-06 23:43 ` [Intel-gfx] " Jesse Barnes
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.