You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Avijit Basak <av...@gmail.com> on 2022/01/02 13:35:09 UTC

Re: [MATH] Build Failure

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 <gi...@gmail.com> wrote:

> Hello.
>
> Le lun. 27 déc. 2021 à 16:02, Avijit Basak <av...@gmail.com> 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 <av...@gmail.com>
> 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 <gi...@gmail.com>
> > > 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-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>

-- 
Avijit Basak

Re: [MATH] Build Failure

Posted by Gilles Sadowski <gi...@gmail.com>.
By the way, we should also start a new ML thread when we change
subject (this thread was about "Build Failure", not about modifying a
previous PR).

Thanks,
Gilles

Le mer. 5 janv. 2022 à 17:50, Gilles Sadowski <gi...@gmail.com> a écrit :
>
> On GH, the "feature" branch referred to below is at
>     https://github.com/apache/commons-math/tree/feature__MATH-1563__genetic_algorithm
>
> Le mer. 5 janv. 2022 à 17:45, Gilles Sadowski <gi...@gmail.com> a écrit :
> >
> > Hello.
> >
> > Le mer. 5 janv. 2022 à 09:26, Avijit Basak <av...@gmail.com> a écrit :
> > >
> > > Hi All
> > >
> > >        I have identified a few *protected* methods which could be made
> > > *private*. Those are mostly validation methods of input arguments and used
> > > internally. Keeping them as protected won't add much value considering
> > > future extension.
> >
> > This is the crux of the above (long) discussion.
> > Everything that "could" be private, must be private.
> > Anything that does not need to be public should be private
> > by default, until a use-case is demonstrated for enhancing
> > its visibility status.
> >
> > > I would like to do the modification.
> > >        It would be helpful if anyone can confirm the process of checking in
> > > new code now. Will it be as part of the same PR(#200) with a new commit?
> >
> > No.  The state of PR #200 as of two days ago is in the
> >     feature__MATH-1563__genetic_algorithm
> > branch.[1]
> > From now on, modifications should come as new PRs based against
> > that branch (i.e. *not* the "master" branch).
> >
> > > Would the commit message remain the same as earlier?
> >
> > No; please describe concisely, but fully, what the commit does.
> > [For major changes, it may be useful to also file a JIRA report.]
> > If there are several trivial changes, it is preferable that they be
> > collected as a single commit (per PR).
> > In this instance, the commit message could just be
> > ---CUT---
> > Changed "protected" to "private".
> > ---CUT---
> > without much more details, since it is in line with the general
> > consensus that more "privacy" is better. ;-)
> > However, please be careful to not mix several types of changes
> > (e.g. visibility level changes and formatting changes) within the
> > same commit.
> >
> > Thanks in advance,
> > Gilles
> >
> > [1] https://gitbox.apache.org/repos/asf?p=commons-math.git;a=shortlog;h=refs/heads/feature__MATH-1563__genetic_algorithm
> >
> > >
> > > Thanks & Regards
> > > --Avijit Basak
> > >
> > > On Sun, 2 Jan 2022 at 19:05, Avijit Basak <av...@gmail.com> wrote:
> > >
> > > > 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
> > > >
> > > > > [...]

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


Re: [MATH] Build Failure

Posted by Gilles Sadowski <gi...@gmail.com>.
On GH, the "feature" branch referred to below is at
    https://github.com/apache/commons-math/tree/feature__MATH-1563__genetic_algorithm

