Re: [all] stopping dependabot and security analyses on dormant components
Le 03/10/2023 à 20:18, Bruno Kinoshita a écrit : Same for me, I prefer to know ahead of time if there are any issues with dependencies. But the Commons components are mostly dependency-less, we are flooded by dependabot requests to update non code related dependencies (Maven plugins, GitHub actions) for non critical purposes. It would be better to have such notifications for CVEs only. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] stopping dependabot and security analyses on dormant components
Same for me, I prefer to know ahead of time if there are any issues with dependencies. On Tue, 3 Oct 2023, 19:23 Gary Gregory, wrote: > Getting rid of this is good for dormant components ONLY IMO. > > It is definitely not a release time task for me. As an RM, I certainly > don't want to spend time doing this at release time. I want to update > dependencies as they become available to let them become part of the code > base where I can check and validate stability over time as I keep > developing and maintaining. I want to know as soon as possible if something > goes wrong, not at release time when *all i want to do* is release. > > Gary > > > > On Tue, Oct 3, 2023, 10:47 AM Emmanuel Bourg wrote: > > > Le 01/10/2023 à 14:09, sebb a écrit : > > > As the subject says: how does one stop dependabot and other analyses > > > from running on dormant components? > > > > +1 > > > > And even on all components, updating the dependencies is a release time > > task. Updating 3 times the same Maven plugins between releases is a > > waste of time. > > > > Emmanuel Bourg > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
Re: [all] stopping dependabot and security analyses on dormant components
You could try archiving the projects. That way all jobs are disabled, including dependabot. You can't push anymore, but unarchiving is just as easy as archiving. Rob On 03/10/2023 19:22, Gary Gregory wrote: Getting rid of this is good for dormant components ONLY IMO. It is definitely not a release time task for me. As an RM, I certainly don't want to spend time doing this at release time. I want to update dependencies as they become available to let them become part of the code base where I can check and validate stability over time as I keep developing and maintaining. I want to know as soon as possible if something goes wrong, not at release time when *all i want to do* is release. Gary On Tue, Oct 3, 2023, 10:47 AM Emmanuel Bourg wrote: Le 01/10/2023 à 14:09, sebb a écrit : As the subject says: how does one stop dependabot and other analyses from running on dormant components? +1 And even on all components, updating the dependencies is a release time task. Updating 3 times the same Maven plugins between releases is a waste of time. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] stopping dependabot and security analyses on dormant components
Getting rid of this is good for dormant components ONLY IMO. It is definitely not a release time task for me. As an RM, I certainly don't want to spend time doing this at release time. I want to update dependencies as they become available to let them become part of the code base where I can check and validate stability over time as I keep developing and maintaining. I want to know as soon as possible if something goes wrong, not at release time when *all i want to do* is release. Gary On Tue, Oct 3, 2023, 10:47 AM Emmanuel Bourg wrote: > Le 01/10/2023 à 14:09, sebb a écrit : > > As the subject says: how does one stop dependabot and other analyses > > from running on dormant components? > > +1 > > And even on all components, updating the dependencies is a release time > task. Updating 3 times the same Maven plugins between releases is a > waste of time. > > Emmanuel Bourg > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [all] stopping dependabot and security analyses on dormant components
On Tue, 3 Oct 2023 at 15:47, Emmanuel Bourg wrote: > > Le 01/10/2023 à 14:09, sebb a écrit : > > As the subject says: how does one stop dependabot and other analyses > > from running on dormant components? > > +1 > > And even on all components, updating the dependencies is a release time > task. Updating 3 times the same Maven plugins between releases is a > waste of time. +1000 Unfortunately it does not appear to be possible to trigger Dependabot checks manually. However, it is possible to reduce the frequency to monthly, which might reduce the churn somewhat. An alternative might be to disable the checks (e.g. by renaming the file), and re-enable with a suitable check date shortly before a release. > Emmanuel Bourg > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [all] stopping dependabot and security analyses on dormant components
Le 01/10/2023 à 14:09, sebb a écrit : As the subject says: how does one stop dependabot and other analyses from running on dormant components? +1 And even on all components, updating the dependencies is a release time task. Updating 3 times the same Maven plugins between releases is a waste of time. Emmanuel Bourg - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] pom.xml should not contain RM details
I've already made a start on that. I'm replacing the entries with comments so people know where to defined them. On Tue, 3 Oct 2023 at 12:44, Bruno Kinoshita wrote: > > Thank you Sebb and thank you Gary! > > On Tue, 3 Oct 2023 at 13:42, Gary Gregory wrote: > > > FYI, I'll do a pass over all poms and remove those properties... > > > > Gary > > > > On Mon, Oct 2, 2023, 6:58 PM sebb wrote: > > > > > As the subject says, please do not use the pom to store RM details such > > as > > > > > > commons.releaseManagerName > > > commons.releaseManagerKey > > > > > > These properties are personal to the user, and should be defined in > > > ~/.m2/settings.xml. > > > See https://commons.apache.org/proper/commons-release-plugin/index.html > > > > > > Or you can define them on the command line. > > > > > > If the RM details are stored in the pom, then it is all too easy for > > > the wrong values to be used. > > > > > > Thanks, > > > Sebb > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] pom.xml should not contain RM details
Thank you Sebb and thank you Gary! On Tue, 3 Oct 2023 at 13:42, Gary Gregory wrote: > FYI, I'll do a pass over all poms and remove those properties... > > Gary > > On Mon, Oct 2, 2023, 6:58 PM sebb wrote: > > > As the subject says, please do not use the pom to store RM details such > as > > > > commons.releaseManagerName > > commons.releaseManagerKey > > > > These properties are personal to the user, and should be defined in > > ~/.m2/settings.xml. > > See https://commons.apache.org/proper/commons-release-plugin/index.html > > > > Or you can define them on the command line. > > > > If the RM details are stored in the pom, then it is all too easy for > > the wrong values to be used. > > > > Thanks, > > Sebb > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
Re: [ALL] pom.xml should not contain RM details
FYI, I'll do a pass over all poms and remove those properties... Gary On Mon, Oct 2, 2023, 6:58 PM sebb wrote: > As the subject says, please do not use the pom to store RM details such as > > commons.releaseManagerName > commons.releaseManagerKey > > These properties are personal to the user, and should be defined in > ~/.m2/settings.xml. > See https://commons.apache.org/proper/commons-release-plugin/index.html > > Or you can define them on the command line. > > If the RM details are stored in the pom, then it is all too easy for > the wrong values to be used. > > Thanks, > Sebb > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [ALL] pom.xml should not contain RM details
On Tue, 3 Oct 2023 at 09:48, Bruno Kinoshita wrote: > > I recall seeing these properties in the commons-release-plugin docs I use > as reference whenever I need to release a component (which the last time > was a long time ago, sorry). > > The commons-release-plugin links to this page: > > https://commons.apache.org/releases/prepare.html That disagrees with the page linked at the start of the thread. > Maybe we need to update that page too to explain these properties must not > be persisted. Indeed, will do. > On Tue, 3 Oct 2023 at 10:26, sebb wrote: > > > The properties are used by the release plugin. > > > > But since they are unique to the user, they do not belong in the shared > > pom. > > > > On Tue, 3 Oct 2023 at 02:33, Phil Steitz wrote: > > > > > > +1 but why then are those properties there? > > > > > > Phil > > > > > > > On Oct 2, 2023, at 3:58 PM, sebb wrote: > > > > > > > > As the subject says, please do not use the pom to store RM details > > such as > > > > > > > > commons.releaseManagerName > > > > commons.releaseManagerKey > > > > > > > > These properties are personal to the user, and should be defined in > > > > ~/.m2/settings.xml. > > > > See > > https://commons.apache.org/proper/commons-release-plugin/index.html > > > > > > > > Or you can define them on the command line. > > > > > > > > If the RM details are stored in the pom, then it is all too easy for > > > > the wrong values to be used. > > > > > > > > Thanks, > > > > Sebb > > > > > > > > - > > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [ALL] pom.xml should not contain RM details
I recall seeing these properties in the commons-release-plugin docs I use as reference whenever I need to release a component (which the last time was a long time ago, sorry). The commons-release-plugin links to this page: https://commons.apache.org/releases/prepare.html Maybe we need to update that page too to explain these properties must not be persisted. On Tue, 3 Oct 2023 at 10:26, sebb wrote: > The properties are used by the release plugin. > > But since they are unique to the user, they do not belong in the shared > pom. > > On Tue, 3 Oct 2023 at 02:33, Phil Steitz wrote: > > > > +1 but why then are those properties there? > > > > Phil > > > > > On Oct 2, 2023, at 3:58 PM, sebb wrote: > > > > > > As the subject says, please do not use the pom to store RM details > such as > > > > > > commons.releaseManagerName > > > commons.releaseManagerKey > > > > > > These properties are personal to the user, and should be defined in > > > ~/.m2/settings.xml. > > > See > https://commons.apache.org/proper/commons-release-plugin/index.html > > > > > > Or you can define them on the command line. > > > > > > If the RM details are stored in the pom, then it is all too easy for > > > the wrong values to be used. > > > > > > Thanks, > > > Sebb > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [ALL] pom.xml should not contain RM details
The properties are used by the release plugin. But since they are unique to the user, they do not belong in the shared pom. On Tue, 3 Oct 2023 at 02:33, Phil Steitz wrote: > > +1 but why then are those properties there? > > Phil > > > On Oct 2, 2023, at 3:58 PM, sebb wrote: > > > > As the subject says, please do not use the pom to store RM details such as > > > > commons.releaseManagerName > > commons.releaseManagerKey > > > > These properties are personal to the user, and should be defined in > > ~/.m2/settings.xml. > > See https://commons.apache.org/proper/commons-release-plugin/index.html > > > > Or you can define them on the command line. > > > > If the RM details are stored in the pom, then it is all too easy for > > the wrong values to be used. > > > > Thanks, > > Sebb > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
