I created https://issues.apache.org/jira/browse/INFRA-23111 <https://issues.apache.org/jira/browse/INFRA-23111> to allow disabling dependabot for repos. Konrad
> On 7. Apr 2022, at 11:51, Konrad Windszus <[email protected]> wrote: > > I fully agree here. I don’t think dependabot can be controlled via .asf.yaml > yet, so for now we need to disable manually per repo… > >> Am 07.04.2022 um 10:18 schrieb Stefan Seifert >> <[email protected]>: >> >> i agree with robert that probably for most of our modules dependabot is not >> helpful (exceptions are the maven plugins and that part of sling starter >> which controls which bundles are really deployed at runtime). in our OSGi >> world, the dependency just defines the contract against which >> package/interface version we compile against. >> >> if possible it would be helpful to disable dependabot for the majority of >> git repos to reduce noice, and avoid accidentally raising a dependency where >> it's not required to. >> >> stefan >> >> >>> -----Original Message----- >>> From: Eric Norman <[email protected]> >>> Sent: Wednesday, April 6, 2022 8:35 PM >>> To: Sling Developers List <[email protected]> >>> Subject: Re: Fwd: [NOTICE] Dependabot Updates enabled for all projects >>> >>> Perhaps some analysis of whether bumping the dependency version changes the >>> generated Import-Package instruction can provide some insight regarding the >>> compatibility. If the new version of the dependency only has changes in >>> packages that we are not directly using then it should be safeish to >>> switch. >>> >>> I would also support changing our process to depend on the lowest possible >>> version that doesn't have known vulnerabilities. Perhaps with some >>> announcement if there are known compatibility issues. >>> >>> Regards, >>> -Eric >
