|Re: [incubation] Updating an existing "build and test dependencies" umbrella CQ|
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
Back to the top