On 12/29/21 8:43 AM, sebb wrote:
On Wed, 29 Dec 2021 at 14:53, Gary Gregory <garydgreg...@gmail.com> wrote:
On Wed, Dec 29, 2021 at 9:42 AM sebb <seb...@gmail.com> wrote:
On Wed, 29 Dec 2021 at 14:18, Gary Gregory <garydgreg...@gmail.com> wrote:
On Wed, Dec 29, 2021 at 9:07 AM sebb <seb...@gmail.com> wrote:
On Wed, 29 Dec 2021 at 13:54, Gary Gregory <garydgreg...@gmail.com>
wrote:
One critical feature is that dependabot does all the builds for you
on
GitHub Actions, this is an enormous time and resource saver!
Not at all.
Just the reverse.
It does NOT save resources, because it runs builds for updates that
are not necessary at that point in time (or ever, in some cases).
Nor does it same time, because the the noise that it generates.
Please stop pretending that Dependabot does things it does not (and
likely cannot) do.
Oh, boy, Sebb, it feels like you are purposely misunderstanding my POV.
It's as simple as I stated:
If Dependabot detects that a new version of a dependency is available,
creates a branch, runs a build, tells me the result and I have a PR I can
merge, *that is all work and time *I* do not have to do manually! Why is
that so hard to understand?*
Of course I understand that.
Phew! :-)
However, just because a new version is available does NOT mean that it
has to be updated there and then.
Sometimes it never needs to be updated.
You can't know if you need to make a decision unless someone asks you to
make it. I don't know out of thin air that a new version is available.
You can be pro-active and do a dependency check yourself.
And you can look out for security bulletins.
That's what we used to do.
Changes to dependencies occur much more frequently than component releases.
So often there will be several mails for the same dependency.
In the past, the approach was to check for new (and useful) updates
shortly before a release.
That must have been before my time and it seems like a horrible idea: The
software is stable after a few months of activity and it's time to make a
release, so the day before a release, you change all the dependencies, and
cross your fingers? Yikes!
That is NOT what I said.
Obviously one would start working on version updates some time before
the release.
Days or weeks rather than months or years.
Generally all the versions would be updated at the same time, instead
of individually.
Not here, if update 10 dependencies and a build fails, then what? I go back
to square one and update each, one at a time, until I find the culprit,
which to me is a waste of time. BTW, 10 dependencies is not unreasonable
for components like VFS, Configuration, and others.
Well yes, but how likely is there to be a failure in such circumstances?
If the build does not fail, you have saved the noise from at least 9
updates which are generally 3 emails per update.
If it does fail, you will have wasted 2 cycles: the original commit of
10, and the revert. And only 2 emails.
+1 and you will get many thanks from those trying to follow commits and
better review of the actual commits. It seems badly broken to me that
in order to effectively review commits to the commons components that I
watch I have to write filters to ignore most of them. The damage from
making it harder to review commits is far greater than the benefit this
thing provides. Actual code commits are where bugs and vulnerabilities
get introduced. Just like mixing formatting changes with functional
code changes is a bad practice, spamming commits@ with a bunch of
auto-branch creations is bad as it dilutes eyeballs, which are the most
important community resource that we have in ensuring code quality and
security.
Phil
Gary
Gary
Gary
On Wed, Dec 29, 2021, 08:51 Rob Tompkins <chtom...@gmail.com> wrote:
On Dec 29, 2021, at 8:45 AM, Romain Manni-Bucau <
rmannibu...@gmail.com>
wrote:
@Rob: dependabot is mainly about dependencies upgrades and it is
also
why
it is so chatty and has so much false positives.
Yes, I am well aware. But I do not see how a robot telling you to
simply
upgrade is a problem?
Maybe I’m missing something but my impression is that’s what
dependabot
does right? Tell you you need to upgrade?
-Rob
If you want to focus on
CVE then setting up on the CI
https://sonatype.github.io/ossindex-maven/maven-plugin/ is way
more
efficient and accurate (basically when it fails you must act) so
dependabot
is a great reporting tool for managers but not to work on an
everyday
basis
IMHO until it is very finely configure but commons is far to
need so
much
investment since there already have solutions for everything
needed
IMHO.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <
https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<
https://www.packtpub.com/application-development/java-ee-8-high-performance
Le mer. 29 déc. 2021 à 14:39, Rob Tompkins <chtom...@gmail.com>
a
écrit :
Guys. I think dependabot is our greatest advantage in the work
against
security problems. I know she has her failings and is chatty.
But, I
think
we should open a line of thinking about how best she can help.
The reason she’s a pain in the ass is that we don’t have enough
hands on
the project making it better. I know I would help more, but I
have
to
keep
up with my father who’s a quadriplegic as well as a currently
failing
marriage.
The answer is that we need more hands on the project. I wish I
could be
those hands but time and priorities keep me chained.
Cheers,
-Rob
On Dec 29, 2021, at 8:26 AM, Gilles Sadowski <
gillese...@gmail.com
wrote:
Le mer. 29 déc. 2021 à 12:18, Thomas Vandahl <t...@apache.org>
a
écrit
:
+1
Thank you, Phil. This thing is a P.I.T.A.
In effect, from day one:
https://markmail.org/message/2vutc4p3b3eqv73f
Basically, the argument is that
* the (dependabot) feature is too important to be disabled
* the annoyed people should filter out those mails (which I
did since no one at the time supported that they be diverted
to another ML).
Did anything change since then?
[Or do we eventually question the general anomaly that code
discussions have been almost completely off-loaded to GH?]
Gilles
Am 28.12.2021 um 19:20 schrieb Phil Steitz <
phil.ste...@gmail.com>:
I can no longer effectively monitor commits@ due to the spam
generated by this tool. I am afraid my eyeballs aren't the only
ones
going
missing here and that is a problem much more severe than any
value
provided
by this tool, IMO.
Phil
Bye, Thomas
---------------------------------------------------------------------
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
---------------------------------------------------------------------
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
