[RFC] Allow fd.o to join forces with X.Org

[Daniel Vetter]

On Mon, Oct 29, 2018 at 01:24:56PM +0000, 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 <daniel at fooishbar.org> wrote:
> >>
> >> Hi,
> >>
> >> On Fri, 26 Oct 2018 at 11:57, Daniel Vetter <daniel at ffwll.ch> 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 <daniel at fooishbar.org> 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&servers 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
http://blog.ffwll.ch