date:20220102

Re: Re: can we get rid of dependabot?

2022-01-02 Thread Eric Bresie

Noticed on recent dependabot PR the below being added to the PR.

Would using any of these options (i.e. like @dependabot close which prevent
some of the repeats notifications) help?

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

   - @dependabot rebase will rebase this PR
   - @dependabot recreate will recreate this PR, overwriting any edits that
   have been made to it
   - @dependabot merge will merge this PR after your CI passes on it
   - @dependabot squash and merge will squash and merge this PR after your
   CI passes on it
   - @dependabot cancel merge will cancel a previously requested merge and
   block automerging
   - @dependabot reopen will reopen this PR if it is closed
   - *@dependabot close will close this PR and stop Dependabot recreating
   it. You can achieve the same result by closing it manually*
   - @dependabot ignore this major version will close this PR and stop
   Dependabot creating any more for this major version (unless you reopen the
   PR or upgrade to it yourself)
   - @dependabot ignore this minor version will close this PR and stop
   Dependabot creating any more for this minor version (unless you reopen the
   PR or upgrade to it yourself)
   - @dependabot ignore this dependency will close this PR and stop
   Dependabot creating any more for this dependency (unless you reopen the PR
   or upgrade to it yourself)


On Sun, Jan 2, 2022 at 9:36 AM Eric Bresie  wrote:

> Late to the discussion but I think what is being said and with a few
> follow up questions is…
>
> The problem discussed is when a dependabot check occurs following a
> commit, it highlights out of date dependencies (possibly security related)
> which notifies folks via an automated email sent to multiple mailing list
> with the frequency of such resulting in giving mailing list overwhelmed by
> the frequent checks for dependencies updates.  Is this correct?
>
> It sounds like what is being proposed (and in work) is for the dependabot
> configuration to change the frequency, trigger, and/or destination for the
> emails…is this correct?
>
> From dependency perspective, is the behavior, it notifies for the need for
> an update or does it create an automated updated via a generates “PR” to
> address direct and indirect dependency updates?  Assume for PR case a
> “person in the loop” is still required to review and merge in the PR…right?
>
> From a higher level, is it correct to say, this attempts to reduce the
> risk of security or out of date dependency issues by automating the version
> dependencies checks/updates in a given build and reduce the amount of time
> and manual involvement to reduce security (and other dependency) updates?
>
> I hope this would be considered sooner in the pipeline and maybe for
> another thread, but…if someone has an upstream dependency of some type, and
> a “bad actors” corrupts and updates a given upstream dependency, would this
> potentially “automate the spread” of a “bad actors” dependency update?
> Assume the “person in the loop” would hopefully reduce the risk but just
> thinking worse case scenario here.
>
>
> Eric Bresie
> ebre...@gmail.com
>
> On December 30, 2021 at 6:12:06 PM CST, Rob Tompkins 
> wrote:
> I believe that we already have begun to do this. -Rob
>
> On Dec 30, 2021, at 6:16 PM, sebb  wrote:
>
> Those of you who want to keep the robot, please use the instructions
> to reduce the spam.
>
> On Thu, 30 Dec 2021 at 22:51, Rob Tompkins  wrote:
>
>
>
> On Dec 30, 2021, at 5:50 PM, Matt Sicker  wrote:
>
>
> There are tons of options to configure. The defaults are handy for
> smaller projects, but they are clearly spammy for larger ones like this.
>
>
> https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates
> <
> https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates>
>
>
>
> +1
>
> --
> Matt Sicker
>
> On Dec 30, 2021, at 16:48, Rob Tompkins  wrote:
>
>
>
> On Dec 30, 2021, at 5:37 PM, sebb  mailto:seb...@gmail.com >> wrote:
>
>
> On Thu, 30 Dec 2021 at 21:39, Rob Tompkins  mailto:chtom...@gmail.com >> wrote:
>
>
> Guys. The fundamental argument underpinng all this is whether it’s better
> to have robot eyes on the code and human eyes on the code. Stop arguing one
> side or the other. We need to find a way to do both successfully.
>
>
> The issue is *not* about robot or no robot.
>
> It is about this particular robot that causes so much noise.
>
>
> Yes! That’s right so we need to figure out how to use the robot correctly!
>
>
>
>
> On Dec 29, 2021, at 1:57 PM, Phil Steitz  mailto:phil.ste...@gmail.com >> wrote:
>
>
> 
>
> On 12/29/21 8:43 AM, sebb wrote:
>
> On Wed, 29 Dec 2021 at 14:53, Gary Gregory  mailto:garydgreg...@gmail.com >> wrote:
>
> On Wed, Dec 29, 2021 at 9:42 AM sebb  mailto:seb...@gmail.com >>

