Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[wtp-pmc] Agenda for WTP PMC telecon for Tuesday, September 5, 2006

Call info:
  • Tollfree in the US: 866-214-3176
  • Alternate: 404-827-9098
  • Access code: 8870689#
Call Time: 7am PDT / 10am EDT
Regrets: Tim Wagner, Arthur Ryman, Jochen Krause
  • Community [Tim, via email]
    • EclipseWorld -- this week! Hope to hear "trip reports" next week.
    • EclipseCon – no word yet on EclipseZilla
             plan is to wait for EclipseZilla to be set up before doing the CFP, but feel free to let people know to start thinking about tutorials
    • Process issues [Tim, via email]
      • had IP discussions with Janet and Bob about ATF requests
      • Enhancing component-level decision making --  introduction of proposal in two parts (see below) (David)
        • Anticipate discussion and PMC vote by 9/12 (feel free to send comments/discussion in advance).
        • On-going: the search for "web master" continues
        • Congratulations and thanks to Jeffrey Liu
          • Potential opportunities for contribution:
            • Performance Engineer
            • Automated Tests
            • Release Engineer
            • API Scans, etc
            • Requirements and 2.0 Planning (Jochen)
              • ongoing ... expect mid September activity
              • 1.5.1 and 2.0 Status (David)
                • 1.5.1
                  • now in "component lead review" level,
                  • next week, starts PMC level review
                  • 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:

                    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

                        * 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.

                    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.

Back to the top