Re: [jakarta.ee-spec.committee] TCK Projects vs Spec Projects

["Kevin Sutter" <sutter@xxxxxxxxxx>]

I think Bill is accurate.  We had
decided that the TCK needed to be separate from the Spec due to the "Working
Group" Participation Agreement that would be necessary for the Specs
(due to the necessary IP flows).  We didn't want to require TCK developers
to be bound to this same "Working Group" Participation Agreement.

Aside...  As I have discussed this
with IBM colleagues over the last couple of months, they have questioned
why this was really necessary.  These are seasoned Eclipse developers
in the community.  And, they were questioning why a special contributor's
agreement was necessary over and above the standard ECA.  So, maybe
this is a question that we need to revisit.

---------------------------------------------------
Kevin Sutter 
STSM, MicroProfile and Java EE architect
e-mail:  sutter@xxxxxxxxxx     Twitter:  @kwsutter
phone: tl-553-3620 (office), 507-253-3620 (office)    
LinkedIn: https://www.linkedin.com/in/kevinwsutter

jakarta.ee-spec.committee-bounces@xxxxxxxxxxx wrote
on 09/06/2018 06:45:55 AM:

> From: Ivar Grimstad <ivar.grimstad@xxxxxxxxx>
> To: Jakarta specification committee <jakarta.ee-spec.committee@xxxxxxxxxxx>
> Date: 09/06/2018 06:46 AM
> Subject: Re: [jakarta.ee-spec.committee] TCK
Projects vs Spec Projects
> Sent by: jakarta.ee-spec.committee-bounces@xxxxxxxxxxx
> 
> I can't speak for how it works in larger organizations, but for 
> JSR371 it is the same people involved. 
> The way we work with tags in the asciidoc spec
documents that is 
> used to generate TCK test coverage, keeping them together makes life
> much easier. 
> Would it be possible to allow for both models?
Or do we need to 
> specify it that detailed?
> 
> Ivar
> 
> On Thu, Sep 6, 2018 at 1:36 PM Mike Milinkovich <
> mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx> wrote:
> On 2018-09-05 6:17 PM, Bill Shannon wrote:
> > In a previous discussion, perhaps in the Steering Committee,
> > I believe we came to the conclusion that the TCK needed to be
> > in a separate project from the spec.  I think this was due
to
> > some IP or licensing issue, perhaps because Spec Projects would
> > operate under different IP rules that we didn't want to apply
to
> > code projects such as the TCK.
> >
> > Does anyone remember the exact rationale for this required
> > separation between TCK Projects and Spec Projects?
> 
> Bill,
> 
> Wayne and I discussed this very topic yesterday.
> 
> Given that the TCK is a 1:1 with the Specification and the API, and
that 
> all three artifacts need to be released at the same time, we're thinking
> that they should all be managed as one project.
> 
> Our single reservation is that AIUI the people who work on the TCK
and 
> the people who work on the spec document are often different. Is that
> actually correct? We typically have a single committer list for everyone
> involved in all aspects of a single project. If we need to manage
> separate lists of committers between the spec doc/API/TCK that may
drive 
> us towards a different solution.
> 
> Thoughts? Comments?
> 
> -- 
> Mike Milinkovich
> mike.milinkovich@xxxxxxxxxxxxxxxxxxxxxx
> (m) +1.613.220.3223
> 
> 
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
> 
> _______________________________________________
> jakarta.ee-spec.committee mailing list
> jakarta.ee-spec.committee@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit
> https://dev.eclipse.org/mailman/listinfo/jakarta.ee-spec.committee
> -- 
> Java Champion, JCP EC/EG Member, EE4J PMC, JUG
Leader
> _______________________________________________
> jakarta.ee-spec.committee mailing list
> jakarta.ee-spec.committee@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or 
> unsubscribe from this list, visit
> https://urldefense.proofpoint.com/v2/url?
> u=https-3A__dev.eclipse.org_mailman_listinfo_jakarta.ee-2Dspec.committee&d=DwICAg&c=jf_iaSHvJObTbx-
> siA1ZOg&r=R9dtOS3afYnRUmu_zogmh0VnVYl2tse_V7QBUA9yr_4&m=wUWaeRnTMhpteEBzp0v4mAONMYw3qIe9oCaaH9JfL1M&s=LfIhNM81zlDqwtsl9bhXsOmoGyRGSHdIwbH3-
> NeUR0o&e=