Shawn Walker wrote:
Garrett D'Amore wrote:
Shawn Walker wrote:
This is the sort of project that needs to stay in sync with whatever
the ON community is doing so they can be aware of big gate or
process changes, and so that they can work together.
I don't like the idea of making this project formally subservient to
the ON Core Contributors (who are ultimately also its C-Team). The
point of this consolidation is to deal with stuff that has been
*excluded* from ON.
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?
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 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.
While that doesn't directly fit what you have here, I think that
there's a lot of overlap in the needs of that project and what
you've proposed. In particular, due to the relatively low volume of
external ON contributions that are currently seen, I suspect that if
we see an increase in them, there's a good chance it will come from
what has been proposed here.
Possibly. I'm not sure that the overlap is quite what you mean
though. I'm also, btw, not sure that the SCA rules need to follow
for this consolidation. It might be that they do in order to be
hosted on opensolaris.org... the SCA is about giving Sun rights to
code. If Sun isn't integrating the code, then is an SCA truly
necessary? IMO, it isn't. But I need to check what the governance
rules for SCA are.
Even if that weren't the case, I personally would be extremely
uncomfortable taking contributions from individuals who have not
provided some sort of guarantee to the community that the code they
contribute belongs to the community and that they have the right to do
so.
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.)
BSD projects don't do this, btw.
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.)
The other thing is that a lot of the stuff I'm talking about would
automatically fail the current RTI process, which requires a lot of
extra things to be in place, mostly to support Sun's business needs
around OpenSolaris and Solaris. Since this consolidation is
explicitly not part of Sun's distros, it can be free from all that
overhead.
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.
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.
- Garrett
_______________________________________________
opensolaris-code mailing list
opensolaris-code@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code
