(I am breaking this discussion out of a bot PR thread to discuss more
broadly.)
Steve Lawrence reminded us recently that updates need to be reviewed
relative to a checklist:
https://cwiki.apache.org/confluence/display/DAFFODIL/Scala+Steward
Given the amount of work this implies, per update, it is 100% clear to me
that the rate of these bot-driven changes that we accept must be massively
cut down. Each one requires significant examination.
What fraction of our dev effort should be spent on this update treadmill. I
would claim < 1%. That's < 2 hours per *month* of work. Frankly I think
even that much is too much.
And by that I mean not just actual work looking at the PRs, but just trying
to keep up with the email load.
I have personally setup email rules to bin all bot update emails into a
sub-folder that I plan to look at only when we do releases, so 2 or 4 times
a year. But alas, every time a dev team member responds to one of those bot
emails, they show up in my inbox again looking for a second reviewer, etc.
So I have not been successful in cutting out this noise.
But it simply must be cut down. The amount of bot-change-related email
dominates all other content on the dev list.
Given that the dev list email is the face of the project as far as
recruiting/retaining more developers, I consider this pollution of the dev
list to be a threat to our project's viability.
I think we are staring at the breaking point for the current state of the
art in what I call "flat linker" software componentry. That is, via these
ongoing attempts for everyone to try to just stay current with the latest
version of every component via update bots. This is what I refer to as the
"update treadmill". By "flat linker" I mean where the whole software
system must have only one version of any given software component. Java
modules and/or OGSI or other namespace systems (non-flat-linker) are the
only long-term way out of this in the long run (note:
https://issues.apache.org/jira/browse/DAFFODIL-2683).
In the meantime, Some ideas:
1. Turning off these update bots, except once a quarter or so, and when we
first start contemplating creating a release. One of the first steps in our
release process is to create a commit for "preparing for release xyzzy".
This would add to that step to re-enable the bots, which would result in a
flurry of update PRs to be dealt with at that time.
2. Accepting these PRs without the scrutiny of the checklist items, so long
as all the CI checks pass, and as part of the pre-release process we
reverify all the transitive dependencies and licenses as a once-a-release
activity for any updated components. Note that there is already release
activity associated with creating release-notes for all updated
dependencies, so this would add on to that work.
3. Make it a basic policy to ignore almost all bot-based update PRs, and
just leave them sitting there. We agree to consciously not respond to them
and we deal with them only if they are security alert related, or we decide
consciously as a project that it is time to work on them.
