No subject

and would probably be even detrimental to testing.

Right now, the drivers that matter build against several X server versions
and I get testing of e.g. evdev master against older servers, finding
evdev-specific bugs during the development cycle. This is mostly due to the
input drivers being much simpler and easier to install than video drivers,
they have virtually no dependencies.
The work needed to support multiple server versions is mostly negligible.
To get the same exposure of testing once the drivers are merged into master
requires a lot of cherry-picking on my behalf.
Even then, we'd still need users to install the server + dependencies to test
a new evdev patch, something which at this point would likely be a
deterrent.
So at this point, merging drivers in would increase my workload and reduce
testing exposure.  That's why I'm reluctant for evdev and synaptics to be
merged, even though the "no API/ABI" is tempting. The drivers just don't
move enough to make it worthwhile just yet. We'll see how Benjamin's
multitouch efforts will affect that.

> Beyond that, one requirement that I see for merging output drivers would
> be to shorten the X server release from the current 6 months down to 3
> months or so. Otherwise I feel that the window of time between hardware
> release and driver release could become too long. I'm up for this
> cadence, but it would mean that we'd need to see major patches posted
> and reviewed in the previous release cycle so that they could be applied
> shortly after a release. I don't want to shorten the RC schedule by
> much. If ABI/API churn is an issue, we could try freezing those for the
> 'odd' releases, but I'd rather avoid that as it can artificially
> constrain development.
> 
> For 1.9, I'd like to shorten the schedule a bit, if that works for other
> people. It seems like releasing around mid-late August would better
> align with the Beta schedules for Fedora, Ubuntu and MeeGo. If that
> seems reasonable to most people, I'd like to propose the following
> schedule:
> 
> Merge window closes:        2010-6-1
> Non-critical bug deadline:  2010-8-1
> Release:                    2010-8-20
> 
> I don't think there are any major changes planned for this release, so
> this shorter merge window seems like it should be sufficient. Nor do I
> necessarily think that this would also mean that the X.org release date
> should be moved in; having the X server ready *before* the X.org release
> seems like a good idea to me. I'll be doing periodic release candidates
> starting with the close of the merge window.
> 
> This schedule would mean that anyone with changes they've been working
> on should get them posted now. Independent of the 1.9 release schedule,
> I'd like to encourage people to post patches as soon as possible anyway;
> there's no reason to wait until the feature merge window is open to get
> code reviewed, the merge window is supposed to be about getting changes
> lined up for the server release.
> 
> Finally, some notes about what our current process is, just to remind
> everyone of what I think the rules are:
> 
>  1) Post all proposed patches to xorg-devel at lists.x.org. All patches
>     must have Signed-off-By: lines attached. I think every patch
>     should be posted and not just a link to a git repository. I do
>     patch review off-line, having things in my inbox makes that really
>     easy.
> 
>  2) Review as many patches as you can stand. Even if you don't know the
>     area that the code touches, please feel free to post comments about
>     style, grammar and the patch description. A 'Reviewed-by:' line
>     doesn't have to say 'I know this code will work', only that you
>     think that the patch is ready for merging.
> 
>  3) Test patches that change stuff you care about. If there's a piece of
>     code that touches something that you know about or use regularly,
>     please give it a try and see what it does. If things appear to work
>     as advertised, please reply with a 'Tested-by:' line.
> 
>  4) Ack patches that you think are necessary. An 'Acked-by:' line should
>     signify that the patch purports to do something that you think is
>     necessary or useful, but that you haven't reviewed in depth or
>     tested it. I'd like to encourage people who see an Acked-by line to
>     consider reviewing and testing the associated patch; all things
>     being equal, patches that lots of people want should probably be
>     higher priority than other patches.
> 
>  4) Patches that are both ready for merging and which conform to the
>     release schedule policy should get updated with all Reviewed-by:,
>     Acked-by:, Tested-by: and Signed-off-by: lines inserted and then
>     sent back to xorg-devel at lists.x.org and Cc:'d to the release manager
>     (that's me for 1.9). You can either send them as patches to the
>     list, or as pull requests. Patches should contain the word 'PATCH'
>     in the subject while pull requests should contain the word 'PULL'.
> 
> Here's some Do's and Don't's:
> 
>  1) Do post patches as soon as you think they're ready for review. They
>     do not have to be 'finished'. The earlier you post big changes, the
>     sooner we can get agreement on how such things should be done. Send
>     them as patches, not pull requests so that we can see the code
>     without needing to pull from your git repository.
> 
>  2) Do not Cc: the release manager with patches that have not been
>     posted to the list before, or patches which haven't seen
>     sufficient review.

except those patches where you are the most likely person to review
them? I seem to have a few of them, mostly code that's old enough to drive,
if not drink.

We also had some overlap where I picked up patches at the same time as you
did, causing some overlap. I think that's better now but we still don't
really have a strict divide. More tree maintainers to snap up patches would
be handy here.

Cheers,
  Peter

>  3) Review, test and acknowledge patches early and often. The more
>     people we get looking at the code, the better things go.
> 
>  4) Review all aspects of a patch, from the coding style to the grammar
>     in the comments. Be constructive and remember that many (most?) of
>     the people in our development community are not native English
>     users.