On Sun, Jul 28, 2013 at 9:23 AM, Emmanuel Dreyfus <manu at netbsd.org> wrote: > Anand Avati <anand.avati at gmail.com> wrote: > > > We are in the process of formalizing the governance model of the > > GlusterFS project. Historically, the governance of the project has been > > loosely structured. This is an invitation to all of you to participate in > > this discussion and provide your feedback and suggestions on how we > should > > evolve a formal model. > > IMO GlusterFS needs a governance that fits core developpers' tastes. > After all we speak about making decisions impacting the way they work. > > As a minor contributor, I do not feel legitimate to push in any > direction. I can just share my experience in governance in projets I > know about (NetBSD, milter-greylist), if someone is interested. > 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. > I can also point what looks like governance failure to me. It is a bit > annoying to have a show-stopper bug and see release cycle going from qa > to alpha to beta to release just like a river flows to the sea. Indeed. My guess is that the issue was probably perceived as a NetBSD specific issue? 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, part of design discussions (to at least consider alternatives / fallbacks in NetBSD when planning to use a Linux specific feature/API), bugs discovered while testing NetBSD not considered "low priority" implicitly with the doubt that it might be NetBSD port specific, etc. If you are willing to take on a more official NetBSD port maintainers position for the above reasons, we can certainly create such a "Role" in formal way with appropriate commit access. > Other > already said it, but there need to be some process to settle (bug, > feature) vs (release schedule) conflicts. It can be a single release > engineer, a release engineering team as a round table, or a democratic > vote from whatever group is prefered, but at least there should be some > accounted decision here. > Certainly. This is good input. We need to clarify the process of what/how make it to the release blocker list. Thanks, Avati -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://supercolony.gluster.org/pipermail/gluster-users/attachments/20130728/9265f21c/attachment-0001.html>
