Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
Le lun. 14 févr. 2022 à 16:11, Xeno Amess a écrit : > > > Code not actively developed does not attract newcomers. > Well I have to say the reason for "codes not actively developed" is a > strong lack of alive committers, or more detailed, reviewers. In part, yes, but they are the consequence of each other (i.e. a vicious circle). The main cause IMHO, is that we loose[1] the spirit of being dedicated to a project/component. Contributions are "dropped" as PR (usually) without follow-up (either here or on JIRA). > I have still 100+ unsolved prs in commons projects, some of which be 1 or 2 > years ago, but it seems there just are not enough reviewers, and pr lists > in every repo grows longer and longer. That's the downside (in plain view?) of GH for a project that lacks human resources (like "Commons") necessary for trimming the list of PRs in a timely manner. As you said in another comment, the PRs look like a stack; if there is just one active committer, they rapidly become stale (because "master" changes). Yet the OP quite often just lets them rot there. A "dedicated" contributor should follow development, update the PRs, collect them in JIRA, based on the type of issue that they fix. IMHO, that work would establish a natural priority, speed up the review (and become a measure of dedication[2]). > But on the other hand, free reviewers who have both ability and willingness > to review, well, are really lacking, it is the truth. [1] Largely "thanks" to GitHub IMO. [2] Which the number of PRs cannot be by itself. > > Gilles Sadowski 于2022年2月14日周一 22:34写道： > > > Le lun. 14 févr. 2022 à 14:34, Gary Gregory a > > écrit : > > > > > > My guess is that this is a combination of the maturity of the components > > > > The "maturity" rationale is not an explanation; it is a cause. > > Code not actively developed does not attract newcomers. > > It is not an "opinion" anymore; it is backed by the fact that > > "Commons Math" API modernization had stalled on the basis > > of that rationale; yet since the path has been unblocked, work > > on [RNG], [Numbers], [Geometry], [Statistics] and [Math] itself > > demonstrated how much room there was for improving[1] those > > "mature" codes. > > > > Regards, > > Gilles > > > > [1] Thanks to all who did it! > > > > > and people having moved on to jobs or hobbies that no longer requires > > these > > > components. > > > > > > Gary > > > > > >>> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
Hello. Le lun. 14 févr. 2022 à 16:46, Xeno Amess a écrit : > > (sigh) Do you think make some public activities would help? Like helding > some online summer camp or something? Well, there is, at least, GSoC. Yet, AFAIK, there is no prior thinking about how to respond to such initiatives, not even whether to respond.[1] It occurs to me that it is not necessary to be a PMC member, or even a committer, in order to help within GSoC (or just team with newcomers until all the issues with their PR are ironed out). Regards, Gilles [1] https://markmail.org/message/2qckwxw2x4ue36sd - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
(sigh) Do you think make some public activities would help? Like helding some online summer camp or something?
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
> it is a request in a queue And it is actually not a queue, but a mixture of stack and priority queue. When we meet some very important prs like critical bug fix or safety things, we will review them first. But for normal prs, actually we treat prs like stack. Two prs with the same importance, one be 2 years ago, another be 2 days ago, then actually we will automatically pick the 2 days ago one first. Xeno Amess 于2022年2月14日周一 23:42写道： > > Remember that creating a PR is not a guarantee of anything, it is a > request > in a queue, a queue managed by volunteers. > > Yes, legally and mortally it is. > But if we get more reviewers I think it will help the repos be more > popular. > The tough thing is I totally have no idea how to get us some more good > reviewers. > > Gary Gregory 于2022年2月14日周一 23:37写道： > >> Remember that creating a PR is not a guarantee of anything, it is a >> request >> in a queue, a queue managed by volunteers. >> >> Gary >> >> On Mon, Feb 14, 2022, 10:12 Xeno Amess wrote: >> >> > > Code not actively developed does not attract newcomers. >> > Well I have to say the reason for "codes not actively developed" is a >> > strong lack of alive committers, or more detailed, reviewers. >> > I have still 100+ unsolved prs in commons projects, some of which be 1 >> or 2 >> > years ago, but it seems there just are not enough reviewers, and pr >> lists >> > in every repo grows longer and longer. >> > But on the other hand, free reviewers who have both ability and >> willingness >> > to review, well, are really lacking, it is the truth. >> > >> > Gilles Sadowski 于2022年2月14日周一 22:34写道： >> > >> > > Le lun. 14 févr. 2022 à 14:34, Gary Gregory >> a >> > > écrit : >> > > > >> > > > My guess is that this is a combination of the maturity of the >> > components >> > > >> > > The "maturity" rationale is not an explanation; it is a cause. >> > > Code not actively developed does not attract newcomers. >> > > It is not an "opinion" anymore; it is backed by the fact that >> > > "Commons Math" API modernization had stalled on the basis >> > > of that rationale; yet since the path has been unblocked, work >> > > on [RNG], [Numbers], [Geometry], [Statistics] and [Math] itself >> > > demonstrated how much room there was for improving[1] those >> > > "mature" codes. >> > > >> > > Regards, >> > > Gilles >> > > >> > > [1] Thanks to all who did it! >> > > >> > > > and people having moved on to jobs or hobbies that no longer >> requires >> > > these >> > > > components. >> > > > >> > > > Gary >> > > > >> > > >>> [...] >> > > >> > > - >> > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> > > For additional commands, e-mail: dev-h...@commons.apache.org >> > > >> > > >> > >> >
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
> Remember that creating a PR is not a guarantee of anything, it is a request in a queue, a queue managed by volunteers. Yes, legally and mortally it is. But if we get more reviewers I think it will help the repos be more popular. The tough thing is I totally have no idea how to get us some more good reviewers. Gary Gregory 于2022年2月14日周一 23:37写道： > Remember that creating a PR is not a guarantee of anything, it is a request > in a queue, a queue managed by volunteers. > > Gary > > On Mon, Feb 14, 2022, 10:12 Xeno Amess wrote: > > > > Code not actively developed does not attract newcomers. > > Well I have to say the reason for "codes not actively developed" is a > > strong lack of alive committers, or more detailed, reviewers. > > I have still 100+ unsolved prs in commons projects, some of which be 1 > or 2 > > years ago, but it seems there just are not enough reviewers, and pr lists > > in every repo grows longer and longer. > > But on the other hand, free reviewers who have both ability and > willingness > > to review, well, are really lacking, it is the truth. > > > > Gilles Sadowski 于2022年2月14日周一 22:34写道： > > > > > Le lun. 14 févr. 2022 à 14:34, Gary Gregory a > > > écrit : > > > > > > > > My guess is that this is a combination of the maturity of the > > components > > > > > > The "maturity" rationale is not an explanation; it is a cause. > > > Code not actively developed does not attract newcomers. > > > It is not an "opinion" anymore; it is backed by the fact that > > > "Commons Math" API modernization had stalled on the basis > > > of that rationale; yet since the path has been unblocked, work > > > on [RNG], [Numbers], [Geometry], [Statistics] and [Math] itself > > > demonstrated how much room there was for improving[1] those > > > "mature" codes. > > > > > > Regards, > > > Gilles > > > > > > [1] Thanks to all who did it! > > > > > > > and people having moved on to jobs or hobbies that no longer requires > > > these > > > > components. > > > > > > > > Gary > > > > > > > >>> [...] > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > >
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
Remember that creating a PR is not a guarantee of anything, it is a request in a queue, a queue managed by volunteers. Gary On Mon, Feb 14, 2022, 10:12 Xeno Amess wrote: > > Code not actively developed does not attract newcomers. > Well I have to say the reason for "codes not actively developed" is a > strong lack of alive committers, or more detailed, reviewers. > I have still 100+ unsolved prs in commons projects, some of which be 1 or 2 > years ago, but it seems there just are not enough reviewers, and pr lists > in every repo grows longer and longer. > But on the other hand, free reviewers who have both ability and willingness > to review, well, are really lacking, it is the truth. > > Gilles Sadowski 于2022年2月14日周一 22:34写道： > > > Le lun. 14 févr. 2022 à 14:34, Gary Gregory a > > écrit : > > > > > > My guess is that this is a combination of the maturity of the > components > > > > The "maturity" rationale is not an explanation; it is a cause. > > Code not actively developed does not attract newcomers. > > It is not an "opinion" anymore; it is backed by the fact that > > "Commons Math" API modernization had stalled on the basis > > of that rationale; yet since the path has been unblocked, work > > on [RNG], [Numbers], [Geometry], [Statistics] and [Math] itself > > demonstrated how much room there was for improving[1] those > > "mature" codes. > > > > Regards, > > Gilles > > > > [1] Thanks to all who did it! > > > > > and people having moved on to jobs or hobbies that no longer requires > > these > > > components. > > > > > > Gary > > > > > >>> [...] > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
> Code not actively developed does not attract newcomers. Well I have to say the reason for "codes not actively developed" is a strong lack of alive committers, or more detailed, reviewers. I have still 100+ unsolved prs in commons projects, some of which be 1 or 2 years ago, but it seems there just are not enough reviewers, and pr lists in every repo grows longer and longer. But on the other hand, free reviewers who have both ability and willingness to review, well, are really lacking, it is the truth. Gilles Sadowski 于2022年2月14日周一 22:34写道： > Le lun. 14 févr. 2022 à 14:34, Gary Gregory a > écrit : > > > > My guess is that this is a combination of the maturity of the components > > The "maturity" rationale is not an explanation; it is a cause. > Code not actively developed does not attract newcomers. > It is not an "opinion" anymore; it is backed by the fact that > "Commons Math" API modernization had stalled on the basis > of that rationale; yet since the path has been unblocked, work > on [RNG], [Numbers], [Geometry], [Statistics] and [Math] itself > demonstrated how much room there was for improving[1] those > "mature" codes. > > Regards, > Gilles > > [1] Thanks to all who did it! > > > and people having moved on to jobs or hobbies that no longer requires > these > > components. > > > > Gary > > > >>> [...] > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
Le lun. 14 févr. 2022 à 14:34, Gary Gregory a écrit : > > My guess is that this is a combination of the maturity of the components The "maturity" rationale is not an explanation; it is a cause. Code not actively developed does not attract newcomers. It is not an "opinion" anymore; it is backed by the fact that "Commons Math" API modernization had stalled on the basis of that rationale; yet since the path has been unblocked, work on [RNG], [Numbers], [Geometry], [Statistics] and [Math] itself demonstrated how much room there was for improving[1] those "mature" codes. Regards, Gilles [1] Thanks to all who did it! > and people having moved on to jobs or hobbies that no longer requires these > components. > > Gary > >>> [...] - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
My guess is that this is a combination of the maturity of the components and people having moved on to jobs or hobbies that no longer requires these components. Gary On Mon, Feb 14, 2022, 08:32 Xeno Amess wrote: > > [2] Backed by the numbers provided the project's report to the ASF > board (where the number of "committers" is utterly misleading wrt > its actual effect on maintenance capacity). > > I'm also interested in why there are so many committers while small > amounts of which really do commit during these years... Are they just > retired or become too busy to commit or something? > > Gilles Sadowski 于2022年2月14日周一 19:31写道： > > > Hello. > > > > Le lun. 14 févr. 2022 à 00:23, GitBox a écrit : > > > > > > > > > nhojpatrick commented on pull request #104: > > > URL: > > https://github.com/apache/commons-codec/pull/104#issuecomment-1038472244 > > > > > > > > >@garydgregory i agree it could be considered clutter. If all > projects > > are kept active current it's never an issue. > > >From experience I'm coming from working with dead or hibernated > > projects, when moving company/job/team/project and having to kick start > > something building. It use to work on the cicd server, but someone > updated > > that to a newer maven version or java version so the project i'm working > > doesn't work anymore. So 1st things I now always setup is maven wrapper > > (takari before it was merge) and enforcer, so the project itself knows > was > > it was last configured to build under. > > > > > > > Thanks for the feedback. > > It has been my understanding that one purpose of "Commons" > > (and any other community project) is to gather (human) resources > > in order to keep the code bases "alive".[1] > > So IMHO, the top priority should be to extend the maintenance > > team(s). The shift of focus from the community's still official forum > > (this ML) to GitHub is aggravating[2][3] the maintenance problem: > > Most components now rely on less than the 3 required votes for > > release, and can thus easily become "attic" candidates. > > > > Regards, > > Gilles > > > > [1] The concept of "mature" library (often floated around here) has > > been proven (in light of the JDK evolutions) to be a hindrance rather > > than the sine qua non of user code stability. > > [2] Backed by the numbers provided the project's report to the ASF > > board (where the number of "committers" is utterly misleading wrt > > its actual effect on maintenance capacity). > > [3] Despite other advantages (not TBD in this thread) brought by the > > platform (mainly for itself IMO). > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
> [2] Backed by the numbers provided the project's report to the ASF board (where the number of "committers" is utterly misleading wrt its actual effect on maintenance capacity). I'm also interested in why there are so many committers while small amounts of which really do commit during these years... Are they just retired or become too busy to commit or something? Gilles Sadowski 于2022年2月14日周一 19:31写道： > Hello. > > Le lun. 14 févr. 2022 à 00:23, GitBox a écrit : > > > > > > nhojpatrick commented on pull request #104: > > URL: > https://github.com/apache/commons-codec/pull/104#issuecomment-1038472244 > > > > > >@garydgregory i agree it could be considered clutter. If all projects > are kept active current it's never an issue. > >From experience I'm coming from working with dead or hibernated > projects, when moving company/job/team/project and having to kick start > something building. It use to work on the cicd server, but someone updated > that to a newer maven version or java version so the project i'm working > doesn't work anymore. So 1st things I now always setup is maven wrapper > (takari before it was merge) and enforcer, so the project itself knows was > it was last configured to build under. > > > > Thanks for the feedback. > It has been my understanding that one purpose of "Commons" > (and any other community project) is to gather (human) resources > in order to keep the code bases "alive".[1] > So IMHO, the top priority should be to extend the maintenance > team(s). The shift of focus from the community's still official forum > (this ML) to GitHub is aggravating[2][3] the maintenance problem: > Most components now rely on less than the 3 required votes for > release, and can thus easily become "attic" candidates. > > Regards, > Gilles > > [1] The concept of "mature" library (often floated around here) has > been proven (in light of the JDK evolutions) to be a hindrance rather > than the sine qua non of user code stability. > [2] Backed by the numbers provided the project's report to the ASF > board (where the number of "committers" is utterly misleading wrt > its actual effect on maintenance capacity). > [3] Despite other advantages (not TBD in this thread) brought by the > platform (mainly for itself IMO). > > - > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
[All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
Hello. Le lun. 14 févr. 2022 à 00:23, GitBox a écrit : > > > nhojpatrick commented on pull request #104: > URL: https://github.com/apache/commons-codec/pull/104#issuecomment-1038472244 > > >@garydgregory i agree it could be considered clutter. If all projects are > kept active current it's never an issue. >From experience I'm coming from working with dead or hibernated projects, > when moving company/job/team/project and having to kick start something > building. It use to work on the cicd server, but someone updated that to a > newer maven version or java version so the project i'm working doesn't work > anymore. So 1st things I now always setup is maven wrapper (takari before it > was merge) and enforcer, so the project itself knows was it was last > configured to build under. > Thanks for the feedback. It has been my understanding that one purpose of "Commons" (and any other community project) is to gather (human) resources in order to keep the code bases "alive".[1] So IMHO, the top priority should be to extend the maintenance team(s). The shift of focus from the community's still official forum (this ML) to GitHub is aggravating[2][3] the maintenance problem: Most components now rely on less than the 3 required votes for release, and can thus easily become "attic" candidates. Regards, Gilles [1] The concept of "mature" library (often floated around here) has been proven (in light of the JDK evolutions) to be a hindrance rather than the sine qua non of user code stability. [2] Backed by the numbers provided the project's report to the ASF board (where the number of "committers" is utterly misleading wrt its actual effect on maintenance capacity). [3] Despite other advantages (not TBD in this thread) brought by the platform (mainly for itself IMO). - To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
Re: [Math] Review of "genetic algorithm" module
Hello.
Le lun. 14 févr. 2022 à 08:03, Avijit Basak a écrit :
>
> Hi All
>
> Thanks for the review comments. Please find my comments below.
>
> (1)
> [...]
>
> (2)
> >The "GeneticException" class seems to mostly deal with "illegal"
> >arguments; hence it should be a subclass of the JDK's standard
> >"IllegalArgumentException" (and be renamed accordingly).
> >If other condition types are needed, then another internal class
> >should be defined with the corresponding standard semantics.
> --IMHO if we think of a single exception class we should extend it only
> from RuntimeException.
"single exception class" is not a requirement (it cannot be since
we agreed some time ago that it was better to align with the JDK's
delineation of error conditions (IAE, NPE, ILSE, AE, ...).
> If we think of multiple exception classes in one
> module we may need to think of a base exception class. Other classes would
> extend the same.
Please no. We'd taken that approach in "Commons Math" (cf.
base class now in module "commons-math-legacy-exception"),
as I've mentioned already IIRC: It was a failed experiment IMO.
[For more details, please refer to the archive of the "dev" ML.]
> The approach mentioned above would mix up these two.
> Please share your opinion regarding this.
Eventually, all new components ([RNG], [Number], [Geometry], ...)
adopted the simple approach of non-public API (ideally private
or package-private) exception classes only for the developer's
use (and the purpose of which is limited to avoiding duplication).
>
> >[Exception messages need review for spelling and formatting.]
> -- It will be really helpful if you can point out some specific examples.
We can fix this when the PR has reached some stability.
>
> (3)
> >IMO Javadoc should avoid redundant phrases like "This class" as
> >the first words of a class description.
> --Refractored the javadoc comments. Please review and mention if you need
> any further changes.
I've not looked yet, but thanks for taking it into account.
Similarly to the previous point, these clean-ups can happen later.
> >A similar remark holds for fields in "GeneticException" class: Since
> >the name of the field is self-documenting, duplication in the Javadoc
> >is visual noise ("Message template" is concise and clear enough).
> --Removal of the javadoc comments produces a checkstyle error.
I did not suggest to remove any Javadoc, only to rephrase it as:
---CUT---
/** "Message template". */
---CUT---
> [...]
>
> (4)
> >Class "ConvergenceListenerRegistry" is generic but its code
> >contains undocumented "@SuppressWarnings" annotations.
> >Moreover, it is a singleton, and not thread-safe.
> >Why should there be such a global "registry"?
> >Since it is only accessed by the "AbstractGeneticAlgorithm" class,
> >it could be defined as a private inner class.
> --Made it a private inner class.
Thanks.
[We should nevertheless address the other issues mentioned in
the above paragraph.]
>
> (5)
> >In class "AbstractGeneticAlgorithm", methods "getCrossoverPolicy"
> >"getMutationPolicy", "getElitismRate" are public, yet they are only
> >ever called by a subclass.
> --Modified the public to protected.
Thanks.
I nevertheless suspect (as hinted at while mentioning the
expected multi-thread feature) that there is a design issue
here. [I may be wrong, so I'll try to make my point stronger
after a more in-depth review.]
>
> (6)
> >Why support inheritance for "AbstractGeneticAlgorithm"?
> >Why would users need their own subclass, rather than call those
> >implemented within the library (currently, "GeneticAlgorithm" and
> >"AdaptiveGeneticAlgorithm")?
> >Couldn't we encapsulate the choice of algorithm in an "enum",
> >similar to "RandomSource" in [RNG].
> >Do I understand correctly that the (only?) difference between the
> >two classes is the ability to adapt crossover and mutation rates?
> -- The difference between GeneticAlgorithm and AdaptiveGeneticAlgorithm is
> the ability to adapt crossover and mutation probability. However, as per
> my understanding enum encapsulation is appropriate with the same set and
> type of constructor arguments, where the arguments can be provided during
> enum declaration. In our case the arguments would be provided by the client
> program and cannot be pre-initialized as part of an enum declaration.
Why not?
A constant rate seems like a (trivial) type of adaptive rate.
>
> (7)
> >The currently available GA implementations are sequential.
> >IIUC, the "nextGeneration" methods should provide an option
> >that processes the population using multiple threads.
> --This needs to be done. However, I would like to address this along with
> parallel GA i.e. convergence of multiple populations together.
The two features (multi-thread vs multiple populations) should
be implemented independently: Users that only need the "basic"
GA should also be able to take advantage of their machine's
multiple CPUs.
[This is related to the design issue which I
