[ogb-discuss] Device Driver Community

[Alan DuBoff]

On Thu, 3 May 2007, Keith M Wesolowski wrote:

> Not at all; a Core Contributor is exactly what the Constutition says
> it is.

To be honest, it doesn't say much at all. What is the point in having 
Core Contributers and/or Contributers might I ask? Other than voting 
rights, it doesn't seem there's much meat to it.

> About the only Community
> Group in which this type of requirement would make sense is one that
> doesn't even exist (and would probably be over-broad if it did):
> Kernel.

The device drivers are an intregal part of the kernel. Although the GPL 
has never been taken to court, most lawyers seem to be in agreement that 
considering anything linked with the kernel and/or operating with it be 
classified as a special case, so to speak.

This goes back to the 2.4.13 kernel when the requirement to export a GPL 
define for a driver was mandatory not to taint the kernel.

Certainly we are held to the same standard and can decide on what to do, 
but Sun's legal seems to go under that presumption. Personally I would 
have liked to see Sun challenge that point, because it's never been held 
up in a court of law. Most answers that come from legal seem to hold the 
assumption that this is true, even though it has never been held up in a 
court of law.

> Systemic knowledge is extremely valuable.  It is not, however, a
> prerequisite to having "contributed substantively to that Group's
> efforts" nor to being given a role in governing the Group's future
> efforts.

Absolutely shouldn't be a requirement to contribute to the group, but if a 
device driver is going back into Solaris, certain standards need to 
continue. The current test suites are tough for any driver to pass, and 
even some of the drivers that are put back already would fail if run 
through some of the test suites again, IMO, but many of them haven't been 
tested in years.

I would be curious how the dmfe, after converted to GLDv3, reatcs to the 
test suites. I don't know if that is a requirement to putback a change 
such as that, but it should be.

> It was determined arbitrarily, based on their history of contribution
> and the defunct status of the existing Community Group.  I argued for
> a deeper investigation

No need to argue, but continue to suggest that investigation for not only 
the device driver community, but all communities in general meet some type 
of standard in how the contributers are decided, and how many will be 
allowed. Some of the

> given that these individuals were among those
> asked to submit lists of Contributors, but it was felt that the risk
> of disenfranchising them in the OGB election was greater than the
> benefits associated with understanding how the problem arose in the
> first place.

And now the elections are over and it's up to the OGB to decide on how to 
handle that. Seems like business unresolved.

> There is no requirement that a Core Contributor have a record of
> putting back to any particular consolidation, or even a project gate.

Yeah, in reading the text of the constitution there is really nothing that 
such a status would do, other than voting rights...whopee...Some 
communities have more than a dozen contributers, like user groups for 
instance.

On the website itself, what is called a leader is merely a person that can 
edit the pages of the community. That should be changed, a leader implies 
much more than being able to edit. Just because someone needs to edit 
doesn't mean they need to be a leader.

I would encourage the OGB to draft up some type of guidelines and/or 
change the name of "leaders" to "editors" possibly, it's confusing.

> Not at all.  The consolidations are not mentioned by the Constitution,
> an unfortunate shortcoming we'll be working to address.

I'm glad you mention that. I would like to add that in the case of ON, the 
context is much more important, IMO, since it's the core of the system, 
well...today it's the system as OpenSolaris is concerned. However, in the 
future we need to be able to add additional software, or what is termed 
layered software and/or web services/software.

As an example, I have an open source library that allows data transfers 
over http. It's a small library that was intended for embedded work, but 
other folks started to use because it's small and lean.

Since the code is licensed under the BSD license by my choice, and the 
fact that BSD is considered to be acceptable code for OpenSolaris, I will 
run it through an opensource review and contribute it. Since this is 
software in userland, it seems different than something like device 
drivers and/or ON code.

> The idea is broader than that; many Groups might not ever sponsor a
> Project that integrates into any consolidation; for example, the
> Advocates (Marketing/User Groups) CGs.

I would like to see a distinction between those types and the types that 
are contributing to ON. These are very different types of what is being 
called leaders, IMO.

> It's up to the Groups to provide their own guidelines.  The Groups are
> largely independent; the OGB's role is to advise and to hear appeals,
> not to meddle.  This allows great flexibility in the types of
> Community Groups that can be established and how they can achieve
> their goals.

If we allow this to happen in this fashion, we will end up with partial 
kaos. Not that it is bad, just that we will have so much different between 
the communities that it will make it more difficult to deal with as a 
whole.

>> Ultimately we need to way to prevent code from just flying back into
>> OpenSolaris, I had thought the contributors and core contributers might be
>> the means to do that...my bad...doesn't seem the core contributers, or
>> even contributers will make much difference in that regard, and in fact it
>> is probably only voting rights. I was hoping they had some control over
>> the community at large.
>
> I share your frustration; the Constitution makes no attempt to address
> what consolidations are or how they may be governed.  But it's been
> fairly well established based on the current structure and discussions
> about reorganisation that they do not fit well as Community Groups
> themselves, nor is any particular Community Group (other than a
> consolidation-specific one) well-positioned to make decisions
> regarding a consolidation.  It remains to be seen how we will move
> consolidation processes into the fold.  Ideas and suggestions are
> welcome.

I would like to see some way of starting by cleaning up what needs 
cleaning, and try to align some of the communities together (based on 
consolidation is fine with me, but currently we really only have ON).

I thought it would be possible for communities to have some control over 
their specific pieces, before placing that on the OGB and/or ARCs when 
they're formed.

I spoke with AlanC today and got the impression that some of this might be 
a little early and that we should wait for things to be put in place.

There is no obligation for anyone to stay in a specific community, so it 
would be nice to try and have something that a contributer would be 
expected to meet after being recognized as such, even if something so 
simple as to be around for xxxx amount of time in the community if 
accepting such recognition.

Of course the willy-nilly way that communities are created to begin with 
needs to be addressed at some point, unless the OGB wants it to continue 
to be as it currently is, but to me that seems like an odd way to build 
communities...what do I know...


--

Alan DuBoff - Solaris x86 IHV/OEM Group