Shawn Walker wrote:
Garrett D'Amore wrote:
Shawn Walker wrote:
I don't agree with that. The OpenSolaris constitution structure
doesn't mean that an ON-sponsored project is subservient to the ON
Community Group. If you're really that worried about that sort of
influence, then you don't want to be on opensolaris.org anyway :)
I think this project needs to have its own CCs that do its own
voting, etc. Other consolidations do this, why not this one?
Why do you need CCs to make decisions? Even then, you don't need your
own CG to have CCs if you align with the correct CG :)
We at least need a committee of folks who can make decisions about the
code that goes into the tree, because there will probably be conflicts
at some point. I think we should also be represented in the larger
community, and I don't think ON's interests will accurately reflect our
interest. I think a separate CG is called for here.
This is about communication and direction, as well as overlap. From
a strictly os.org point of view, I don't see why this shouldn't be a
sponsored project of the ON CG. To me, it fails the common test for
an independent CG. If you don't want it sponsored by ON, then I
think it needs to be sponsored by some other related CG.
What test is that? Other consolidations have their own CGs, why not
this one?
I don't see this as a consolidation; and aren't consolidations
strictly a Sun thing anyway? I thought you were wanting to remove all
'Sun' aspects from this...
Its a consolidation in that its a repository of common code, yes. It
will also have its own gatekeeper(s) and rules for integration. I think
you should go back and read the original proposal again. (Or explain
why you don't think this is a consolidation.)
I also believe the issue of where the code lives is completely
separate from community governance structures. The ON CG doesn't
get control over your project's repository just because they are
your sponsor, any more than the installer, etc. CGs get control over
the pkg(5) repository because they sponsor the Image Packaging
System project..
No, but I think this project should have its own CCs who vote on
matters both internal to this project, but also get representation in
the larger audience. These CCs might well fall below the threshold
for ON CC grants (which are based on contribution to ON!)
I don't understand your objections here.
I don't understand what the concern is about autonomy. The
OpenSolaris constitution makes it very clear here that project
decisions remain the purvue of projects; not of the CG (as I
understand it).
This might have been misunderstanding on my part. I thought a Project
had to abide by whatever decisions were made by sponsoring CG.
Even then, I suspect this will change soon if the constitution is
further updated and that point your concerns will be moot (based on
current direction).
As such, I'll digress on this point. I personally would not approve a
CG for this project; I don't believe it meets the criteria under the
current constitution for the scope that is intended for a Community
Group. But it isn't my decision, so proceed however you will.
I still don't understand your objection. Do you believe that this
project does not warrant having its own representation at election
time? Why not? (Again, I think our interests and those of the larger
ON community might be divergent at times.)
Even FSF projects require some sort of contributor agreement for
contributions of a certain scope to gcc, etc.
FSF does the same thing for the same reasons that SCA does. It has
nothing to do with assurances of original authorship, and
*everything* to do with making sure that there is a single copyright
owner who can change the license at any time. (This allows FSF to
globally change the GPLv2 to v3 on its projects, for example, without
requiring individual authors to sign another agreement.)
It isn't just about authorship; it also has to do with patent rights,
contributions from those under an employment agreement, etc. from my
rough, non-legally qualified understanding of things.
That's part of CDDL, not SCA.
I'm primarily concerned about any drivers or fixes from this project
that result in other users from being unable to benefit from them
since they won't be able to be integrated back into ON.
We integrate stuff without an SCA from other FOSS into ON all the time.
It might be that if you use the CDDL that an SCA is required. But BSD
licensed code has no such problems.
In any case if folks want to get their code integrated into ON, then
they will have to follow ON's rules, still. I don't see how that is a
problem. (It may mean that at some later date the Contributor has to
sign an SCA. So what?)
I'm not sure that an agreement does anything really to mitigate the
risk of copyright violation or plagiarism. If the author has ripped
off the original copyright notices, who's to say they're going to be
honest in their agreement? (Especially since the SCA and the code
submissions generally happen at two points in time that are very
disjoint from one another.)
There's a big difference between someone's verbal assent that they
have the right to contribute something and won't assert patents, etc.
and a written, signed agreement :)
We don't currently require that from everyone.
Note that such an agreement is *only* between Sun and the contributor.
At the end of the day, I don't really care if we require and SCA or
not. I don't have a strong feeling on it. Its not a big deal, but I
still believe that the SCA is designed to facilitate Sun's business
needs, and offers little value to the rest of the community.
But I digress on this point; I'll let you followup with the
appropriate parties.
Yes, but I'm assuming that a very similar formal RTI process will
still be needed for this project.
No, much less formal. No C-Team review. A basic code review and
sign-off by a CC who would basically be acting as CRT advocate. The
idea here is a much lower barrier to entry.
As I said, "similar".
Actually, pretty dissimilar. I think at the end of the day our process
will be at most about 25% as much work as ON's.
If you've ever tried to commit code to ON, you'd understand that
there is a very high bar to get new code into ON.
I have RTIs for ON as an external community member, so I'm somewhat
familiar with the fairly arduous process :)
If you submit a new driver, or a new "project", the process is far more
arduous than just a normal bug fix.
- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
