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
Re: [RFC] Allow fd.o to join forces with X.Org
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 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. 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 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:
> > >
> > > On Tue, 16 Oct 2018 at 08:17, Peter Hutterer
> > > wrote:
> > > > On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > > > > + \item Support free and open source projects through the
> > > > > freedesktop.org
> > > > > + infrastructure. For projects outside the scope of item
> > > > > (\ref{1}) support
> > > > > + extends to project hosting only.
> > > > > +
> > > >
> > > > Yes to the idea but given that the remaining 11 pages cover all the
> > > > legalese
> > > > for xorg I think we need to add at least a section of what "project
> > > > hosting"
> > > > means. Even if it's just a "includes but is not limited to blah". And
> > > > some
> > > > addition to 4.1 Powers is needed to spell out what the BoD can do in
> > > > regards
> > > > to fdo.
> > >
> > > 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?
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
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 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. 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 -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ 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 Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote:
> >
> > On Tue, 16 Oct 2018 at 08:17, Peter Hutterer
> > wrote:
> > > On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > > > + \item Support free and open source projects through the
> > > > freedesktop.org
> > > > + infrastructure. For projects outside the scope of item (\ref{1})
> > > > support
> > > > + extends to project hosting only.
> > > > +
> > >
> > > Yes to the idea but given that the remaining 11 pages cover all the
> > > legalese
> > > for xorg I think we need to add at least a section of what "project
> > > hosting"
> > > means. Even if it's just a "includes but is not limited to blah". And
> > > some
> > > addition to 4.1 Powers is needed to spell out what the BoD can do in
> > > regards
> > > to fdo.
> >
> > 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.
Cheers,
Peter
___
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 Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote:
>
> On Tue, 16 Oct 2018 at 08:17, Peter Hutterer wrote:
> > On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > > + \item Support free and open source projects through the
> > > freedesktop.org
> > > + infrastructure. For projects outside the scope of item (\ref{1})
> > > support
> > > + extends to project hosting only.
> > > +
> >
> > Yes to the idea but given that the remaining 11 pages cover all the legalese
> > for xorg I think we need to add at least a section of what "project hosting"
> > means. Even if it's just a "includes but is not limited to blah". And some
> > addition to 4.1 Powers is needed to spell out what the BoD can do in regards
> > to fdo.
>
> 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.
Thanks, Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
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 Tue, 16 Oct 2018 at 08:17, Peter Hutterer wrote:
> On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > + \item Support free and open source projects through the
> > freedesktop.org
> > + infrastructure. For projects outside the scope of item (\ref{1})
> > support
> > + extends to project hosting only.
> > +
>
> Yes to the idea but given that the remaining 11 pages cover all the legalese
> for xorg I think we need to add at least a section of what "project hosting"
> means. Even if it's just a "includes but is not limited to blah". And some
> addition to 4.1 Powers is needed to spell out what the BoD can do in regards
> to fdo.
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
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 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> The leadership of freedesktop.org (fd.o) has recently expressed interest
> in having an elected governing body. Given the tight connection between
> fd.o and X.Org and the fact that X.Org has such a governing body it
> seemed obvious to consider extending X.Org's mandate to fd.o.
>
> Quite a bit of background on fd.o leading up to this has been covered by
> Daniel Stone at XDC 2018 and was covered really well by Jake Edge of LWN [1].
>
> One question that is briefly addressed in the LWN article and was
> thoroughly discussed by members of the X.Org boards, Daniel Stone, and
> others in hallway discussions is the question of whether to extend the
> X.Org membership to projects hosted on fd.o but outside the purpose of
> the X.Org foundation as enacted in its bylaws.
>
> Most people I talked to would prefer not to dilute X.Org's mission and
> extend membership only to contributors of projects that follow X.Org's
> purpose as enacted in its bylaws. Other projects can continue to be
> hosted on fd.o but won't receive X.Org membership for the mere reason of
> being hosted on fd.o.
>
> [1] https://lwn.net/Articles/767258/
>
> v2:
> - Subject line that better describes the intention
> - Briefly describe reasons behind this change
> - Drop expanding membership eligibility
> ---
>
> We're looking for feedback and comments on this patch. If it's not
> widely controversial the final version of the patch will be put to a
> vote at the 2019 X.Org elections.
>
> The patch applies to the X.Org bylaws git repo, which can be found at
> https://gitlab.freedesktop.org/xorgfoundation/bylaws
>
> Happy commenting.
>
> Harry
>
> bylaws.tex | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/bylaws.tex b/bylaws.tex
> index 4ab35a4f7745..44ff4745963b 100644
> --- a/bylaws.tex
> +++ b/bylaws.tex
> @@ -14,7 +14,7 @@ BE IT ENACTED AND IT IS HEREBY ENACTED as a By-law of the
> X.Org Foundation
>
> The purpose of the X.Org Foundation shall be to:
> \begin{enumerate}[(i)\hspace{.2cm}]
> - \item Research, develop, support, organize, administrate, standardize,
> + \item \label{1} Research, develop, support, organize, administrate,
> standardize,
> promote, and defend a free and open accelerated graphics stack. This
> includes, but is not limited to, the following projects: DRM, Mesa,
> Wayland and the X Window System,
> @@ -24,6 +24,11 @@ The purpose of the X.Org Foundation shall be to:
>
> \item Support and educate the general community of users of this
> graphics stack.
> +
> + \item Support free and open source projects through the freedesktop.org
> + infrastructure. For projects outside the scope of item (\ref{1}) support
> + extends to project hosting only.
> +
Yes to the idea but given that the remaining 11 pages cover all the legalese
for xorg I think we need to add at least a section of what "project hosting"
means. Even if it's just a "includes but is not limited to blah". And some
addition to 4.1 Powers is needed to spell out what the BoD can do in regards
to fdo.
Cheers,
Peter
> \end{enumerate}
>
> \article{INTERPRETATION}
> --
> 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: [RFC] Allow fd.o to join forces with X.Org
On October 15, 2018 2:50:13 PM UTC, Harry Wentland
wrote:
> The leadership of freedesktop.org (fd.o) has recently expressed
> interest
> in having an elected governing body. Given the tight connection
> between
> fd.o and X.Org and the fact that X.Org has such a governing body it
> seemed obvious to consider extending X.Org's mandate to fd.o.
>
> Quite a bit of background on fd.o leading up to this has been covered
> by
> Daniel Stone at XDC 2018 and was covered really well by Jake Edge of
> LWN [1].
If you'd like to watch Daniel's presentation, the recording is available on
YouTube:
https://youtu.be/s22B3E7rUTs
The slides are linked in the description.
>
> One question that is briefly addressed in the LWN article and was
> thoroughly discussed by members of the X.Org boards, Daniel Stone, and
> others in hallway discussions is the question of whether to extend the
> X.Org membership to projects hosted on fd.o but outside the purpose of
> the X.Org foundation as enacted in its bylaws.
>
> Most people I talked to would prefer not to dilute X.Org's mission and
> extend membership only to contributors of projects that follow X.Org's
> purpose as enacted in its bylaws. Other projects can continue to be
> hosted on fd.o but won't receive X.Org membership for the mere reason
> of
> being hosted on fd.o.
With my member hat on, I think this is the best choice.
Acked-by: Eric Engestrom
>
> [1] https://lwn.net/Articles/767258/
>
> v2:
> - Subject line that better describes the intention
> - Briefly describe reasons behind this change
> - Drop expanding membership eligibility
> ---
>
> We're looking for feedback and comments on this patch. If it's not
> widely controversial the final version of the patch will be put to a
> vote at the 2019 X.Org elections.
>
> The patch applies to the X.Org bylaws git repo, which can be found at
> https://gitlab.freedesktop.org/xorgfoundation/bylaws
>
> Happy commenting.
>
> Harry
>
> bylaws.tex | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/bylaws.tex b/bylaws.tex
> index 4ab35a4f7745..44ff4745963b 100644
> --- a/bylaws.tex
> +++ b/bylaws.tex
> @@ -14,7 +14,7 @@ BE IT ENACTED AND IT IS HEREBY ENACTED as a By-law
> of the X.Org Foundation
>
> The purpose of the X.Org Foundation shall be to:
> \begin{enumerate}[(i)\hspace{.2cm}]
> - \item Research, develop, support, organize, administrate,
> standardize,
> + \item \label{1} Research, develop, support, organize, administrate,
> standardize,
> promote, and defend a free and open accelerated graphics stack. This
> includes, but is not limited to, the following projects: DRM, Mesa,
> Wayland and the X Window System,
> @@ -24,6 +24,11 @@ The purpose of the X.Org Foundation shall be to:
>
> \item Support and educate the general community of users of this
> graphics stack.
> +
> + \item Support free and open source projects through the
> freedesktop.org
> + infrastructure. For projects outside the scope of item (\ref{1})
> support
> + extends to project hosting only.
> +
> \end{enumerate}
>
> \article{INTERPRETATION}
> --
> 2.19.1
>
> ___
> memb...@foundation.x.org: X.Org Foundation Members
> Archives: https://foundation.x.org/cgi-bin/mailman/private/members
> Info: https://foundation.x.org/cgi-bin/mailman/listinfo/members
___
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
