Michel Dänzer is invited to help maintain master X server branch

Eric Anholt eric at anholt.net
Thu Aug 18 20:02:38 UTC 2016

Keith Packard <keithp at keithp.com> writes:

> Michel Dänzer <michel at daenzer.net> writes:
>> Many glamor changes have been pushed by Adam or Keith lately. Is that
>> intentional, i.e. is it okay for others to push glamor changes which are
>> ready, or should we always get in touch with Eric first?
> Would saying "it depends" help at all? When there's a major chunk of
> code getting ready to be merged, then coordinating through a single
> person can avoid merge conflicts. In quiet times, then working
> separately will reduce communication overhead.
> So, I think the key is to know when things are busy and when things are
> quiet, and to have a sense of how much conflict any particular patch is
> likely to cause with other changes in process. It's probably not a great
> idea to merge a whitespace patch touching every file in the repo just
> before someone merges a pile of changes to a single file.
> When in doubt, feel free to just ask around. If several of us agree that
> merging a patch seems fine, then at least it's not entirely your fault?

I'm generally in favor of people pushing reviewed patches to glamor.
The only thing I'll get grumpy about is new code without coverage in XTS
or rendercheck.  X rendering is hard to get right, so make sure that
there's a test covering it.

However, the manual operation of our testsuites is also awful (which
subsets am I supposed to actually run?  How do I know if I succeeded,
when there are expected failures?).  Having spent a while recently
working in a project with actual CI, I'll try not to be too irritated
about others not doing testing on X when I haven't actually made X's
rendering testing usable.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <https://lists.x.org/archives/xorg-devel/attachments/20160818/45ab617e/attachment.sig>

More information about the xorg-devel mailing list