Re: How exactly is the Xorg MIT-COOKIE being sent by the application to the server - does Xlib do that?
On 10/30/18 08:30 PM, Veek M wrote: You can setup Xorg to listen only on a UNIX DOMAIN socket: *Xorg -nolisten tcp -nolisten inet -nolisten inet6 -listen unix -nolisten local :0 -seat seat0 vt7 -novtswitch&* The Xorg process must receive a COOKIE on this /tmp/X11/X0 and @/tmp/X11/X0 device, that matches its cookie - it then creates an internal CONTEXT that is associated with the cookie-senders IP:PORT IF this were a socket (TCP etc) since we've disabled TCP, the pipe is used but how does Xorg validate connections on that one pipe? Does it use/generate a different token (similar to what FTP does - one port to negotiate and another for xfer) or is the cookie passed in for every API call the Xlib/Client makes AFTER XOpenWIndow()? Just like a TCP socket, every time an application connects to a Unix domain socket or named pipe, it causes a new file descriptor to be created in the X server. In the connection setup on that file descriptor the client would send the cookie if required, and the X server then marks that file descriptor as authenticated. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[PATCH app/fonttosfnt] Mark vsprintf_alloc as printf-like function
Signed-off-by: Peter Hutterer
---
Review this quickly please, we have another release coming up in 9 years
time and I don't want to miss the merge window.
util.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/util.c b/util.c
index 81c0489..5a23eeb 100644
--- a/util.c
+++ b/util.c
@@ -37,6 +37,7 @@ THE SOFTWARE.
#include FT_FREETYPE_H
#include FT_BDF_H
#include "X11/Xos.h"
+#include "X11/Xfuncproto.h" /* for _X_ATTRIBUTE_PRINTF */
#include "fonttosfnt.h"
#ifdef NEED_SNPRINTF
@@ -80,6 +81,7 @@ sprintf_alloc(const char *f, ...)
}
#if HAVE_VASPRINTF
+_X_ATTRIBUTE_PRINTF(1, 0)
char*
vsprintf_alloc(const char *f, va_list args)
{
@@ -92,6 +94,7 @@ vsprintf_alloc(const char *f, va_list args)
return r;
}
#else
+_X_ATTRIBUTE_PRINTF(1, 0)
char*
vsprintf_alloc(const char *f, va_list args)
{
--
2.19.1
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: How exactly is the Xorg MIT-COOKIE being sent by the application to the server - does Xlib do that?
You can setup Xorg to listen only on a UNIX DOMAIN socket: *Xorg -nolisten tcp -nolisten inet -nolisten inet6 -listen unix -nolisten local :0 -seat seat0 vt7 -novtswitch&* The Xorg process must receive a COOKIE on this /tmp/X11/X0 and @/tmp/X11/X0 device, that matches its cookie - it then creates an internal CONTEXT that is associated with the cookie-senders IP:PORT IF this were a socket (TCP etc) since we've disabled TCP, the pipe is used but how does Xorg validate connections on that one pipe? Does it use/generate a different token (similar to what FTP does - one port to negotiate and another for xfer) or is the cookie passed in for every API call the Xlib/Client makes AFTER XOpenWIndow()? (I read those docs but I'm not an expert on Xorg and its API and it has over 10 O'Reilly manuals so..) ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[PATCH xserver] dix: do not send focus event when grab actually does not change
c67f2eac5651 ("dix: always send focus event on grab change") made dix
always sent events when it's a NotifyGrab or NotifyUngrab, even if
from == to, because 'from' can just come from a previous XSetInputFocus
call.
However, when an application calls XGrabKeyboard several times on
the same window, we are now sending spurious FocusOut+FocusIn with
NotifyGrab, even if the grab does not actually change. This makes screen
readers for blind people spuriously emit activity events which disturb
screen reading workflow when e.g. switching between menus.
This commit avoids calling DoFocusEvents in that precise case, i.e. when
oldWin is a previous grab and the new grab is the same window.
Signed-off-by: Samuel Thibault
Index: xorg-server-1.19.2/dix/events.c
===
--- xorg-server-1.19.2.orig/dix/events.c
+++ xorg-server-1.19.2/dix/events.c
@@ -1530,7 +1530,9 @@ ActivatePointerGrab(DeviceIntPtr mouse,
mouse->spriteInfo->sprite->hotPhys.y = 0;
ConfineCursorToWindow(mouse, grab->confineTo, FALSE, TRUE);
}
-DoEnterLeaveEvents(mouse, mouse->id, oldWin, grab->window, NotifyGrab);
+if (! (grabinfo->grab && oldWin == grabinfo->grab->window
+ && oldWin == grab->window))
+DoEnterLeaveEvents(mouse, mouse->id, oldWin, grab->window, NotifyGrab);
mouse->valuator->motionHintWindow = NullWindow;
if (syncEvents.playingEvents)
grabinfo->grabTime = syncEvents.time;
@@ -1640,7 +1642,9 @@ ActivateKeyboardGrab(DeviceIntPtr keybd,
oldWin = keybd->focus->win;
if (keybd->valuator)
keybd->valuator->motionHintWindow = NullWindow;
-if (oldWin)
+if (oldWin &&
+ ! (grabinfo->grab && oldWin == grabinfo->grab->window
+ && oldWin == grab->window))
DoFocusEvents(keybd, oldWin, grab->window, NotifyGrab);
if (syncEvents.playingEvents)
grabinfo->grabTime = syncEvents.time;
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[Bug 108600] Regression: Segfault on video playback with XScale
https://bugs.freedesktop.org/show_bug.cgi?id=108600 --- Comment #4 from Michel Dänzer --- Please make sure debugging symbols are available for /usr/lib/xorg/modules/drivers/amdgpu_drv.so and /usr/lib/Xorg, reproduce the crash again and attach the full corresponding Xorg log file. -- You are receiving this mail because: You are the assignee for the bug.___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org https://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: XRender / XComposite Documentation
On 10/30/18 08:34 AM, Dennis Clarke wrote: I don't think your average user will ever find that. Best to go to the actual release site : https://www.x.org/releases/X11R7.7/doc/libXrender/libXrender.txt But that's 6 years old now, since we stopped doing X11R7.* releases. Ajax's links are the most up-to-date for people today. I agree ... but who will ever find those ? Stick them on the main site if they are up to date. Agreed, but not yet implemented: https://gitlab.freedesktop.org/xorg/meta/issues/3 -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: XRender / XComposite Documentation
I don't think your average user will ever find that. Best to go to the actual release site : https://www.x.org/releases/X11R7.7/doc/libXrender/libXrender.txt But that's 6 years old now, since we stopped doing X11R7.* releases. Ajax's links are the most up-to-date for people today. I agree ... but who will ever find those ? Stick them on the main site if they are up to date. dc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: XRender / XComposite Documentation
On 10/30/18 07:58 AM, Dennis Clarke wrote: On 10/30/2018 10:35 AM, Adam Jackson wrote: On Tue, 2018-10-30 at 02:06 -0700, x...@pengaru.com wrote: On Mon, Oct 29, 2018 at 04:04:08PM -0400, Patrick Herbst wrote: Hello, I'm desperately trying to find documentation on these extensions. Can someone point me in the right direction? Am I missing something? Any pointers? https://www.x.org/archive/X11R7.5/doc/libXrender/libXrender.txt https://www.x.org/archive/X11R7.5/doc/renderproto/renderproto.txt https://www.x.org/archive/X11R7.5/doc/compositeproto/compositeproto.txt Those are a bit dated. The current versions can be found in gitlab: https://gitlab.freedesktop.org/xorg/lib/libxrender/blob/master/doc/libXrender.txt https://gitlab.freedesktop.org/xorg/proto/xorgproto/blob/master/compositeproto.txt https://gitlab.freedesktop.org/xorg/proto/xorgproto/blob/master/renderprotoproto.txt - ajax I don't think your average user will ever find that. Best to go to the actual release site : https://www.x.org/releases/X11R7.7/doc/libXrender/libXrender.txt But that's 6 years old now, since we stopped doing X11R7.* releases. Ajax's links are the most up-to-date for people today. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - https://blogs.oracle.com/alanc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[Bug 108600] Regression: Segfault on video playback with XScale
https://bugs.freedesktop.org/show_bug.cgi?id=108600 Michel Dänzer changed: What|Removed |Added Attachment #142276|text/x-log |text/plain mime type|| -- You are receiving this mail because: You are the assignee for the bug.___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org https://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: XRender / XComposite Documentation
On 10/30/2018 10:35 AM, Adam Jackson wrote: On Tue, 2018-10-30 at 02:06 -0700, x...@pengaru.com wrote: On Mon, Oct 29, 2018 at 04:04:08PM -0400, Patrick Herbst wrote: Hello, I'm desperately trying to find documentation on these extensions. Can someone point me in the right direction? Am I missing something? Any pointers? https://www.x.org/archive/X11R7.5/doc/libXrender/libXrender.txt https://www.x.org/archive/X11R7.5/doc/renderproto/renderproto.txt https://www.x.org/archive/X11R7.5/doc/compositeproto/compositeproto.txt Those are a bit dated. The current versions can be found in gitlab: https://gitlab.freedesktop.org/xorg/lib/libxrender/blob/master/doc/libXrender.txt https://gitlab.freedesktop.org/xorg/proto/xorgproto/blob/master/compositeproto.txt https://gitlab.freedesktop.org/xorg/proto/xorgproto/blob/master/renderprotoproto.txt - ajax I don't think your average user will ever find that. Best to go to the actual release site : https://www.x.org/releases/X11R7.7/doc/libXrender/libXrender.txt dc ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: XRender / XComposite Documentation
On Tue, 2018-10-30 at 02:06 -0700, x...@pengaru.com wrote: > On Mon, Oct 29, 2018 at 04:04:08PM -0400, Patrick Herbst wrote: > > Hello, > > > > I'm desperately trying to find documentation on these extensions. Can > > someone point me in the right direction? Am I missing something? Any > > pointers? > > > > https://www.x.org/archive/X11R7.5/doc/libXrender/libXrender.txt > https://www.x.org/archive/X11R7.5/doc/renderproto/renderproto.txt > https://www.x.org/archive/X11R7.5/doc/compositeproto/compositeproto.txt Those are a bit dated. The current versions can be found in gitlab: https://gitlab.freedesktop.org/xorg/lib/libxrender/blob/master/doc/libXrender.txt https://gitlab.freedesktop.org/xorg/proto/xorgproto/blob/master/compositeproto.txt https://gitlab.freedesktop.org/xorg/proto/xorgproto/blob/master/renderprotoproto.txt - ajax ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
[Bug 108600] Regression: Segfault on video playback with XScale
https://bugs.freedesktop.org/show_bug.cgi?id=108600 --- Comment #3 from Matthew Scheirer --- Versions: Arch, Xorg-server 1.20.3, kernel 4.18.16. Like I said, no segfaults on 18.0, 18.1+ segfaults in every video player I can find (HW accelerated or not - happens in Firefox, VLC, MPV). Doesn't seem to crash without playing video - I've had a desktop last several hours actively avoiding any video playback. -- You are receiving this mail because: You are the assignee for the bug.___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org https://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 108600] Regression: Segfault on video playback with XScale
https://bugs.freedesktop.org/show_bug.cgi?id=108600 --- Comment #2 from Matthew Scheirer --- Ugh, wiped the summary box while submitting this, so heres the summary: Found a regression in 18.1 from 18.0. I use xscale for multi monitor DPI handling and video playback under 18.1 with scaling enabled crashes the server regularly. Doesn't happen in 18.0, does still happen on trunk. Doesn't happen without scaling enabled. -- You are receiving this mail because: You are the assignee for the bug.___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org https://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 108600] Regression: Segfault on video playback with XScale
https://bugs.freedesktop.org/show_bug.cgi?id=108600 --- Comment #1 from Matthew Scheirer --- Created attachment 142276 --> https://bugs.freedesktop.org/attachment.cgi?id=142276=edit Xorg Segfault Error -- You are receiving this mail because: You are the assignee for the bug.___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org https://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 108600] New: Regression: Segfault on video playback with XScale
https://bugs.freedesktop.org/show_bug.cgi?id=108600 Bug ID: 108600 Summary: Regression: Segfault on video playback with XScale Product: xorg Version: git Hardware: Other OS: All Status: NEW Severity: normal Priority: medium Component: Driver/AMDgpu Assignee: xorg-driver-ati@lists.x.org Reporter: matt.schei...@gmail.com QA Contact: xorg-t...@lists.x.org Created attachment 142275 --> https://bugs.freedesktop.org/attachment.cgi?id=142275=edit Xrandr output -- You are receiving this mail because: You are the assignee for the bug.___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org https://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: XRender / XComposite Documentation
On Mon, Oct 29, 2018 at 04:04:08PM -0400, Patrick Herbst wrote: > Hello, > > I'm desperately trying to find documentation on these extensions. Can > someone point me in the right direction? Am I missing something? Any > pointers? > https://www.x.org/archive/X11R7.5/doc/libXrender/libXrender.txt https://www.x.org/archive/X11R7.5/doc/renderproto/renderproto.txt https://www.x.org/archive/X11R7.5/doc/compositeproto/compositeproto.txt The docs also tend to get installed under /usr/share/doc/$packagename On Debian I have: /usr/share/doc/libxrender-dev/libXrender.txt.gz /usr/share/doc/x11proto-render-dev/renderproto.txt.gz /usr/share/doc/x11proto-composite-dev/compositeproto.txt.gz Regards, Vito Caputo ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: [RFC] Allow fd.o to join forces with X.Org
On Mon, Oct 29, 2018 at 01:24:56PM +, Wentland, Harry wrote: > On 2018-10-26 7:22 a.m., Daniel Vetter wrote: > > On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone wrote: > >> > >> Hi, > >> > >> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote: > >>> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote: > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote: > > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone > > wrote: > >> Yeah, I think it makes sense. Some things we do: > >> - provide hosted network services for collaborative development, > >> testing, and discussion, of open-source projects > >> - administer, improve, and extend this suite of services as necessary > >> - assist open-source projects in their use of these services > >> - purchase, lease, or subscribe to, computing and networking > >> infrastructure allowing these services to be run > > > > I fully agree that we should document all this. I don't think the > > bylaws are the right place though, much better to put that into > > policies that the board approves and which can be adapted as needed. > > Imo bylaws should cover the high-level mission and procedural details, > > as our "constitution", with the really high acceptance criteria of > > 2/3rd of all members approving any changes. Some of the early > > discussions tried to spell out a lot of the fd.o policies in bylaw > > changes, but then we realized it's all there already. All the details > > are much better served in policies enacted by the board, like we do > > with everything else. > > > > As an example, let's look at XDC. Definitely one of the biggest things > > the foundation does, with handling finances, travel sponsoring grants, > > papers committee, and acquiring lots of sponsors. None of this is > > spelled out in the bylaws, it's all in policies that the board > > deliberates and approves. I think this same approach will also work > > well for fd.o. > > > > And if members are unhappy with what the board does, they can fix in > > the next election by throwing out the unwanted directors. > > yeah, fair call. though IMO in that case we can just reduce to > > \item Support free and open source projects through the > freedesktop.org > infrastructure. > > because my gripe is less with the fdo bit but more with defining what > "project hosting" means, given that we use that term to exclude fdo > projects > from getting anything else. I think just dropping that bit is sufficient. > >>> > >>> Hm yeah, through the lens of "everything not explicitly listed isn't in > >>> scope as X.org's purpose", leaving this out is probably clearest. And > >>> under 2.4 (i) the board already has the duty to interpret what exactly > >>> this means wrt membership eligibility. > >>> > >>> Harry, Daniel, what do you think? > >> > >> Yeah, that's fine. I didn't specifically want the enumerated list of > >> what we do in the bylaws, just spelling it out for background as a > >> handy reference I could point to later. I think maybe we could reduce > >> it to something like: > >> Administer, support, and improve the freedesktop.org hosting > >> infrastructure to support the projects it hosts > > > > This feels a bit self-referential, not the best for the purpose of > > what X.org does. If we do want to be a bit more specific we could do > > something like with (i) and provide a list that the board can extend: > > > > \item Support free and open source projects through the freedesktop.org > > infrastructure. This includes, but is not limited to: > > Administering and providing > > project hosting services. > > > > I like this phrasing, but won't that bring us back to David Hutterer's > point about defining what "project hosting services" means? > > Personally I think "project hosting" is quite clear and shouldn't need to be > defined. I think it's less tricky, since we no longer use it to exclude services and support. It makes it much more clear that defining the details is all up to the board, with just a rough guideline of what should be included. Peter? -Daniel > > Harry > > > That would make it clear that admins are in scope, and > > everything else is up to the board. Similar to how drm, mesa, wayland > > and X are explicitly in scope, and stuff like cros/android gfx stack > > or libinput is up to the board to decide/clarify. > > > >> Gives us enough scope to grow in the future (e.g. we don't need a > >> bylaws change to move from pure-git to GitLab), avoids the sticky > >> question of what exactly fd.o hosts in the bylaws (e.g. if > >> NetworkManager needs a new repo then we don't have to consult > >> membership to add it), but is still pretty firmly limited in scope. > >> > >> Any of the above have my in-principle ack though, I think they're all > >> reasonable
XRender / XComposite Documentation
Hello, I'm desperately trying to find documentation on these extensions. Can someone point me in the right direction? Am I missing something? Any pointers? Thanks! ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: [RFC] Allow fd.o to join forces with X.Org
On 2018-10-26 7:22 a.m., Daniel Vetter wrote: > On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone wrote: >> >> Hi, >> >> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote: >>> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote: On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote: > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote: >> Yeah, I think it makes sense. Some things we do: >> - provide hosted network services for collaborative development, >> testing, and discussion, of open-source projects >> - administer, improve, and extend this suite of services as necessary >> - assist open-source projects in their use of these services >> - purchase, lease, or subscribe to, computing and networking >> infrastructure allowing these services to be run > > I fully agree that we should document all this. I don't think the > bylaws are the right place though, much better to put that into > policies that the board approves and which can be adapted as needed. > Imo bylaws should cover the high-level mission and procedural details, > as our "constitution", with the really high acceptance criteria of > 2/3rd of all members approving any changes. Some of the early > discussions tried to spell out a lot of the fd.o policies in bylaw > changes, but then we realized it's all there already. All the details > are much better served in policies enacted by the board, like we do > with everything else. > > As an example, let's look at XDC. Definitely one of the biggest things > the foundation does, with handling finances, travel sponsoring grants, > papers committee, and acquiring lots of sponsors. None of this is > spelled out in the bylaws, it's all in policies that the board > deliberates and approves. I think this same approach will also work > well for fd.o. > > And if members are unhappy with what the board does, they can fix in > the next election by throwing out the unwanted directors. yeah, fair call. though IMO in that case we can just reduce to \item Support free and open source projects through the freedesktop.org infrastructure. because my gripe is less with the fdo bit but more with defining what "project hosting" means, given that we use that term to exclude fdo projects from getting anything else. I think just dropping that bit is sufficient. >>> >>> Hm yeah, through the lens of "everything not explicitly listed isn't in >>> scope as X.org's purpose", leaving this out is probably clearest. And >>> under 2.4 (i) the board already has the duty to interpret what exactly >>> this means wrt membership eligibility. >>> >>> Harry, Daniel, what do you think? >> >> Yeah, that's fine. I didn't specifically want the enumerated list of >> what we do in the bylaws, just spelling it out for background as a >> handy reference I could point to later. I think maybe we could reduce >> it to something like: >> Administer, support, and improve the freedesktop.org hosting >> infrastructure to support the projects it hosts > > This feels a bit self-referential, not the best for the purpose of > what X.org does. If we do want to be a bit more specific we could do > something like with (i) and provide a list that the board can extend: > > \item Support free and open source projects through the freedesktop.org > infrastructure. This includes, but is not limited to: > Administering and providing > project hosting services. > I like this phrasing, but won't that bring us back to David Hutterer's point about defining what "project hosting services" means? Personally I think "project hosting" is quite clear and shouldn't need to be defined. Harry > That would make it clear that admins are in scope, and > everything else is up to the board. Similar to how drm, mesa, wayland > and X are explicitly in scope, and stuff like cros/android gfx stack > or libinput is up to the board to decide/clarify. > >> Gives us enough scope to grow in the future (e.g. we don't need a >> bylaws change to move from pure-git to GitLab), avoids the sticky >> question of what exactly fd.o hosts in the bylaws (e.g. if >> NetworkManager needs a new repo then we don't have to consult >> membership to add it), but is still pretty firmly limited in scope. >> >> Any of the above have my in-principle ack though, I think they're all >> reasonable colours for our lovely shed. > > Well, one more bikeshed from me! > > Cheers, Daniel > >> >> Cheers, >> Daniel > > > ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: https://lists.x.org/mailman/listinfo/xorg Your subscription address: %(user_address)s
Re: [RFC] Allow fd.o to join forces with X.Org
On 2018-10-26 7:22 a.m., Daniel Vetter wrote: > On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone wrote: >> >> Hi, >> >> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote: >>> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote: On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote: > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote: >> Yeah, I think it makes sense. Some things we do: >> - provide hosted network services for collaborative development, >> testing, and discussion, of open-source projects >> - administer, improve, and extend this suite of services as necessary >> - assist open-source projects in their use of these services >> - purchase, lease, or subscribe to, computing and networking >> infrastructure allowing these services to be run > > I fully agree that we should document all this. I don't think the > bylaws are the right place though, much better to put that into > policies that the board approves and which can be adapted as needed. > Imo bylaws should cover the high-level mission and procedural details, > as our "constitution", with the really high acceptance criteria of > 2/3rd of all members approving any changes. Some of the early > discussions tried to spell out a lot of the fd.o policies in bylaw > changes, but then we realized it's all there already. All the details > are much better served in policies enacted by the board, like we do > with everything else. > > As an example, let's look at XDC. Definitely one of the biggest things > the foundation does, with handling finances, travel sponsoring grants, > papers committee, and acquiring lots of sponsors. None of this is > spelled out in the bylaws, it's all in policies that the board > deliberates and approves. I think this same approach will also work > well for fd.o. > > And if members are unhappy with what the board does, they can fix in > the next election by throwing out the unwanted directors. yeah, fair call. though IMO in that case we can just reduce to \item Support free and open source projects through the freedesktop.org infrastructure. because my gripe is less with the fdo bit but more with defining what "project hosting" means, given that we use that term to exclude fdo projects from getting anything else. I think just dropping that bit is sufficient. >>> >>> Hm yeah, through the lens of "everything not explicitly listed isn't in >>> scope as X.org's purpose", leaving this out is probably clearest. And >>> under 2.4 (i) the board already has the duty to interpret what exactly >>> this means wrt membership eligibility. >>> >>> Harry, Daniel, what do you think? >> >> Yeah, that's fine. I didn't specifically want the enumerated list of >> what we do in the bylaws, just spelling it out for background as a >> handy reference I could point to later. I think maybe we could reduce >> it to something like: >> Administer, support, and improve the freedesktop.org hosting >> infrastructure to support the projects it hosts > > This feels a bit self-referential, not the best for the purpose of > what X.org does. If we do want to be a bit more specific we could do > something like with (i) and provide a list that the board can extend: > > \item Support free and open source projects through the freedesktop.org > infrastructure. This includes, but is not limited to: > Administering and providing > project hosting services. > I like this phrasing, but won't that bring us back to David Hutterer's point about defining what "project hosting services" means? Personally I think "project hosting" is quite clear and shouldn't need to be defined. Harry > That would make it clear that admins are in scope, and > everything else is up to the board. Similar to how drm, mesa, wayland > and X are explicitly in scope, and stuff like cros/android gfx stack > or libinput is up to the board to decide/clarify. > >> Gives us enough scope to grow in the future (e.g. we don't need a >> bylaws change to move from pure-git to GitLab), avoids the sticky >> question of what exactly fd.o hosts in the bylaws (e.g. if >> NetworkManager needs a new repo then we don't have to consult >> membership to add it), but is still pretty firmly limited in scope. >> >> Any of the above have my in-principle ack though, I think they're all >> reasonable colours for our lovely shed. > > Well, one more bikeshed from me! > > Cheers, Daniel > >> >> Cheers, >> Daniel > > > ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
Re: [RFC] Allow fd.o to join forces with X.Org
On Mon, Oct 29, 2018 at 01:24:56PM +, Wentland, Harry wrote: > On 2018-10-26 7:22 a.m., Daniel Vetter wrote: > > On Fri, Oct 26, 2018 at 1:08 PM Daniel Stone wrote: > >> > >> Hi, > >> > >> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter wrote: > >>> On Fri, Oct 26, 2018 at 10:13:51AM +1000, Peter Hutterer wrote: > On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote: > > On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone > > wrote: > >> Yeah, I think it makes sense. Some things we do: > >> - provide hosted network services for collaborative development, > >> testing, and discussion, of open-source projects > >> - administer, improve, and extend this suite of services as necessary > >> - assist open-source projects in their use of these services > >> - purchase, lease, or subscribe to, computing and networking > >> infrastructure allowing these services to be run > > > > I fully agree that we should document all this. I don't think the > > bylaws are the right place though, much better to put that into > > policies that the board approves and which can be adapted as needed. > > Imo bylaws should cover the high-level mission and procedural details, > > as our "constitution", with the really high acceptance criteria of > > 2/3rd of all members approving any changes. Some of the early > > discussions tried to spell out a lot of the fd.o policies in bylaw > > changes, but then we realized it's all there already. All the details > > are much better served in policies enacted by the board, like we do > > with everything else. > > > > As an example, let's look at XDC. Definitely one of the biggest things > > the foundation does, with handling finances, travel sponsoring grants, > > papers committee, and acquiring lots of sponsors. None of this is > > spelled out in the bylaws, it's all in policies that the board > > deliberates and approves. I think this same approach will also work > > well for fd.o. > > > > And if members are unhappy with what the board does, they can fix in > > the next election by throwing out the unwanted directors. > > yeah, fair call. though IMO in that case we can just reduce to > > \item Support free and open source projects through the > freedesktop.org > infrastructure. > > because my gripe is less with the fdo bit but more with defining what > "project hosting" means, given that we use that term to exclude fdo > projects > from getting anything else. I think just dropping that bit is sufficient. > >>> > >>> Hm yeah, through the lens of "everything not explicitly listed isn't in > >>> scope as X.org's purpose", leaving this out is probably clearest. And > >>> under 2.4 (i) the board already has the duty to interpret what exactly > >>> this means wrt membership eligibility. > >>> > >>> Harry, Daniel, what do you think? > >> > >> Yeah, that's fine. I didn't specifically want the enumerated list of > >> what we do in the bylaws, just spelling it out for background as a > >> handy reference I could point to later. I think maybe we could reduce > >> it to something like: > >> Administer, support, and improve the freedesktop.org hosting > >> infrastructure to support the projects it hosts > > > > This feels a bit self-referential, not the best for the purpose of > > what X.org does. If we do want to be a bit more specific we could do > > something like with (i) and provide a list that the board can extend: > > > > \item Support free and open source projects through the freedesktop.org > > infrastructure. This includes, but is not limited to: > > Administering and providing > > project hosting services. > > > > I like this phrasing, but won't that bring us back to David Hutterer's > point about defining what "project hosting services" means? > > Personally I think "project hosting" is quite clear and shouldn't need to be > defined. I think it's less tricky, since we no longer use it to exclude services and support. It makes it much more clear that defining the details is all up to the board, with just a rough guideline of what should be included. Peter? -Daniel > > Harry > > > That would make it clear that admins are in scope, and > > everything else is up to the board. Similar to how drm, mesa, wayland > > and X are explicitly in scope, and stuff like cros/android gfx stack > > or libinput is up to the board to decide/clarify. > > > >> Gives us enough scope to grow in the future (e.g. we don't need a > >> bylaws change to move from pure-git to GitLab), avoids the sticky > >> question of what exactly fd.o hosts in the bylaws (e.g. if > >> NetworkManager needs a new repo then we don't have to consult > >> membership to add it), but is still pretty firmly limited in scope. > >> > >> Any of the above have my in-principle ack though, I think they're all > >> reasonable
