Re: [modeling-pmc] Too Many Guava CQs

[Ed Merks <ed.merks@xxxxxxxxx>]

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