Le mer. 5 janv. 2022 à 17:45, Gilles Sadowski <gi...@gmail.com> a écrit :
>
> Hello.
>
> Le mer. 5 janv. 2022 à 09:26, Avijit Basak <av...@gmail.com> a écrit :
> >
> > Hi All
> >
> >        I have identified a few *protected* methods which could be made
> > *private*. Those are mostly validation methods of input arguments and used
> > internally. Keeping them as protected won't add much value considering
> > future extension.
>
> This is the crux of the above (long) discussion.
> Everything that "could" be private, must be private.
> Anything that does not need to be public should be private
> by default, until a use-case is demonstrated for enhancing
> its visibility status.
>
> > I would like to do the modification.
> >        It would be helpful if anyone can confirm the process of checking in
> > new code now. Will it be as part of the same PR(#200) with a new commit?
>
> No.  The state of PR #200 as of two days ago is in the
>     feature__MATH-1563__genetic_algorithm
> branch.[1]
> From now on, modifications should come as new PRs based against
> that branch (i.e. *not* the "master" branch).
>
> > Would the commit message remain the same as earlier?
>
> No; please describe concisely, but fully, what the commit does.
> [For major changes, it may be useful to also file a JIRA report.]
> If there are several trivial changes, it is preferable that they be
> collected as a single commit (per PR).
> In this instance, the commit message could just be
> ---CUT---
> Changed "protected" to "private".
> ---CUT---
> without much more details, since it is in line with the general
> consensus that more "privacy" is better. ;-)
> However, please be careful to not mix several types of changes
> (e.g. visibility level changes and formatting changes) within the
> same commit.
>
> Thanks in advance,
> Gilles
>
> [1] https://gitbox.apache.org/repos/asf?p=commons-math.git;a=shortlog;h=refs/heads/feature__MATH-1563__genetic_algorithm
>
> >
> > Thanks & Regards
> > --Avijit Basak
> >
> > On Sun, 2 Jan 2022 at 19:05, Avijit Basak <av...@gmail.com> wrote:
> >
> > > 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
> > >
> > > > [...]

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


Re: [MATH] Build Failure

Posted by Gilles Sadowski <gi...@gmail.com>.
Hello.

Le mer. 5 janv. 2022 à 09:26, Avijit Basak <av...@gmail.com> a écrit :
>
> Hi All
>
>        I have identified a few *protected* methods which could be made
> *private*. Those are mostly validation methods of input arguments and used
> internally. Keeping them as protected won't add much value considering
> future extension.

This is the crux of the above (long) discussion.
Everything that "could" be private, must be private.
Anything that does not need to be public should be private
by default, until a use-case is demonstrated for enhancing
its visibility status.

> I would like to do the modification.
>        It would be helpful if anyone can confirm the process of checking in
> new code now. Will it be as part of the same PR(#200) with a new commit?

No.  The state of PR #200 as of two days ago is in the
    feature__MATH-1563__genetic_algorithm
branch.[1]
From now on, modifications should come as new PRs based against
that branch (i.e. *not* the "master" branch).

> Would the commit message remain the same as earlier?

No; please describe concisely, but fully, what the commit does.
[For major changes, it may be useful to also file a JIRA report.]
If there are several trivial changes, it is preferable that they be
collected as a single commit (per PR).
In this instance, the commit message could just be
---CUT---
Changed "protected" to "private".
---CUT---
without much more details, since it is in line with the general
consensus that more "privacy" is better. ;-)
However, please be careful to not mix several types of changes
(e.g. visibility level changes and formatting changes) within the
same commit.

Thanks in advance,
Gilles

[1] https://gitbox.apache.org/repos/asf?p=commons-math.git;a=shortlog;h=refs/heads/feature__MATH-1563__genetic_algorithm

>
> Thanks & Regards
> --Avijit Basak
>
> On Sun, 2 Jan 2022 at 19:05, Avijit Basak <av...@gmail.com> wrote:
>
> > 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
> >
> > > [...]

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


Re: [MATH] Build Failure

Posted by Avijit Basak <av...@gmail.com>.
Hi All

       I have identified a few *protected* methods which could be made
*private*. Those are mostly validation methods of input arguments and used
internally. Keeping them as protected won't add much value considering
future extension. I would like to do the modification.
       It would be helpful if anyone can confirm the process of checking in
new code now. Will it be as part of the same PR(#200) with a new commit?
Would the commit message remain the same as earlier?

Thanks & Regards
--Avijit Basak

On Sun, 2 Jan 2022 at 19:05, Avijit Basak <av...@gmail.com> wrote:

> 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 <gi...@gmail.com>
> wrote:
>
>> Hello.
>>
>> Le lun. 27 déc. 2021 à 16:02, Avijit Basak <av...@gmail.com> 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 <av...@gmail.com>
>> 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 <gi...@gmail.com>
>> > > 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-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
> --
> Avijit Basak
>


-- 
Avijit Basak