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
[email protected]
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
EclipseCon France 2016 <http://www.eclipsecon.org/france2016>
_______________________________________________
modeling-pmc mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
_______________________________________________
modeling-pmc mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/modeling-pmc
