Bad timing -- we need to be cautious about this right now.

https://github.com/dependabot/dependabot-core/issues/10634

Dependabot seems to be ignoring our config that it should ignore major and minor updates.

So,

1) Reviewers -- be extra cautious about what you are reviewing.  If you approve such a thing, please comment that you noticed it's not a micro.

2) Mergers -- be extra cautious about what you are merging, particularly in any case where you've not gotten a response from reviewers. Never merge anything but a micro without clear approval.

My inclination is mergers should just close such PRs if they notice them, unless by strange chance all relevant component leads have already noticed it's not a micro approved it.

On Tue, Sep 17, 2024 at 12:24 PM Brian Stansberry <brian.stansberry@redhat.com> wrote:
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@redhat.com> 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@jboss.com> 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@redhat.com> 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?


--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
_______________________________________________
wildfly-dev mailing list -- wildfly-dev@lists.jboss.org
To unsubscribe send an email to wildfly-dev-leave@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/TPDMKFOYOZV4AMQFZPDG2IX3CIXUVY76/


--
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


--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His