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
