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 <[email protected]> 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 <[email protected]> 于2022年2月14日周一 19:31写道： > > > Hello. > > > > Le lun. 14 févr. 2022 à 00:23, GitBox <[email protected]> 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: [email protected] > > For additional commands, e-mail: [email protected] > > > > >
