Pending patch queue

[Kristian Høgsberg]

Hi all,

I'm getting to a point where I can't keep track of which patches and
series are out there pending review/commit/etc.  Two weeks of holiday
and then catching up on email and various paper work pushed me over
the edge.  I used to have a list locally of patches I needed to get
back to, but it's no longer very complete or up-to-date.

So instead of maintaining this list myself, I'd like to make it more
of a collaborative effort, where patch authors can help me keep it
up-to-date.  The list will make my workflow a little more transparent,
and let authors know what's "on my radar" and whether I'm waiting for
a resend or if I need to review/commit.

It's a lot like http://patchwork.freedesktop.org, but by doing it by
email it's much more visible on list, a little more free-form and
easier to participate in.

How does it work:

 - I'll try to send out the list once a week

 - Each patch or patch series is added to the patch list as it hits
   the mailing list.

 - No patch is too small to be on the list.  But many small fixes
   won't make the list because I receive and commit them before
   sending out the next list.

 - When a patch is committed, we take it off the list.  I will reply
   to the patch to acknowledge.

 - If a patch or series is rejected or abandoned, we take it off the
   list.  Resend the series to get back on the lits.

 - If a patch wasn't committed or dropped, I probably forgot about,
   remind me by replying to the patch queue mail (including this one).

So without further ado, here's the list I have now:

* Subsurface (Pekka Paalanen)

  - Still work-in-progress.  There are a few corner cases around
    commit behavior and clipping that we need to get consensus on.
    Also, I think we need to allow recursive sub-surfaces.


* xwm series (Tiago Vignatti)

  - Looking at the reasons we would do this, we're down to just doing
    this for the increased robustness of running xwm in a separate
    process.  This comes with the added complexiy of having a new
    interface and even more synchronization hassle between the three
    processes, so it's not a clear win.

  - The series also introduces the feature of keeping toplevel X
    window positions in sync with wayland position and letting X place
    popups.  This makes sense and is what makes X clients work much
    better under weston, but is orthogonal to splitting xwm into a
    separate process.

  - Reflecting wayland surface position into X has to be synchronized
    with mapping the window, so that clients receive the configure
    event with the initial position before the map-notify event.


* /dev/fb backend (Philip Withnall)

  - If doing this for nouveau, why not use kms and get reliable page
    flipping?  Regardless, a /dev/fb backend is useful for cases where
    we don't have KMS.

  - Should use shadow fb as David suggests.


* language binding patches (Jason Ekstrand)

  - v2 looks good

  - Hoping someone will do a node.js binding :)


* weston.ini man page (Martin Minarik)

  - Awaiting a resend with the changes suggested by Scott and Pekka.


* surface_data and surface panel list (Scott Moreau)

  - This one was in good shape at the last resend, but I think there
    was a few more issues we still we discussion.  I forget (sorry).


* resize from center (Scott Moreau)

  - I think we got stuck discussion how to trigger resize-from-center.
    I think we can just handle it in the compositor, by remembering
    the initial center (pre-resize) and then center the window there
    if shift is pressed during resize, and jump back to normal
    resizing if shift is released.


* Gamma correct compositing patches (John Kåre Alsaker)

  - Would like to break this into two or three series: first series to
    do the dynamic shader creation using GLSL #ifdef and including a
    generated "#define YUV_SHADER" snippet first to determine which
    combination to compile.  Then the indirect rendering series and
    then the color correct compositing patches.

Kristian