|
Dmitry,
Your opinion is definitely not dumb, but I think that it is
neglecting an important aspect of why we need specification
documents and processes. It's not just about the collaboration and
efficiency at the level of each projects and its contributors.
There is also a requirement for formal engagement by the
corporations who own the patents. I am certainly open to ideas,
but I don't see how we get to the necessary IP flows without this
special project type and the creation of specification documents.
There are also behavioral aspects to the specifications that
typically don't get captured by API documentation. And there is
also the broader case where the Eclipse Foundation has potential
use cases for specifying data formats and protocols.
Anyways, not a dumb idea, but I don't see how we satisfy the
requirement for clean IP/patent flows using your approach. I would
be interested if anyone has an idea which would prove me wrong.
On 2018-06-04 10:21 AM, Dmitry Kornilov wrote:
There are too many types projects and too many
requirements. The process is confusing and requires a lot of
collaboration between projects teams. Collaboration is slow. I
have concerns about this model efficiency. I think that the
model must be as simple as possible.
I see that it’s been discussed and maybe my opinion is dumb,
but I don’t think that we need Specification projects. I think
that specs, API and TCK should be prepared by API project team.
Possibly the problems can be solved without creating the special
project type by modifying EDP and introducing some special
committers groups. Also, I am not sure that we need
specification documents at all. Properly documented API + TCK is
the specification.
Considering above, the scenario in Ivar’s email turns into:
The JAX-RS API Project
1. Decides to extract the best parts from the implementations
and produces a standard API for them.
2. Submits JAX-RS 3.0 for release review
a.
Project gets reviewed by PMC
b.
Project get reviewed by the Spec Committee
3. JAX-RS 3.0 is released
Maybe it makes sense splitting #2 to two reviews: preliminary
and final.
Thanks,
Dmitry
Hi,
I think we are confused since we are so used
to thinking "spec first", while we now should be
thinking "code first".
In the spec-first approach, it makes perfect
sense to group the API with the spec.
But when we turn around to code-first, I
think they should/must be separated.
Consider the following scenario
for a code-first approach:
Let's say Apache CXF has some cool features
that partly overlap with some features of RESTEasy.
Jersey may or may not have these features.
The JAX-RS API Project
1. Decides to extract the best parts from
the implementations and produce a standard API for them.
2. Release JAX-RS 3.0
3. Propose to the Jakarta EE Specification
Committee to standardize through Jakarta EE
a. A EE4J project (such as JAX-RS API
project) would go through the EE4J PMC
b. A standalone Eclipse Foundation API
project would go through their PMC
c. A project outside the Eclipse
Foundation (e.g. Bean Validation) would go through their
equivalent to the PMC
The Jakarta EE Specification
Committee
1. Approves the suggestion (or suggest
changes or decline...)
2. If approved, mandate the Jakarta EE Spec
project for JAX-RS to produce the specification
The Jakarta EE JAX-RS
Specification Project
1. Produce the specification document which
includes:
a. A human readable description of the
API with references to the API JavaDoc
b. Define what MUST, SHOULD, COULD,
SHOULD NOT etc. be implemented in order to comply with
the specification
c. Assertions backing up the MUSTs,
SHOULDs, COULDs and SHOULD NOTs on an agreed up format
to form the basis by the TCK
The JAX-RS TCK Project
1. Use the assertions from the spec to
create/update the JAX-RS TCK
2. Seek approval that the TCK does what it
is supposed to from the Jakarta EE Specification
Committee
The Implementation projects (may
or may not be Eclipse projects)
1. Adjust their implementations to implement
the API
2. Test their implementation against the TCK
Whether, or not, JAX-RS 3.0 should be a part
of Jakarta EE X is up to the platform
project/Specification Committee to decide.
Does it make sense, or am I way off?
Ivar
I'm
starting to become concerned/confused about this as
well.
I think we were previously expecting that a
specification project would manage the specification
document, the source code for the API classes, and
the source code for the TCK. Assuming we need
special rules for specification projects, do we
really want those special rules to apply to the API
and TCK, which after all are just source code
projects?
The API classes are hard because they mix
specification with (varying amounts of)
implementation. But none of the IP issues for the
spec apply to the TCK, right? Maybe the TCKs should
be in separate code projects that follow the normal
EDP rules?
Steve
Millidge (Payara) wrote on 05/29/18 02:28 AM:
I share
Ivar’s concerns here.
I am also
confused by the definitions and the
developing special nature of this
specification project and how that is going
to work in practice with the standard
Eclipse API and TCK projects that will live
under the EE4J PMC.
So forgive
me if I get this wrong are we saying;
Specification
Project -> creates Document,
Specification Implementation, TCK?
A normal
EE4J project under the PMC creates just the
API?
Or are we
saying Specification Project just creates
the Document and must ensure there is a TCK,
API and Specification Implementation before
the Specification can be released.
Also given
the document just essentially describes the
API and behaviours under the API how is the
Specification project going to
control/influence the work of the API
project working under usual EDP rules of
engagement?
I’m afraid
I’m a fairly practical person and I am now
confused about practicalities of who is
doing what.
Thanks
Steve
From: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
<jakarta.ee-spec.committee-bounces@xxxxxxxxxxx>
On Behalf Of Ivar Grimstad
Sent: 25 May 2018 18:02
To: Jakarta specification
committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
Subject: Re:
[jakarta.ee-spec.committee] Recent Edits
Hi,
I think we should tread
carefully here so we don't become a
corporate club where you have to pay to
play, which is exactly what critical
voices in the community have warned
against.
I can understand the
reasoning behind the wish for a company to
being able to replace a committer on a
project. But at the same time, if a
corporation is allowed to do that it
should probably apply to individual
committers as well. E.g. someone that
wants to resign from the project for some
reason and give the reigns over to someone
else. By doing so, we are going against
the Open Source Rules of Engagement
defined by the EDP (https://www.eclipse.org/projects/dev_process/development_process.php#2_1_Open_Source_Rules_of_Engagement).
So be prepared for a storm! This will not
be well received by our critics...
On Fri, May 25,
2018 at 4:02 AM, Mike Milinkovich
<mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
wrote:
Richard,
We (the EMO) are thinking
about this, and how we could
make it work if we decide it
is the right thing to do.
Two points:
- I find
it surprising that the
small-company guy is arguing
for the corporate approach.
I realize that this is quite
typical in standards
organizations. Is everyone
else on the list comfortable
that this explicit corporate
presence is desirable?
Well, like any
other organization that is
dedicating resources to the effort
of Jakarta EE, we (Tomitribe) want
to ensure that we benefit from
that investment. When an engineer
works on a Jakarta EE
specification, it costs the
company money in terms of salary,
but that's not all. Often the
employee will rely on other
resources in the company such as
people or equipment. None of this
is free. I am a committer for the
EJB Specification project.
Tomitribe is counting on me to
make valuable contributions that
will result in a stronger
specification which means a
healthier market for Tomitribe and
everyone else. If I were to leave
Tomitribe, they would want to
protect that investment in time
and energy by replacing me with
another qualified individual. My
time contributing to
specifications is not a sunk cost.
When a
company's representative is added
to a Specification Project its
done on merit, just like adding an
individual. It's expected that
the company can contribute,
regardless of the representative,
real value to the definition of
the specification. The company
has to have demonstrated expertise
in the area concerned.
- I hope
that you are prepared to
argue for this when our
friends like Markus Karg
take us to task for being a
bunch of corporate shills ;)
-
On 2018-05-24 10:58 AM,
Richard Monson-Haefel
wrote:
Thanks,
Mike.
At
this time committers
are defined as
"individuals." I would
like to see that
expanded to include
"representatives". A
representative is the
role of committer in a
project that can be
occupied by an
employee of the
company that is
represented. Not sure
if that makes sense or
not. You can be
nominated and elected
as a committer to a
project as either an
individual or as a
representative of a
company. If an
elected representative
leaves the company
they were elected to
represent, the company
has the option of
appointing a new
representative. If
the project wishes to
also keep the original
representative they
can be re-nominated
and elected as an
individual or as a
representative of a
different company. A
representative committer is
equal in all other
ways to an individual
committer.
On
Thu, May 24, 2018 at
4:09 AM, Mike
Milinkovich <mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx>
wrote:
Please do not
worry about how
Wayne and I get
the approvals in
place for any
necessary
process changes.
I'm confident we
can make what we
agree to happen.
Let's figure out
what the right
solution is, and
then the EMO can
figure out how
to implement it.
On 2018-05-24
1:36 AM, Richard
Monson-Haefel
wrote:
I believe
changes to the
Eclipse
Development
Process
require
approval by
the Eclipse
Board, so if a
rule change is
necessary it
would need to
be proposed to
the board.
Whether or not
an exception
can be made
for just the
EE4J Working
Group or if
the change
would need to
apply to all
Working
Groups, I do
not know. If
the rules
germane to
this issue
cannot be
changed, than
instead of a
rules change
it could be
considered a
“courtesy”
that is
commonly
extended to
companies
whose whose
employee,
elected as a
committer, has
ended their
employment
with that
company. For
example:
Project X has
10 committers
with names (A,
B, C ... J).
Committer B
worked for
ACME Company
when elected
to a
Specification
Project. When
Committer B is
nominated they
declare that
although they
are individual
they also are
an official
representative
of ACME
Company. This
proclamation
is not binding
in anyway, but
is simply
informative
part of the
nomination.
Committer B
announces that
they are
leaving the
ACME Company
to become
independent
but will sign
a new
Committers
Agreement as
an Independent
(or their new
company will
sign one) and
will stay on
Project X.
The ACME
Company makes
a request that
another
employee, Ms.
K, me
nominated as a
committer to
Project X. The
Project Lead,
as a courtesy
to the ACME
Company, can
choose to
nominate Ms.
K. The vote is
taken
according to
normal Eclipse
Development
Handbook and
Ms. K is
either elected
a committer or
not.
That's a start, but that makes it clear
we're
inventing new
rules for Spec
Projects that
are different
than any other
Eclipse
project. Is
there a better
way to
"overlay" the
Spec Project
rules on top
of the
existing
Project rules?
Richard
Monson-Haefel
wrote on
05/23/18 02:34
PM:
Good
point. Here
is a counter
proposal:
In
addition to
accepting
individuals to
a
Specification
Group, the
group lead or
the group can
nominate/elect
(or whatever)
a
representative
of an
organization.
If the
represenative
leaves that
organization,
the
organization
can nominate a
replacement
represenative.
The original
representative
can remain on
the
Specification
Group as an
individual or
perhaps
representing
some other
company, but
the company
that
originally
invested in
that
represenative
has the right
to nominate a
new
represenative.
The newly
nominated
represenative
can be subject
to a vote by
the group.
That way the
organization
that lost the
represenative
has the
oppourtunity
to maintain
its place at
the table but
is not an
automatic “pay
to play”
contributor.
I
think that
protects the
investment
made by the
organization
when it has
payed the
representative
salary and
gave that time
to the
Specification
Group without
making it a
“pay to play”
situation. So
there can be
individual
group members
and
organizational
group
members.
Richard
Monson-Haefel
wrote on
05/23/18 07:28
AM:
Depending
on the
membership
level, an
organization
should
automatically
get a seat on
any
specification
project they
want but
should
excercise
self-restraint
to focus on
those
specifications
germane to
their
products.
Why, for
example,
should a
company become
a strategic
member if it
cannot have a
seat at the
table?
So,
if you pay
then you can
play?
What about the
people who
don't pay?
At the JCP,
the Spec Lead
would decide
whether an
expert was
qualified to
be on the
expert group.
We ran into
quite a few
people who
clearly only
wanted to be
on an expert
group so that
they could add
that to their
resume. We
rejected many
of those
people.
If "expert
group members"
are Committers
on a Spec
Project, who
qualifies the
Committers?
After the
Project is
created, I
assume it
would be the
Project Lead.
Before the
Project is
created, is it
just the
person who
proposes the
project? And
you're
suggesting
that the
Project Lead
would have no
choice but to
accept any
Committer
proposed by a
paying Member?
|
