2.0
- declared M1, with cautions
- Dali/JPA [Neil]
- JSF [Raghu]
- ATF [Bob]
= = = = = = = = = = = = = = = = =
= = = = = = = = = = = = = = = = = = = = = = = = =
Proposed clarification of "code change"
process.
Our WTP Charter, and the The Eclipse
general charter it refers to,
specifies the general procedure and decision process used for changing
code.
I think WTP is far enough along and
being used for enough business critical applications, that we, the
PMC would be best to clarify what the specific
procedures and decision processes are.
The charter itself allows the "The
PMC defines the decision process" so, my proposal is not a change
to the charter, just more
specific. I think this is important
to be clear on this decision process before controversy arises, since WTP
is a very complex project, and
becoming more complex, and is very heterogeneous
in the companies represented. It is not that I anticipate controversy,
just that the current procedures and
process is a bit general. Also, I should be explicit, I have no doubt of
the good will of all
involved in WTP ... but, good will alone
is sometimes not enough when folks are committing their hard work and trying
to make long
term business plans.
I think my proposal is pretty much how
we have already been operating, except that I think moving forward we need
to
do more "prep work" in side
branches, before committing to a release.
Here is what the current (general) charter
says:
<quote>
The Committers of a Project or component
decide which changes may be committed to the master code base of a Project
or
component respectively. The PMC defines
the decision process, but that process must include the ability for Committers
to veto the change. The decision process
employed may change with the phase of development. Common decision
processes
include:
* Retroactive - changes
are proactively made by Committers but can be vetoed by a single Committer.
* Proactive - for efficiency,
some code changes from some contributors (e.g. feature additions, bug fixes)
may be
approved in advance, or
approved in principle based on an outline of the work, in which case they
may be committed
first and changed as needed,
with conflicts resolved by majority vote of the Committers of the Project
or component,
as applicable.
* Three Positive - No
code is committed without a vote; three +1 ('yes' votes) with no -1 ('no'
votes or vetoes) are
needed to approve a code
change.
Vetoes must be followed by an explanation
for the veto within 24 hours or the veto becomes invalid. All votes are
conducted via the developer mailing
list associated with the Project or component. Special rules may be established
by
the PMC for Projects or components with
fewer than three Committers.
</quote>
Here is the specification I am proposing,
that I think covers our project in more explicit terms:
Process of changes to the master code
base [1]:
Changes that do not require extra processes
or voting (that is, they are approved "in advance").
Bug fixes,
java doc and JUnit tests can all be committed to the forward (head) stream.
Feature
requests, if simple additions, that do not increase dependancies, or require
changes
in APIs.
But, any new features that involve API or SPI, should only be done as "
official API". We don't
want to
add to our "API debt".
Any evolution
of an API, as long as the API is evolved in a source and binary
compatible
way.
Changes that do require a concrete proposal
[2], review and prior agreement [3] of component members:
A change
in internal non-API that is clearly identified in "usage reports"
as being used by adopters.
Any such
proposed changes need approval of the components committers, so that adopters
can anticipate
and minimize
disruption.
A new API.
The main criteria here is if it meets "API Quality guidelines"
as described in the Eclipse
Development Process
and allows
for later API
evolution.
The committers
for a component (and their clients) are the primary stake holders, and
thus is their responsibility
to
propose and decide API and ensure its quality. But, it should be developed
Promotion
of provisional API. While final decision is up to committers of a component
(and follows normal, "new API" guidelines
above,
the type of criteria here the PMC requires is that
1)
adopters can move from the provisional API with no churn (or, minimal,
with well documented migration steps) and
2) that by moving to the new official API, then "that
is it", it meets clients/adopters needs and there would not be
additional required migration later on.
[1] Master code base means the "head"
stream, to be released for build, milestones, and the release itself.
Committers can do what they want in side branches
(within, of course, the bounds of the project and Eclipse Foundation rules).
[2] By "concrete proposal"
is meant at least a short description of the "problem"
and "how solved" and preferably
the "ready-to-go-code" that
has been developed in a side branch, where it can be reviewed. All
"new work" proposed must fit the
scope of the charter of WTP and the
themes approved by the PMC for a given release
[3] Prior agreement means prior to committing
to head, or the release. A simple vote on developer mailing lists
is good if its "controversial",
or if it is considered "obviously agreed to" then formal voting
record is not needed, but,
would be subject to retroactive "veto"
if later found objectionable by a committer to a component. In the event
of disagreement
between committers, the PMC can arbitrate
a solution (which normally will strive to satisfy all requests, but, may
vary priority, schedule,
or exactly which release a change occurs
in).
Proposed Component Teams
Along with a being more specific about
how components decides their code changes, plans, etc. I think we need
to be clearer
on what the WTP components are.
"Component" is used in many
ways, so for the purposes here, it means a "Component Team",
which is responsible for one or more
components of code (or, bugzilla or
cvs components).
Here's a "picture" of the
organization we will have during WTP 2.0 development (numbers are approximate,
I need to double check
the latest "committers spread sheet").
Webtools (WST and JST) 23
IBM 14
BEA
3
Turkcell 1
Eteration 2
JBoss 1
SAS
1
Oracle 1
Dali: 11
Oracle: 6
Versant: 3
BEA
1
JBoss 1
JSF: 5
Oracle: 4
Sybase 1
Page Editor (proposed) 5
Oracle: 2
Sybase: 3
ATF: 5
IBM: 5
I think we should be explicit, that
Dali (JPA), JSF, Page Editor, and ATF, will remain being their own component
teams, for
decision making, planning, etc. as well
as them "voting in" their own future committers that they would
find valuable. That is,
if/when they graduate incubation, and
if/when joint WTP, they would join as their own WTP Component Team, in
the sense of this document.
But, I think WST and JST are "too
big" for efficient, agile development by Component Teams.
I suggest WTP consist of the following
Component Teams.
Common (Component Team that works on
current WST and JST Common component features)
Server (Component Team that works on
current WST and JST Server component features)
Database (RDB)
SSE, XML, DTD, _javascript_ CSS, HTML,
JSP, XSD
Web Services and WSDL (Component Team
that works on current WST and JST Server component features)
Web Projects (Component Team that works
on current WST and JST Project models, refactoring, etc)
JEE and EJB2 (Component Team that works
on current JST J2EE and EJB)
I think the current WST and JST code
plugins and current list of 23 or so committers can all be divided up in
some pretty obvious ways, and component leads nominated where its not obvious.
(Note, many current committers would
belong to more than one component, depending on what they desire and what
they've been working on, and suspect in nearly all cases,
we'd easily have at least 3, the "minimum"
number needed to conduct votes, etc.)
So, the Component Teams would be responsible
for their own "code changes" (per PMC guidelines) as well as
voting in new committers.
There's no great rush, but eventually
I'd assume this would translate into CVS access as well .. my main concern
is simply having a better handle over
who votes on code changes, and who votes
in new committers.
Also note, I propose, a committer to
any Component Team would "automatically" become a committer to
the website and the releng components.
Still to do: should list features/plugins
explicitly, and, I'll make my best guess on proposed members for each Component
Team.
Again, my goal is not to change anything
that anyone current does, or rights they have, but simply to crisp-up what
is basically our
undocumented processes and organization.
