I'd like to propose we move to a lower touch system for processing dependabot updates. Currently when dependabot files a PR, wildfly-bot tags various component leads to request a review, and then often I or others tag others. (I typically do this based on quick git grepping of module.xml to find uses.) And then things often block with no feedback, leading to repeated checking on the PR. So my proposal is if you are tagged for a review on one of these, you have two weeks to either approve or raise an objection via the GH PR review UI, or put a 'hold' label on the PR and leave a comment explaining why. The latter is basically a way of saying 'give me more time'. Then remove the hold when done. After 10 calendar days, PRs without objections or 'hold' statements are free to merge. If your component is the sole user of a particularly dependency and you don't want dependabot managing it, send a PR updating dependabot.yaml.[1] Thoughts? [1] https://github.com/wildfly/wildfly/blob/main/.github/dependabot.yml -- Brian Stansberry Principal Architect, Red Hat JBoss EAP WildFly Project Lead He/Him/His _______________________________________________ wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org Privacy Statement: https://www.redhat.com/en/about/privacy-policy List Archives: https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message...

10 days sounds far, in theory if these projects also enabled dependabot they should have also received a PR for the same update so hopefully will have some CI results already. On Mon, Sep 16, 2024 at 4:30 PM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > I'd like to propose we move to a lower touch system for processing > dependabot updates. > > Currently when dependabot files a PR, wildfly-bot tags various component > leads to request a review, and then often I or others tag others. (I > typically do this based on quick git grepping of module.xml to find uses.) > > And then things often block with no feedback, leading to > repeated checking on the PR. > > So my proposal is if you are tagged for a review on one of these, you > have two weeks to either approve or raise an objection via the GH PR review > UI, or put a 'hold' label on the PR and leave a comment explaining why. The > latter is basically a way of saying 'give me more time'. Then remove the > hold when done. > > After 10 calendar days, PRs without objections or 'hold' statements are > free to merge. > > If your component is the sole user of a particularly dependency and you > don't want dependabot managing it, send a PR updating dependabot.yaml.[1] > > Thoughts? > > [1] https://github.com/wildfly/wildfly/blob/main/.github/dependabot.yml > > -- > Brian Stansberry > Principal Architect, Red Hat JBoss EAP > WildFly Project Lead > He/Him/His > _______________________________________________ > wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org > To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org > Privacy Statement: https://www.redhat.com/en/about/privacy-policy > List Archives: > https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >

I temporarily went with 6 days. :-) I just put this on the 8 open dependabot PRs. "@person1 @person2 Please approve, object or put a 'hold' label (with explanatory comment) to by more time by Monday, Sept 24. If approved please file a WFLY component upgrade JIRA." I went with Sept 24 (6 days) so we can decide Monday if we want to merge any of these on that day, before the 34 beta tag. All of these PRs have been open for a long time. On Tue, Sep 17, 2024 at 11:41 AM Brian Stansberry < brian.stansberry(a)redhat.com&gt; wrote: > I'm not wedded to the 10 days. It's basically a "you can take a week off > and not worry about this" period. > > If there was true urgency about one of these we can always accelerate. > > +1 to your point that component projects should add their own automation. > Note we don't control many important projects though. > > > On Tue, Sep 17, 2024 at 3:24 AM Darran Lofthouse < > darran.lofthouse(a)jboss.com&gt; wrote: > >> >> 10 days sounds far, in theory if these projects also enabled dependabot >> they should have also received a PR for the same update so hopefully will >> have some CI results already. >> >> On Mon, Sep 16, 2024 at 4:30 PM Brian Stansberry < >> brian.stansberry(a)redhat.com&gt; wrote: >> >>> I'd like to propose we move to a lower touch system for processing >>> dependabot updates. >>> >>> Currently when dependabot files a PR, wildfly-bot tags various >>> component leads to request a review, and then often I or others tag others. >>> (I typically do this based on quick git grepping of module.xml to find >>> uses.) >>> >>> And then things often block with no feedback, leading to >>> repeated checking on the PR. >>> >>> So my proposal is if you are tagged for a review on one of these, you >>> have two weeks to either approve or raise an objection via the GH PR review >>> UI, or put a 'hold' label on the PR and leave a comment explaining why. The >>> latter is basically a way of saying 'give me more time'. Then remove the >>> hold when done. >>> >>> After 10 calendar days, PRs without objections or 'hold' statements are >>> free to merge. >>> >>> If your component is the sole user of a particularly dependency and you >>> don't want dependabot managing it, send a PR updating dependabot.yaml.[1] >>> >>> Thoughts? >>> >>> [1] https://github.com/wildfly/wildfly/blob/main/.github/dependabot.yml >>> >>> -- >>> Brian Stansberry >>> Principal Architect, Red Hat JBoss EAP >>> WildFly Project Lead >>> He/Him/His >>> _______________________________________________ >>> wildfly-dev mailing list -- wildfly-dev(a)lists.jboss.org >>> To unsubscribe send an email to wildfly-dev-leave(a)lists.jboss.org >>> Privacy Statement: https://www.redhat.com/en/about/privacy-policy >>> List Archives: >>> https://lists.jboss.org/archives/list/wildfly-dev@lists.jboss.org/message... >>> >> > > -- > Brian Stansberry > Principal Architect, Red Hat JBoss EAP > WildFly Project Lead > He/Him/His > -- Brian Stansberry Principal Architect, Red Hat JBoss EAP WildFly Project Lead He/Him/His