> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Neil Horman > > On Tue, May 19, 2015 at 05:45:05PM +0200, Thomas Monjalon wrote: > > 2015-05-19 11:34, Neil Horman: > > > On Tue, May 19, 2015 at 07:43:14AM -0700, Stephen Hemminger wrote: > > > > > Composition of the TSC should reflect contributions to the > project, but be > > > > > balanced so that no single party has an undue influence. It > should also be > > > > > kept to a manageable size(maybe 7?). > > > > > > > > > > The TSC should elect its own chair, who would have the deciding > vote in > > > > > the event that the TSC was deadlocked. Once in place, the TSC > should > > > > > approve any new members. > > > > > > > > > > Specific details on membership can be discussed and agreed > later, if we > > > > > agree on the creation of a TSC. > > > > > > > > TSC should be limited to those individuals and companies that have > > > > contributed in a non-trivial way to the DPDK distributed code > base. > > > > It should not be a users group, or place for network vendors who > take but > > > > never give back. > > > > > > > +1 > > > > > > It should also endavour to only act as a fallback body for any > issues commonly > > > handled by the development communtiy (patch acceptance/review, etc) > > > > I agree that it should be a fallback. > > And I'm wondering how useful it would be: have we ever known such > discussion or > > conflict without finding a solution or a consensus? > Well, I suppose the jury is still out on that, since there are ongoing > problems, > in the form of patch latency, and such. But for the most part, no, > problems > tend to reach consensus resolution IMO
It's true that there aren't many obvious examples, although as Neil points out there are still some things that are ongoing. One issue that springs to mind where we didn't reach consensus was inclusion of ABI Versioning in 1.8. It was subsequently included in 2.0, but there were people who believed it should have been in 1.8. The other issue with having to reach consensus on everything is that it tends to a lowest common denominator approach, and can slow things down. There are times where a clear decision and then everybody moving forward is preferable. > > By the way, is there a TSC in Linux netdev? > > > No, but there are TSC for many projects, including Openshift, > freedesktop.org, > etc. > > Neil
