> On Dec 29, 2021, at 10:29 AM, Matt Benson <mben...@apache.org> wrote:
>
> On Wed, Dec 29, 2021, 9:21 AM Mark Thomas <ma...@apache.org> wrote:
>
>>> On 29/12/2021 15:04, Gary Gregory wrote:
>>>> On Wed, Dec 29, 2021 at 9:37 AM Rob Tompkins <chtom...@gmail.com> wrote:
>>>
>>>> Why not just run dependabot weekly. We move slowly enough that weekly
>>>> currently works. Until we can get more hands on the project, slower
>> comms
>>>> are indeed reasonable…right?
>>>>
>>>
>>> I would be OK with it once a week.
>>
>> I think the improvement resulting from moving to once a week will be
>> minimal.
>>
>> I get the desire to keep things up to date but the way dependabot is
>> currently working creates a lot of traffic on both issues@ and commits@
>> That noise makes it much harder to follow any other activity that might
>> be happening in the project. I am finding it a lot more effort to keep
>> track of the Commons projects I am interested in.
>>
>> Most commons libraries have very few "real" dependencies. Most of the
>> dependencies are there to support testing or building. I would argue
>> that updates to test/build libraries are far less critical and low risk
>> to update en masse just before a release.
>>
>> I may look at applying local filters in the short term but that strikes
>> me very much as fixing the symptom rather than the cause and I don't
>> think it is efficient for every subscriber to have to do this if there
>> is an approach available that addresses the root cause.
>>
>> As an aside, we also need to keep repeatable builds in mind. Simply
>> defining a version dependency as "latest" (or anything other than an
>> explicit version) is going to be problematic.
>>
>> So, is there a way we could do something like the following with any
>> combination of dependabot and/or Versions Maven plugin and/or something
>> else?
>>
>> - dependabot like behaviour (daily check, separate PR) for dependencies
>> that are used (required or optional) at runtime
>>
>> - a weekly (or even monthly?) check for test libraries, build tools etc.
>> (i.e. everything that isn't a runtime dependency) that provides,
>> ideally, a single PR with one commit per update
>>
>> Emphasis on the "something like" the above.
>>
>
+1
> To jump into the discussion, I think these are sensible and constructive
> suggestions.
>
> Matt
>
> Mark
>>
>> ---------------------------------------------------------------------
>> 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
