|
|
On Fri, 4 May 2007, Roy T. Fielding wrote:
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.
One of the most important things for open source projects is to properly
acknowledge contributions. In many ways, it is the only thanks that
anyone gets for contributing toward the goals of the group. It is also
essential for tracking intellectual property claims when they occur
(and they *will* occur, even for a nonprofit like Apache). The
Contributor category and associated requirements exist to document
the responsibility of Groups for maintaining a list of credits.
That's a valid point, most certainly. But wouldn't the license be the
determining factor on IP?
The Core Contributor category is to identify the people who are able
to make decision for the Group and to emphasize that we want the
people doing the most work (or having invested the most time) to be
the ones responsible for making decisions, rather than just whoever
writes to the mailing list today.
And that's important to some.
Note that there are a lot more ways to contribute than simply coding.
It is difficult to list them all, so we left it wide open.
Sure, but I was thinking there would be some type of guideline so that
things were more consistent across a community at large, for user groups
for instance. The way in which it was decided didn't account for any type
of consistent action, and the results display that.
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.
I agree.
This seems to be in agreement that something should change in regards to
this, so I'll let the OGB work that out.
As an "outsider", my perspective was that the notion of consolidation
and the products grouped into consolidations were both completely
arbitrary accidents of business reorganizations within Sun.
I am not sure I understand why, but even in other distributions such as
Debian, they have several areas that could be considered similar. free,
non-free, contributed, ...
I'm not sure why a consolidation for ON doesn't make sense, it seems that
many distributions would want/need to use it and include it in their
distribution. It is a consolidation of software. The same applies to free,
non-free, contrib, for Debian in many ways.
Even
after all this time, the current consolidation structure makes no sense
to me. That is why they aren't in the constitution. I figured it
would be better to leave it unspecified than to write something into
the constitution for which I did not understand the rationale, let alone
the desired structure for opensolaris.
Because they didn't make sense for you, is quite honestly no reason that
it doesn't make sense to others. That is after all why we have 7 member of
the OGB, so that no one point of view could be taken by any single board
member, no?
AFAICT, consolidation just means a release management process for a
given set of products. In my opinion, that should be a project of the
community that owns that product(s). However, I am sure that you guys
have a much better handle on how consolidations coordinate work in
practice (at least from the perspective of Solaris releases), so you
are in a much better position to define it correctly than the CAB.
No, I think this is true as I see it also, just that you view the entire
distribution (for lack of a better term) to be one large consolidation,
which it is.
The problem with a large consolidation is that there are overlaps and grey
areas between them, so grouping them together in smaller consolidation not
only makes it easier, but allows for a way to deal with those
consolidation as a group, rather than a whole.
If OpenSolaris were producing a distribution, then I'd suggest a
single consolidation structure along the lines of Ubuntu Linux.
In other words, a distribution community that is responsible for
overlapping "release" projects that terminate every six months.
Then the individual product releases (managed by each product's
community) would be independent from the overall release project.
But, YMMV.
It is one way to look at it, but creates a very large consolidation to
deal with as a whole. If consolidations were smaller, it would allow more
people to use them. As an example, if we did have an embedded community,
it could include the needed components of an embedded system, so that
people building embedded distributions could get them as a whole. By
lumping those all together might make it more difficult for embedded to
strip out what they want.
In the same light, would an opensolaris distribution targeted for destkop
really need software such as busybox? I think probably not, but many do
have it (Debian, Red Hat, etc..). For most all purpose, there is no reason
to duplicate the standard system utilities with something such as busybox
if you have the space.
--
Alan DuBoff - Solaris x86 IHV/OEM Group
_______________________________________________
ogb-discuss mailing list
ogb-discuss@xxxxxxxxxxxxxxx
http://opensolaris.org/mailman/listinfo/ogb-discuss
|
|