Wayne,
No, of course you didn't tell anyone to do this. That's why I
find it so frustrating. In any case, I won't discuss the issue
further. The 15.0.0 is approved and that's sufficient.
On 02.06.2016 16:50, Wayne Beaton
wrote:
Ed,
I've been staring at a lot of IP Logs over the past few weeks,
so please forgive me for not remembering the specific catalyst
of this discussion. AFAIK, I never told anybody that they needed
to create a bajillion piggyback CQs. Feel free to remind me.
As I recall, I did notice that the QVT-OCL project was actively
distributing Guava 15 and recommend that they create just one CQ
for that specific version.
Wayne
On 02/06/16 03:25 AM, Ed Merks wrote:
Wayne,
As you can see below, this is all very academic, and I don't
care to pursue an academic exercise. Please reduce the number
of required CQs to just the version on the train so that the
view passes and is complete.
Regards,
Ed
On 02.06.2016 09:13, Ed Willink wrote:
Hi Ed
I don't think that you should need to approve any of the extra
Guava piggy back CQs.
Each has a primary CQ satisfying the Eclipse requirement for
IP diligence.
OCL and QVTd have Guava 10 PiggyBack CQs satisfying the
requirement for per-project Orbit traceability.
The additional pig-sty of CGs seems to be a complete nonsense.
It is required because the IP policy fails to accommodate the
reality of rapid version change by an Orbit component.
If the pig-sty is required, as indicated by Sharon, then the
CQs should be auto-approved (albeit manually) by the IP team.
Better the IP team should recognize that they are pointless
and auto-generate the pig-sty for all projects. Or perhaps
Guava new-version primary CQs should be designated as NV CQs
of the original version so that a PB CQ of a particular
version inherits the full chain of NV CQs.
At the moment it seems that the IP team is creating a dilemma.
If I do nothing ...
QVTd will fail its release review shortly before the
Simulataneous release. As a +3 incubation project, exclusion
of QVTd will not affect anyone, but a post RC5 respin will be
required delaying the Neon release.
OCL will similarly fail and a few projects will have to rework
post RC5 to ensure that OCL is a truly optional dependency. A
few projects will be unable to rework in the timescale and
will have to follow OCL out of the train. An unrealistic
disruption for a purely academic review failure.
Alternatively I withdraw the CQs and knowingly violate the
clearly expressed requirement for these CQs. If I update the
review documentation to indicate that I know of this academic
IP violation, the reviews should fail.
Without the pig-sty of CQs, it seems that either I must
provide knowingly false review documentation, or the IP team
must revise the IP policy for Guava.
Regards
Ed Willink
On 02/06/2016 07:00, Ed Merks wrote:
Wayne,
While I see the technical point Ed Willink is making about
which version of Guava he should PB CQ, given that ranges
(or the unbounded range) are involved in the requirement and
at install/runtime could be installed/wired with any
version, I feel it's splitting hairs in a way that creates
extra work for everyone involved to open a PB CQ for every
version of Guava known to mankind. The 15.0 version is the
one on the Neon train (and is approved), and I approved the
19.0 (latest) version. I don't see all other modeling
projects creating a flood of PB CQs in these cases, nor to I
want to see that. It seems superfluous, so I'll draw the
line with this workflow based on the expectation that each
project will file a single PB CQ a given library they are
using for their release. Technically, looking at the OCL
repo, they are not actually redistributing Guava in the
repository, but the project is on the train, so it will
generally install with Guava 15.0.0. Approving that CQ is
sufficient from my point of view.
Regards,
Ed
-----
No virus found in this message.
Checked by AVG - www.avg.com
Version: 2016.0.7598 / Virus Database: 4591/12342 - Release
Date: 06/01/16
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or
unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
--
Wayne Beaton
@waynebeaton
The Eclipse Foundation
_______________________________________________
modeling-pmc mailing list
modeling-pmc@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
|