Re: Re: can we get rid of dependabot?

2022-01-02 Thread Xeno Amess

IMO it is the dependency's developer's duti to keep their private key safe, and 
oss 's duty to keep the uploaded dependency stored and delivered safe.

If you really think to apply zero trust in this way, maybe we shall also think 
git, github, maven, jdk, system,all of them have possibility to corrupt the 
artiface.

XenoAmess

From: Eric Bresie 
Sent: Sunday, January 2, 2022 11:36:18 PM
To: dev@commons.apache.org 
Subject: Re: Re: can we get rid of dependabot?

Late to the discussion but I think what is being said and with a few follow up 
questions is…

The problem discussed is when a dependabot check occurs following a commit, it 
highlights out of date dependencies (possibly security related) which notifies 
folks via an automated email sent to multiple mailing list with the frequency 
of such resulting in giving mailing list overwhelmed by the frequent checks for 
dependencies updates. Is this correct?

It sounds like what is being proposed (and in work) is for the dependabot 
configuration to change the frequency, trigger, and/or destination for the 
emails…is this correct?

From dependency perspective, is the behavior, it notifies for the need for an 
update or does it create an automated updated via a generates “PR” to address 
direct and indirect dependency updates? Assume for PR case a “person in the 
loop” is still required to review and merge in the PR…right?

From a higher level, is it correct to say, this attempts to reduce the risk of 
security or out of date dependency issues by automating the version 
dependencies checks/updates in a given build and reduce the amount of time and 
manual involvement to reduce security (and other dependency) updates?

I hope this would be considered sooner in the pipeline and maybe for another 
thread, but…if someone has an upstream dependency of some type, and a “bad 
actors” corrupts and updates a given upstream dependency, would this 
potentially “automate the spread” of a “bad actors” dependency update? Assume 
the “person in the loop” would hopefully reduce the risk but just thinking 
worse case scenario here.

Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)

> On December 30, 2021 at 6:12:06 PM CST, Rob Tompkins  (mailto:chtom...@gmail.com)> wrote:
> I believe that we already have begun to do this. -Rob
>
> > On Dec 30, 2021, at 6:16 PM, sebb  > (mailto:seb...@gmail.com)> wrote:
> >
> > Those of you who want to keep the robot, please use the instructions
> > to reduce the spam.
> >
> > > On Thu, 30 Dec 2021 at 22:51, Rob Tompkins  > > (mailto:chtom...@gmail.com)> wrote:
> > >
> > >
> > >
> > > > > On Dec 30, 2021, at 5:50 PM, Matt Sicker  > > > > (mailto:boa...@gmail.com)> wrote:
> > > >
> > > > There are tons of options to configure. The defaults are handy for 
> > > > smaller projects, but they are clearly spammy for larger ones like this.
> > > >
> > > > https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates
> > > >  
> > > > 
> > > >
> > >
> > > +1
> > >
> > > > --
> > > > Matt Sicker
> > > >
> > > > > > On Dec 30, 2021, at 16:48, Rob Tompkins  > > > > > (mailto:chtom...@gmail.com)> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On Dec 30, 2021, at 5:37 PM, sebb  > > > > > > (mailto:seb...@gmail.com) > wrote:
> > > > > >
> > > > > > On Thu, 30 Dec 2021 at 21:39, Rob Tompkins  > > > > > (mailto:chtom...@gmail.com) > wrote:
> > > > > > >
> > > > > > > Guys. The fundamental argument underpinng all this is whether 
> > > > > > > it’s better to have robot eyes on the code and human eyes on the 
> > > > > > > code. Stop arguing one side or the other. We need to find a way 
> > > > > > > to do both successfully.
> > > > > >
> > > > > > The issue is *not* about robot or no robot.
> > > > > >
> > > > > > It is about this particular robot that causes so much noise.
> > > > >
> > > > > Yes! That’s right so we need to figure out how to use the robot 
> > > > > correctly!
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > > On Dec 29, 2021, at 1:57 PM, Phil Steitz 
> > > > > > > > > mailto:phil.ste...@gmail.com) 
> > > > > > > > > > wrote:
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > > On 12/29/21 8:43 AM, sebb wrote:
> > > > > > > > > > On Wed, 29 Dec 2021 at 14:53, Gary Gregory 
> > > > > > > > > > mailto:garydgreg...@gmail.com) 
> > > > > > > > > > > wrote:
> > > > > > > > > > > On Wed, Dec 29, 2021 at 9:42 AM sebb  > > > > > > > > > > (mailto:seb...@gmail.com) > 
> > > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > On Wed, 29 Dec 2021 at 14:18, Gary Gregory

