[Gluster-devel] [FEEDBACK] Governance of GlusterFS project

[Emmanuel Dreyfus]

Hi

it seems the message below was written some time ago but was stuck in my
mailbox. Here is it released:

Anand Avati <anand.avati at gmail.com> wrote:

> Please do. I'm curious to know how releases happen (release engineer?
> team?) and how new committers are added in the NetBSD project (votes? by
> who? are there quantified criteria?) I'm sure there are lessons we can
> learn from such a longstanding project.

First a warning, it is not obvious if GlusterFS can grab recipes from
NetBSD, which has between 200 and 250 developers. The large number means
NetBSD can afford to have many task-specific teams. On the technical
side, we have:

Security officers
They are the point of contact for security issues. They coordinate
security fixes to supported branches, co-write security advisories with
whoever made the fix, and they publish the security advisory. GlusterFS
fame and surface attack are low enough to let it spare security for now,
but that will not last forever.
 
Release engineering
They manage release branches, with different teams for each supported
branch (there are two supported branch at a time: currently netbsd-6 and
netbsd-5). Release engineering has an exclusive commit access to the
branch: regular developpers send tickets with pullup-requests, something
GlusterFS already does.

Core team
Usually, implementation design is done by discussion on the mailing
lists, where a proposal must meet consensus. If no consensus is
obtained, the core team can be asked to make the decision. IMO this is
something GlusterFS could do: democracy is good and desirable, but it
also needs a small government to make some decisions on specific issues.
And having a team that is responsible for that avoid non consensual
changes to get stuck forever.

[Release cycle pace and NetBSD support]
> Indeed. My guess is that the issue was probably perceived as a NetBSD
> specific issue?

It was caused by an uninitialized mutex. You are just lucky Linux accept
to make that work, but this is bad practice. 

> This specific bug apart, the next question - what are the
> platforms we officially support? So far you have been doing an outstanding
> job of keeping the NetBSD port active, but it is still not "official". I
> would like to throw open the question of whether you would be interested in
> getting involved with the GlusterFS project in a deeper manner so that the
> NetBSD port too is considered a first class citizen - part of
> smoke/regression tests, 

To be honnest, I was less and less sure it was relevant to support a
NetBSD port considering how fragile it has been. Being part of the
regression tests would change that. I woule be happy to help here.

> part of design discussions (to at least consider
> alternatives / fallbacks in NetBSD when planning to use a Linux specific
> feature/API),

Well, I already did the fallback part already a few times.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu at netbsd.org