Intel27 Aug 2013 03:58 am

Over a year ago Daniel Vetter started to maintain the Intel graphics kernel driver, drm/i915. He did an amazing job organizing the whole process. All trees he maintain are explained on his drm/i915 Branches Explained post.

This organization speed up he development process. With the speed came the flood of patches on our intel-gfx mailing list, what is great. The downside of the flood is that sometimes simple patches (1-2 patches) are left behind, not reviewed and even forgotten.

In order to avoid loosing patches we are temporarily/experimentally introducing the drm-intel-collector branch:

http://cgit.freedesktop.org/~vivijim/drm-intel/log/?h=drm-intel-collector

To describe drm-intel-collector I’ll quote Daniel:
“The overall idea is to make sure that simple patches don’t get lost.
Bigger patch series or feature work tends to not get lost, and really
trivial patches I tend to merge right away. But 1-2 patch stuff in
between is occasionally lost”

Process:

1. Daniel pushs drm-intel-testing
2. I rebase drm-intel-collector onto drm-intel-testing
3. I collect all simple (1-2) patches that wasn’t yet reviewed and not queued by Daniel
4. Request automated QA’s PRTS automated i-g-t tests comparing drm-intel-testing x drm-intel-collector
5. If tests are ok I send the patches as a series to intel-gfx mailing list for better tracking and to be reviewed.

There are some reasons that some patches can still be left behind:
1. It was send so long time ago. I started with patches from Jul 26th.
2. Your patch didn’t applied cleanly and I couldn’t easily solve the conflicts.
3. Kernel didn’t compiled with your patch.
4. I simply missed it. If you believe this is the case please warn me.

Yesterday I sent the first series to intel-gfx and Daniel already organized everything volunteering people for review. It seems drm-intel-collector will be useful!

All ideas to improve the process are always very welcome.

Trackback this Post | Feed on comments to this Post

Leave a Reply