[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
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