Re: [incubation] Updating an existing "build and test dependencies" umbr

[Ed Willink <ed.willink@xxxxxxxxx>]

Hi

On 30/09/2020 06:18, Ed Merks wrote:
> I would personally have a canary if I had to report and track all the 
> Maven plugins used by all my builds.  visit 
> https://www.eclipse.org/mailman/listinfo/incubation 

Indeed.

I see four kinds of code.

a) primary source code, e.g. a copied and pasted algorithm - obviously 
needs a CQ

b) indirect application code, e.g. libraries executed by users of your 
code as a consequence of the overall OSGI installation, arguably these 
need a piggy CQ, although the irritation that I caused by raising many 
piggy back CQs, for the various versions of Guava that my users might be 
using from Orbit, just adds to the argument. Fortunately we now have 
auto-piggy-back CQs.

c) secondary test code, e.g a test case contributed by a user and 
committed to an EF GIT repo. Since this is not deliverable, I consider a 
CLA Bugzilla authorisation adequate.

d) indirect build/test/install code seems to cover your activity of what 
happens while building. This is not in your GIT and is not delivered to 
your customer, so no CQ required.

It may help to consider what the real problem CQs avoid is.

The worst scenario is that the rightful author of some mistakenly copied 
code issues a take down instruction to the EF. This could be massively 
disruptive to comply with and could make some or all of Eclipse 
unavailable to users for days while a workaround is arranged.

Beyond that it may be necessary to clean the offending code from all 
archives and distributions. Again a disruptive nightmare.

Something that is not in an EF-hosted GIT, archive or distribution is 
not really a problem. Just a nuisance if you have to rework your build 
procedures.

        Regards

            Ed Willink





--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus