[ogb-discuss] Device Driver Community
Alan DuBoff
alan.duboff at sun.com
Fri May 4 17:34:38 PDT 2007
On Fri, 4 May 2007, Keith M Wesolowski wrote:
> Roy's comments here seem spot on to me. I think you may have
> different expectations from the rest of ours for what a Community
> Group is.
I'm not sure that I even understand all of the constitution in that
regard. I do think the constitution is much more complicated than it needs
to be, and communities are an example.
Like maintaining records, I know of no communities that are doing that
today. Can you point me to one that is maintaining records of
participation?
Or why do we need to have compilication such as 7.10 (Meetings)? It should
be understood that a community exists and in this type of mode from the
start, until it is deemed terminated (at which point it wouldn't exist).
> No one is suggesting that integration requirements have changed.
No one has suggested to the community that it will remain the same.
It has been 2 years almost, we're struggling to get SCM in operation.
There are still closed cases that can't be viewed in bugster.
Will the gatekeeper remain or will the community need to find one?
Will ARCs be formed from Sun people, or can other community people be
involved in that.
As it is today, the biggest part of opensolaris is Sun. I think some of
the other community members might be intimidated and/or feel that they're
not a part of the process. I wouldn't say I blame anyone for feeling that
way, given the way things have progressed.
> Review, testing, and completeness checks are still in place and we
> expect them to remain in place, perhaps with minor changes,
> indefinitely.
Do you think that is understood by most of the community? It seems an
important issue, and it seems something that most people will want to
understand. For that matter, do folks outside of Sun really understand
much of the process as it is today?
> You seem to think that most (or even all?) of the 43
> Community Groups will be responsible for enforcing, and perhaps
> constructing, those requirements with respect to its area of
> expertise.
In so many words, it seems like what AlanC has stated, that each community
is responsible for such.
> Such a system would look nothing like the one we seem to
> be moving towards - one in which the number of consolidations remains
> relatively small (a dozen or fewer) with architecturally meaningful
> boundaries and centralised management.
Hmmm...seems that AlanC mentioned the communities being responsible for
looking over their stuff, so that it would allow each of them to demand
whatever they want in regards to a putback for instance. You imply
different possibly...Maybe I misunderstood him.
> to take a device
> driver as a seemingly obvious example, shouldn't an author seek the
> advice of the DTrace Community Group with respect to SDT probe
> placement and usage?
Sure, if that is what they're trying to accomplish.
> Shouldn't he or she gather input from the
> Systems Administrators Community Group as to how the driver should be
> controlled?
Depends if that is even a question for them.
What about even before they get to that point. What about determining if a
specific device driver should even be included in OpenSolaris?
> The Constitution implies rather strongly that approving putbacks is a
> Community Group function, but I'll be damned if I can construct a
> meaningful Community Group that would be sensibly positioned to make
> such a call without being entirely inconsistent with the structure of
> the existing Groups. It may be that we'll end up there anyway, with
> some Community Groups being more equal than others.
This seems very confusing in how it is unfolding. I think the OGB needs
time to look things over and act on what they feel needs attention. Maybe
this needs to be revisited.
>> 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
>
> We don't actually need to do anything; the Constitution already
> requires Groups to establish their own requirements. The OGB doesn't
> get to dictate what those requirements may or may not consist of, but
> someone who feels a Group is acting improperly is welcome to appeal.
So, as an example, if a community decides that every person in their
community needs to have contributor status because they're involved and
working with the community, it should be granted?
> The User Groups Community did indeed make a lot of grants that we
> might not agree with, and it appears that many of them will be
> discontinued as part of its reorganisation and merger with the
> Marketing Group. I'd suggest a bit of patience here - if you've been
> following the conversation on this and other lists, you've seen that
> things are absolutely moving in the right direction.
I've seen some of it, but haven't seen anything in the last week, so maybe
I'm not on the list they're discussing things at. This is another
point...we have a lot of communities and it's growing quickly. It's hard
for everyone to be a part of all communities, and I don't think that was
intended anyway. But this means that decisions are being made that much of
the community doesn't even know about, such as the OGB delaring the device
driver community defunct.
I certainly didn't need to push this point, I have no obligation to the
device driver community, nor do I for any other community. Neither does
anyone else, even if contributor status is granted to a person, it doesn't
mean much other than acknowledgement and voting.
What happens when someone is appointed a contributor, and changes their
focus to something else? As an example, let's say they go work at a
company focusing on Linux, and all of the sudden have a new found love for
Linux. There is no obligation, even if they have contributor status.
I would be curious to know, did 100% of all contributors vote in the OGB
election? I think not, and I don't care. I'm just pointing out that there
is no obligation even if one does have contributor status.
> We simply don't have the Constitutional tools to enforce such a
> distinction, even if we believed it were necessary. If we were to
> decide that the best representation for a consolidation's organisation
> is a Community Group, then ON's sponsoring Group would have the same
> responsibilities, constraints, and privileges that other Groups have.
But ON is comprised of many pieces in itself. There are pieces that are
not even related to each other, other than the fact that they're a part of
ON. shells as an example was brought up by JimC.
> We can't force people to work together who don't want to. All we can
> do is give them tools to accomplish their goals and global frameworks
> for resolving their conflicts. I still believe that a more rational
> and consistent view of this community would consist of perhaps eight
> to ten Groups representing vertical segments of the software stack and
> another handful representing horizontal layers (corresponding roughly
> to consolidations and ARCs). But it's very obvious that most people
> don't want such a structure, and don't believe they could be
> productive within it. As for the flexibility to include Groups not
> sponsoring projects that expect to integrate code into a
> consolidation, I'm glad to have it - it allows us to represent types
> of activity that could not have been otherwise.
This is where the OGB needs to decide as a whole what would best benifit
opensolaris. If you folks truely believe that it would help our community
and would like to offer some type of reccomendation, it might help
indecisive communities.
> As Alan pointed out, this is not really correct. But I'd like to
> follow your line of thinking to its logical conclusion - please
> compose a list of Groups and a mapping from each one to a
> consolidation.
Better yet, if you could let me know how having a tarball thrown in the
community really makes it a part of opensolaris? My take is BFD, just
because some package is on opensolaris doesn't make it a part of it.
If I understand you, opensolaris is just a compilation of various projects
that have no correlation to a system. How does that help opensolaris?
There could be some software that opensolaris wants to get rid of, such as
the closed binaries, so just because software is there today doesn't mean
it is or will be a part of opensolaris in the future.
> The OGB does not make technical decisions, except possibly in response
> to an appeal of last resort. Like the consolidations, it's unclear
> how the ARC is to be represented in the new model - it works poorly as
> a Community Group, but again we simply don't have many choices.
Well, it has worked ok to now. I'm not sure why that couldn't continue in
the future, but that's not up to me to decide.
>> 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.
>
> Yes. We're still working on Group reform, and haven't yet tackled the
> more challenging problems of consolidations and the ARC, much less the
> really intractable ones like defect management.
No problem Keith, I wasn't trying to breath down your folk's back...
--
Alan DuBoff - Solaris x86 IHV/OEM Group
More information about the ogb-discuss
mailing list