Re: Re: can we get rid of dependabot?

2022-01-02 Thread Eric Bresie

Late to the discussion but I think what is being said and with a few follow up 
questions is…

The problem discussed is when a dependabot check occurs following a commit, it 
highlights out of date dependencies (possibly security related) which notifies 
folks via an automated email sent to multiple mailing list with the frequency 
of such resulting in giving mailing list overwhelmed by the frequent checks for 
dependencies updates. Is this correct?

It sounds like what is being proposed (and in work) is for the dependabot 
configuration to change the frequency, trigger, and/or destination for the 
emails…is this correct?

From dependency perspective, is the behavior, it notifies for the need for an 
update or does it create an automated updated via a generates “PR” to address 
direct and indirect dependency updates? Assume for PR case a “person in the 
loop” is still required to review and merge in the PR…right?

From a higher level, is it correct to say, this attempts to reduce the risk of 
security or out of date dependency issues by automating the version 
dependencies checks/updates in a given build and reduce the amount of time and 
manual involvement to reduce security (and other dependency) updates?

I hope this would be considered sooner in the pipeline and maybe for another 
thread, but…if someone has an upstream dependency of some type, and a “bad 
actors” corrupts and updates a given upstream dependency, would this 
potentially “automate the spread” of a “bad actors” dependency update? Assume 
the “person in the loop” would hopefully reduce the risk but just thinking 
worse case scenario here.

Eric Bresie
ebre...@gmail.com (mailto:ebre...@gmail.com)

> On December 30, 2021 at 6:12:06 PM CST, Rob Tompkins  (mailto:chtom...@gmail.com)> wrote:
> I believe that we already have begun to do this. -Rob
>
> > On Dec 30, 2021, at 6:16 PM, sebb  > (mailto:seb...@gmail.com)> wrote:
> >
> > Those of you who want to keep the robot, please use the instructions
> > to reduce the spam.
> >
> > > On Thu, 30 Dec 2021 at 22:51, Rob Tompkins  > > (mailto:chtom...@gmail.com)> wrote:
> > >
> > >
> > >
> > > > > On Dec 30, 2021, at 5:50 PM, Matt Sicker  > > > > (mailto:boa...@gmail.com)> wrote:
> > > >
> > > > There are tons of options to configure. The defaults are handy for 
> > > > smaller projects, but they are clearly spammy for larger ones like this.
> > > >
> > > > https://docs.github.com/en/code-security/supply-chain-security/keeping-your-dependencies-updated-automatically/configuration-options-for-dependency-updates
> > > >  
> > > > 
> > > >
> > >
> > > +1
> > >
> > > > --
> > > > Matt Sicker
> > > >
> > > > > > On Dec 30, 2021, at 16:48, Rob Tompkins  > > > > > (mailto:chtom...@gmail.com)> wrote:
> > > > > >
> > > > > >
> > > > > >
> > > > > > > On Dec 30, 2021, at 5:37 PM, sebb  > > > > > > (mailto:seb...@gmail.com) > wrote:
> > > > > >
> > > > > > On Thu, 30 Dec 2021 at 21:39, Rob Tompkins  > > > > > (mailto:chtom...@gmail.com) > wrote:
> > > > > > >
> > > > > > > Guys. The fundamental argument underpinng all this is whether 
> > > > > > > it’s better to have robot eyes on the code and human eyes on the 
> > > > > > > code. Stop arguing one side or the other. We need to find a way 
> > > > > > > to do both successfully.
> > > > > >
> > > > > > The issue is *not* about robot or no robot.
> > > > > >
> > > > > > It is about this particular robot that causes so much noise.
> > > > >
> > > > > Yes! That’s right so we need to figure out how to use the robot 
> > > > > correctly!
> > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > > > On Dec 29, 2021, at 1:57 PM, Phil Steitz 
> > > > > > > > > mailto:phil.ste...@gmail.com) 
> > > > > > > > > > wrote:
> > > > > > > >
> > > > > > > > 
> > > > > > > >
> > > > > > > > > On 12/29/21 8:43 AM, sebb wrote:
> > > > > > > > > > On Wed, 29 Dec 2021 at 14:53, Gary Gregory 
> > > > > > > > > > mailto:garydgreg...@gmail.com) 
> > > > > > > > > > > wrote:
> > > > > > > > > > > On Wed, Dec 29, 2021 at 9:42 AM sebb  > > > > > > > > > > (mailto:seb...@gmail.com) > 
> > > > > > > > > > > wrote:
> > > > > > > > > >
> > > > > > > > > > > On Wed, 29 Dec 2021 at 14:18, Gary Gregory 
> > > > > > > > > > > mailto:garydgreg...@gmail.com) 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > > On Wed, Dec 29, 2021 at 9:07 AM sebb  > > > > > > > > > > > (mailto:seb...@gmail.com) > 
> > > > > > > > > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > On Wed, 29 Dec 2021 at 13:54, Gary Gregory 
> > > > > > > > > > > > >  > > > > > > > > > > > > (mailto:garydgreg...@gmail.com) 
> > > > > > > > > > > > >

