On Jun 30, 2005, at 2:11 PM, Ricardo Morin wrote:
Hi,
I have some comments on Section I, Division of the
Repository. In the current proposal, it appears as if
the partitioning of the repository is three big
chunks: JVM, Class library and Website/Documentation.
Due to the very large size of this project, I would
like to propose to break down the Class library part
into the following more discrete modules:
- GUI – Essentially swing
- Client – Awt, java2D, etc
- Core – lang, util, networking, io
- Enterprise – jdbc, corba, jmx, etc
- Security – security and crypto
- XML – Xerces/Xalan
- Tools – javac, jar, jdb, etc
If we ever have to do a class library, this is fine by me.
This will move the project more in the modular
direction, which was stated as one of main goals for
Harmony. I believe that communities of interest are
most likely to form around these projects.
Yes, indeed. But for now, until we have a compelling reason to
consider our own class library, we're working out how to work with
GNU Classpath.
So Section I would look like:
I. Division of Repository
-------------------------
1) JVM
2) GUI class libraries
3) Client class libraries
4) Core class libraries
5) Enterprise class libraries
6) Security class libraries
7) XML class libraries
8) Tools
9) Website and Documentation
I'd rather see, if we did classlib :
1) JVM
a) core
b) mm
c) JIT
i) interpreter
ii) compiler
2) ClassLibrary
a) GUI
b) Client
c) core
d) ....
.....
z) tools
3) Website and documentation
This is a minor restructuring, but one that seems to make more
hierarchical sense to me.
I would also like to propose to update Section II to
clarify the granularity of the access control list to
the division of the repository above.
That or finer, because we may need to partition some of the large
grain down, such as having a person who has to be kept out of
jvm.jit.compiler but can work in interpreter.
Right?
geir
Thoughts? Comments?
Thanks,
Ricardo
--- "Geir Magnusson Jr." <[EMAIL PROTECTED]> wrote:
NOTE : THE FOLLOWING IS FOR DISCUSSION PURPOSES.
THIS PROPOSAL GOES
BEYOND STANDARD APACHE PRACTICE, AND WILL HAVE TO BE
REVIEWED - IF WE
CHOOSE TO FOLLOW THIS ROUTE - BY THE ASF.
There are many legal and political concerns about
the Apache Harmony
project, and it behooves us to do the best job we
can at all times in
ensuring that the software contributed or created by
the community is
as "clean" (in the IP sense) as possible. We do
this to protect the
ASF, the committers, and the users of the software.
There are are few issues that come to mind when
thinking about
committers :
1) What IP has the committer been exposed to,
and what is the position of the owner of that
IP
with respect to the committer's
participation?
For example, has the committer been exposed
to
copyrighted or patented material, in which an
accidental re-creation would put the project
or users at risk of legal action from the
IP owner?
2) If people have been exposed to code that
would be
problematic for us, what can we do to allow
the maximum
participation with the minimal risk?
3) How do we ensure that we carefully track our
committers and what they've been exposed to?
To solve, consider the following :
I. Division of Repository
-------------------------
For starters, we can divide our SVN repository into
parts :
1) JVM
- VM
- JIT
- GC
- etc
2) Class library
- VM/lib interface :-b
3) Website and Documentation
and we limit access to the SVN to which your
contributions have no
"taint" as we understand it at the moment. Because
attitudes will
change over time, I think that "taint" can go away
as an individual's
issue that causes the 'taint' gets resolved.
We can start with access for website and docs
immediately w/o much
consideration for 'taint'.
II. Specific Access Control Lists
----------------------------------
Through fine-grained (as necessary) access control
lists for the SVN
repo, we'll allow committers into repos for project
components for
which they have no "taint". If they've worked on
Sun's class
libraries in the past but no exposure to VM, we keep
them from any
class library work we do (if any) and allow them
into VM-related code.
I think for simplicity in accounting, we should be
conservative and
explicit about access. You are granted access only
to repos that you
ask to be granted access to (although with the
exception of the
"taint" issue, we should grant to anything asked
for...) and
encourage people to keep their personal list small,
and ask for
access to be removed if they no longer need it.
III. Strict Limits on Committer Contribution
---------------------------------------------
Committers can only commit contributions to the
repositories that
they personally created specifically for
contribution to Apache
Harmony. This is the standard stream of fresh
original work, small
enhancements and patches that are the normal flow of
project life.
The purpose of this rule is to explicitly prohibit
re-purposed "bulk"
code that the contributor believes is their original
work. We can
still accept those, but wish to track them
explicitly.
IV. Be Proactive in Committer Education
---------------------------------------
People sometimes forget or don't understand the
intricacies of
copyright and authorhsip, and just want to get work
done. Therefore,
we should make a special effort to remind the
committers of the
limits, give them clear information on what to do if
a commit isn't w/
in the rules, and where to ask questions (and a list
of answered
questions for reference).
We could have this as part of a standard svn commit
message template,
for example. Other ideas welcome.
V. Required Committer Paperwork
-------------------------------
Each committer is required to complete an standard
Apache Individual
Contributor License Agreement. This document
asserts that the
contributor is licensing their material to the ASF
under the Apache
license and is their original work (there's some
other details).
For employed committers where it's appropriate, I'm
interested in
what we can do to get validation that the employer
doesn't own the
rights to the employee's work in the project. While
this is not
applicable to many legal jurisdictions, it is
applicable to the US,
and an element of concern here for Apache Harmony.
We don't want
code to be contributed that will later be deemed to
be a work for
hire or other kind of property of the employer, and
thus give a third
party some claim on us or our users.
We would like to know who is contributing to the
project. To this
end, we might consider a form asking information
like the following.
This goes beyond standard ASF practice, and we would
of course have
this reviewed and approved by ASF lawyers and other
interested
members of the community (yes, it's fairly
conservative...) :
-------------------------------------------
1) Identification
Please provide the following information
- Name (real name, please)
- E-mail and other electronic contact
information
- Mailing address (include Country)
- If you have an employer, include name and
address of employer
2) Access to Repositories :
Apache Harmony would like to limit write access
to repositories
to those that need it, but will grant all that
is asked for as long
as there are no 'taint' issues.
- Which components are you interested in
working on?
3) Taint
The Project is committed to producing an
implementation
=== message truncated ===
____________________________________________________
Yahoo! Sports
Rekindle the Rivalries. Sign up for Fantasy Football
http://football.fantasysports.yahoo.com
--
Geir Magnusson Jr +1-203-665-6437
[EMAIL PROTECTED]
