To all members of the JSR 343 Expert Group. (This email is being sent to jsr343-experts_at_jms-spec.java.net which is
forwarded to the user alias).
Thank you all for joining the JSR 343 Expert Group, and, once again, welcome!
Although there are still two or three more applications being processed, I think we've now got enough members, and
enough organisations represented, to reach the "critical mass" which will allow us to start.
In this email I'd like to introduce the expert group, invite you to send two emails introducing yourself and outlining
your own priorities, and make some general proposals about how I think we should work.
I look forward to working with you all,
Nigel
The Expert Group
----------------
Here is the current list of members:
Nigel Deakin, Oracle, Specification lead
Tom Barnes, Oracle
Reza Rahman, Caucho
Clebert Suconic, Red Hat
Bruce Snyder, VMware
Adrian Johnson, TIBCO
Shivajee Samdarshi, TIBCO
Adam Bien, individual
Masoud Kakali, individual
You can see the offical list, including email addresses and phone numbers at
http://jcp.org/en/eg/view?id=343
(you'll need to login to jcp.org to see this)
You will note that we have two representatives from Oracle and from TIBCO. Please note that each organisation still has
only one vote on formal business. In general I'm supposed to restrict each organisation to a single representative.
However here in Oracle we decided that we were such a large organisation, with several Java EE implementations and even
more JMS providers, that we needed to send two representatives to ensure adequate representation. It's therefore only
fair that I extend the same courtesy to other organisations who are very large, or who have multiple JMS providers, and
feel that they need to provide more than one representative. I'll need to ask organisations with two delegates to tell
me who is their primary representative.
To get things started
---------------------
To get things started, I'd like to invite you all to write *two* emails:
* introduce yourself (to jsr-343-eg_at_jcp.org)
* state your priorities (to jsr343-experts_at_jms-spec.java.net) (by 3 Jun 2011 if possible)
Introduce yourself
------------------
If you wish, please send an email to the private email list jsr-343-eg_at_jcp.org), introducing yourself? Although you
provided a short biography when you applied to join the group, I don't think this information is available to others. So
please share some information about you and your organisation. Please say where you live or work. I'll do the same. I
suggest emails that contain vaguely personal information like this are best kept on the private alias jsr-343-eg_at_jcp.org.
State your priorities
---------------------
In a separate email, please write a few words about what you'd like to see in JMS 2.0 and post it to the public expert
group alias jsr343-experts_at_jms-spec.java.net . I've spoken to several of you directly, asking what your priorities are
for changes to the JMS spec. Here is a first opportunity to share your views with other expert group members. If
possible, please reply by Friday 3rd June 2011. This list is archived, so latecomers to the EG can read it when they join.
NOTE: Please use the subject line "JMS 2.0 Priorities: Proposal from <your name>. Other members can then reply and ask
questions to clarify their understanding, without anyone getting confused about whose proposals we are discussing.
When we've received proposals from everyone I'll combine them into a single list, and will then start a separate email
thread to discuss each.
Rights and Responsibilities
---------------------------
As spec lead I see my role, and responsibility, is to lead the expert group and make sure we work efficiently towards
our agreed goal of developing version 2.0 of the JMS specification. I use the word "efficiently" because I appreciate
that EG members are busy people who don't want to waste time on irrelevant digressions or going over the same ground
repeatedly.
So here are a few guidelines I'd like to suggest we follow, based on lessons learned from other expert groups.
First of all, I'd like to suggest some rights and responsibilities for the JMS 343 spec lead and for expert group members:
*** Your rights as a JSR 343 expert group member:
- timely response to emails
- the issues you raise get dealt with and not fall on the floor
- be informed of schedule milestones and release plans as soon as possible.
- have your spec lead be fully allocated to leading the EG as their primary official job responsibility,
on paper and in practice.
- have expectations set realistically, for example, the EG needs to be made aware that the JCP process can take a long
time, months even, between when the actual spec discussion work is done, and when it is final. During that time, we're
going through JCP process steps, working on the TCK and polishing the RI, writing the documentation, integrating it into
the release vehicle, and qualifying it with third party products.
*** Your responsibilities as a JSR 343 expert group member:
- be active in email discussions
- On the rare occasions when we specifically ask for a VOTE,
such as whether or not we declare that we've hit a JCP milestone,
cast one.
- conduct all email in a professional manner
- follow the email discussion guidelines provided in this message
- stay within the scope of the JSR
- respect the spec lead's final call on the schedule for the JSR.
*** My rights as the specification lead:
- The ability to make the final call on the schedule for the JSR,
after sincerely considering EG input.
- The ability to make executive decisions to settle deadlocks
- The ability to shut down threads that are digressions.
*** My responsibilities as the specification lead:
- All new discussion threads receive a response within two days from me,
barring planned and unplanned absences.
- All discussion threads are managed.
If appropriate they are associated with an issue-tracker issue.
- to see that each discussion thread is summarized and labeled as CLOSED when the discussion is resolved.
- keep the spec document up-to-date as issues are resolved
- coordinate the work of the JSR with the development of the TCK and Reference Implementation
- to be available to expert group members by telephone to discuss any matter
Email lists
-----------
Our main mechanism of communication will be email. Since revising the JMS spec is a complex technical topic and there
will be many emails, and I'm keen to ensure we work efficiently, I'd like to propose a number of guidelines on our use
of email.
* Please conduct technical discussions on the public alias jsr343-experts_at_jms-spec.java.net as much as possible
* Please keep discussions involving personal information, contact details, phone numbers, and anything else you'd like
to keep confidential to the EG on the private alias jsr-343-eg_at_jcp.org. Note that messages to that list are not achived.
Conference calls
----------------
I plan to organise a conference call soon very soon to allow us to introduce ourselves, hear each other's voices and to
chat informally. I propose we have a series of regular calls during the early stages to help us get started, and after a
while change to having them only when we feel we need them.
Email thread management
-----------------------
* Please confine technical discussions on a given topic to a specific email thread with a specific subject line. The
spec lead will normally start new discussion threads, manage the discussion, seek agreement (with informal votes when
needed), summary any conclusions, and eventually close the thread.
* If you want to originate a thread, send it to the EG prefixed by [NEW] in the subject line. If the spec lead sees the
need for an issue tracker issue (and another EG member hasn't created one already), they will put it in the issue
tracker. The spec lead will then change the subject of the email to begin with [JMS20-<nn>], where NN is the issue
number), and discussion will continue on that thread, NOT the thread with [NEW] in the title.
* Put [ADMIN] at the start of the subject line for all schedule and administrative related emails.
* Please send all mail as plain text, not HTML, and if you possibly can, avoid top-posting (e.g. place your comment
beneath the quoted text you are commenting on).
* If this doesn't work, we'll try something else. I'm open to other suggestions about how to best conduct the EG
discussions over email.
JIRA
----
We have a JIRA issue tracker. I see this as having at least two distinct roles:
* All proposals to change the Spec will have a corresponding JIRA issue. These can be created by the expert group member
proposing the change or by the spec lead if needed. I see this as being particularly useful as a way of making sure we
don't lose track of the myriad changes - some small, some larger - that members may want to propose. I'll develop (in
conjunction with the EG) a suitable lifecycle for these issues to track its acceptance for 2.0, its deferral for 2.1, or
its rejection.
EG members and users may add comments to these issues, though substantive discussion will take place by email (on an
appropriate thread) and any decisions (e.g. to reject or modify the proposal) recorded in the issue.
We will also use these issues to track progress incorporating any changes in the TCK and RI.
* Users are invited to create new issues as a way of proposing spec changes to the expert group. The spec lead will
check whether this is a duplicate of some other issue, or can be merged with another issue, and close it if necessary.
Anyone (including expert group members) may make comments, particularly to discuss the issue with the submitter, though
any substantive discussion will take place by email (on an appropriate thread).
Reference implementation and TCK
--------------------------------
JMS 2.0 will need a Reference Implementation (RI) and Technology Compatibility Kit (TCK). The JCP 2 process
(http://jcp.org/en/procedures/jcp2) states that these are the responsibility of the spec lead's company or organisation.
I can confirm that Oracle will take responsibility for this.
Oracle will deliver the RI through the Open Message Queue project, http://mq.java.net. This is the JMS provider in
GlassFish Server, Open Source Edition, which is itself the RI for Java EE 6 and will be the RI for Java EE 7.
JMS 2.0 will also need a Tecknology Compatibility Kit (TCK). This is "a suite of tests, tools and documentation that
determines whether or not a product complies with a particular Java™ technology specification." The TCK will be
developed by Oracle internally.
The Spec Document itself
------------------------
The JMS 2.0 specification will consist of an updated pdf document and a set of javadocs. I have primary responsibility
for updating these, ensuring that they are consistent, properly formatted, etc, and for maintaining an official change
log which records all changes from the existing specification.
I plan to maintain working draft versions of both on the java.net project.
Provisional schedule
--------------------
The milestones proposed in the JSR proposal were:
Expert Group Formation: March 2011
Early Draft: Q3 2011
Public Review: Q1 2012
Final Release: Q3 2012
I'd now like to start turning this into a more detailed schedule. Here's a first suggestion (nothing here is
definitive). Since it's taken longer to get started than I had hoped I've slipped the Early Draft date by one month but
kept the other dates. The final release date needs to stay aligned with the Java EE 7 final release date.
End May: Formation of Expert Group
(5 month period to prepare early draft)
End Oct 2011: Start of Early Draft Review
(1 month period for early draft review. During this period the EG may update the draft.
During the final week of this period, the draft is frozen and
the EG conducts a Public Draft Specification Approval Ballot to decide if the draft may proceed)
End Nov 2011: End of Early Draft Review (allows a 90 day review period)
(4 month period to prepare public draft)
End Mar 2012: Start of Public Review
(1 month period for public review. During this period the EG may update the draft.
During the final week of this period, the draft is frozen and the EG conducts
a Public Draft Specification Approval Ballot to decide if the draft may proceed)
End Apr 2012: End of Public Review
(4 month period for completion of RI and TCK. If this uncovers deficiencies in the spec,
the spec will be updated. Comments will also be considered)
Mid Sept 2012: Start of Final Approval Ballot
(Period for voting by the EC)
End Sept 2012: End of Final Approval Ballot, Final Release
(The formal JCP process is described at http://jcp.org/en/procedures/jcp2)