Re: [all] Binaries for example modules

2022-01-02 Thread Thomas

Maybe a bit late in the game, but still:

In face of the fact, that we are already looking at a multi module project:

Having all the examples within a dedicated module added into the
hierarchy would allow us, to have it all, and still without burdening
the RM:

- keeping the examples current by compiling and executing/testing them
during releases

- maintaining arbitrary links from other modules sites/javadoc into the
site generated by the examples

- we may still avoid to distribute some of their artifacts, especially
the binaries, by simply excluding them from install/deploy/release
steps, which could done by properly configuring the
install/deploy/release plugins within the examples pom. It shouldn't
even be necessary, to have a profile for that.

Just my 2 cents.

The only thing, that might be of interest is the question, whether as
part of the process, the examples module should produce and release kind
of a source artifact, containing the *complete* source (with pom,
src/main/** etc), or if we point the users simply to the version
control URL, where they might check it out.

Regards,

Thomas

On 09.08.2021 13:22, Matt Juntunen wrote:

Advertising
the examples at a higher level in the project site is better, so adding
them to the user guide is an appropriate place. The question then is should
the higher location point the user to the module site index, recommend
downloading the source release which contains all the examples (and not
having the module site published), or both.

I would say both.

I do not think pushing the artifacts to Maven Central is useful

+1. I think we're all agreed on this point.

-Matt J

On Sun, Aug 8, 2021 at 5:38 PM Alex Herbert wrote:

On Fri, 6 Aug 2021 at 04:01, Gilles Sadowski wrote:

Le ven. 6 août 2021 à 04:01, Matt Juntunen a
écrit :

Gilles,

I do _not_ ask any work to be done in order to complicate the release
process and/or review.
My question was (cf. above and the other thread) whether singling out
the "examples" module has any benefit (apart from saving a few bytes
on Maven Central).

Yes, I believe it is beneficial. If nothing else, it keeps maven
central and the project site uncluttered and reduces the chance of
user confusion.

I do not see where the problem is supposed to be (with Maven Central).
But, either way, it's not worth fighting over it, as long as the examples
are kept in sync with the code (and this is done at the lastest as part
of the current release process). [The counter-example is "Commons
Math", where the code examples were not kept up to date with the
main code...]
For the site, I believe that the examples should be there, as they are
show-cases (for users!) of fully-working applications.[1]

I do not think that the layout of the site for maven modules is very
friendly for browsing the source. You are required to traverse down the
hierarchy to the module site index, then click the project reports link
then either the javadoc or xref reports. It takes a lot of finding and may
not be found at all by a new user of the modular site layout. Advertising
the examples at a higher level in the project site is better, so adding
them to the user guide is an appropriate place. The question then is should
the higher location point the user to the module site index, recommend
downloading the source release which contains all the examples (and not
having the module site published), or both.

I do not think pushing the artifacts to Maven Central is useful as the
applications are either developer testing tools or integration test demos.
These are not of use to be linked by a third party as a dependency, and
given they have no binary compatibility guarantee it would be unwise to
depend on them anyway.

Gilles

[1] See e.g.
https://commons.apache.org/proper/commons-rng/commons-rng-examples/commons-rng-examples-quadrature/xref/index.html

-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: [MATH] Build Failure

2022-01-02 Thread Avijit Basak

Hi All

I have created a new *PR*(*#200*) with all changes under a single
commit message. Kindly review the same and let me know if any further
change is required.

Thanks & Regards
--Avijit Basak

On Mon, 27 Dec 2021 at 23:31, Gilles Sadowski  wrote:

> Hello.
>
> Le lun. 27 déc. 2021 à 16:02, Avijit Basak  a
> écrit :
> >
> > Hi All
> >
> > Please ignore my previous mail. The rebase is done successfully.
> > Please let me know if there is any issue.
>
> Here is a the list of commit messages that are should not be
> present (at least not when introducing completely new code):
>
> Merge branch 'feature/MATH-1563-ADAPTIVE' of
> https://github.com/avijitbasak/commons-math.git into
> feature/MATH-1563-ADAPTIVE
> removed 64 by Long.SIZE
> Merge branch 'master' of https://github.com/apache/commons-math.git
> into feature/MATH-1563-ADAPTIVE
> Minor change for UniformRandomProvider
> modified as per PMD recommendations
> updated for checkstyle formatting
> An optimized data structure implementation for binary chromosome
> minor modifications
> Modifications as per review comments
> Developed the new genetic algorithm module following the JIRA MATH-1563.
>
> What I suggested is to check out a pristine copy of "master", and copy
> the new files onto it, and only change whatever needs to be touched for
> the new contents to be handled correctly (i.e. just the POM files I guess).
>
> Then generate a _new_ PR (and close #199).
> There should be a _single_ commit with a log message of the form:
> ---CUT---
> MATH-1563: Introducing new implementation of GA functionality (WIP).
> ---CUT---
>
> [If you don't want to give more details about all the changes, please
> stick to the above sentence.  Note that the convention is that the
> issue identifier be followed by a colon; then, as the commit log
> summary, a single sentence, ending with a period, on the first line.]
>
> Thanks,
> Gilles
>
> >
> > Thanks & Regards
> > --Avijit Basak
> >
> > On Mon, 27 Dec 2021 at 19:21, Avijit Basak 
> wrote:
> >
> > > Hi All
> > >
> > > I have tried to rebase. However I found too many conflicts and
> > > most of them are unnecessary. So I aborted the process. Can we avoid
> the
> > > rebase as we have very few commits after the last rebase. Please share
> your
> > > views on this.
> > >
> > > Thanks & Regards
> > > --Avijit Basak
> > >
> > > On Sat, 25 Dec 2021 at 18:45, Gilles Sadowski 
> > > wrote:
> > >
> > >> Hello.
> > >>
> > >> I've fetched the current contents of PR 199; locally, the build
> completes
> > >> successfully, so the problem reported by Travis looks strange indeed.
> > >> I would create a branch for further discussion on your GA design but
> > >> please first create a *single* commit that contains all changes wrt to
> > >> current "master" with a clear log message (first word *must* be the
> JIRA
> > >> identifier of your proposal (perhaps a new JIRA report would be
> clearer?),
> > >> like:
> > >> ---CUT---
> > >> MATH-: Refactoring of GA functionality (WIP)
> > >>
> > >> Summary of what has been implemented (with the corresponding JIRA
> > >> reports)...
> > >>
> > >> (optionally) Summary what is under discussion...
> > >> ---CUT---
> > >>
> > >> Thanks,
> > >> Gilles
> > >>
> > >> >> [...]
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>

-- 
Avijit Basak

Re: Re: can we get rid of dependabot?

Re: Re: can we get rid of dependabot?

Re: Re: can we get rid of dependabot?

Re: [all] Binaries for example modules

Re: [MATH] Build Failure

5 matches

Site Navigation

Mail list logo

Footer information