Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
The same applies to changing access modifiers. JUnit 5 encourages use of package private everything as it’s the least typing and now supported (as in v5 will reflectively allow access to your test code if it’s not public). — Matt Sicker > On Feb 17, 2022, at 19:59, Gary Gregory wrote: > > On Thu, Feb 17, 2022 at 8:47 PM Itamar C wrote: > >>> On Thu, Feb 17, 2022 at 8:16 PM Gilles Sadowski >>> wrote: >>> >>> Which discussion (since this thread covered more than one subject)? >>> If you mean the "migration to Junit 5" task for [Codec], it's already >>> there.[1] >>> If you mean the method rename (to remove the "test" prefix), then >>> the "dev" ML is where to continue the discussion (and/or start a vote >>> if there is no clear agreement). >>> >>> Regards, >>> Gilles >>> >>> >> Hi. >> >> I was talking about the method rename (to remove the "test" prefix). >> If this ML is the right place to continue the discussion or make a vote, ok >> then. >> > > I am opposed to changing hundreds if not thousands of methods names just > for cosmetic reasons, it is certainly not required to use JUnit 5. > > Gary > > >> Regards, >> Itamar >>
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
On Thu, Feb 17, 2022 at 8:47 PM Itamar C wrote: > On Thu, Feb 17, 2022 at 8:16 PM Gilles Sadowski > wrote: > > > Which discussion (since this thread covered more than one subject)? > > If you mean the "migration to Junit 5" task for [Codec], it's already > > there.[1] > > If you mean the method rename (to remove the "test" prefix), then > > the "dev" ML is where to continue the discussion (and/or start a vote > > if there is no clear agreement). > > > > Regards, > > Gilles > > > > > Hi. > > I was talking about the method rename (to remove the "test" prefix). > If this ML is the right place to continue the discussion or make a vote, ok > then. > I am opposed to changing hundreds if not thousands of methods names just for cosmetic reasons, it is certainly not required to use JUnit 5. Gary > Regards, > Itamar >
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
On Thu, Feb 17, 2022 at 8:16 PM Gilles Sadowski wrote: > Which discussion (since this thread covered more than one subject)? > If you mean the "migration to Junit 5" task for [Codec], it's already > there.[1] > If you mean the method rename (to remove the "test" prefix), then > the "dev" ML is where to continue the discussion (and/or start a vote > if there is no clear agreement). > > Regards, > Gilles > > Hi. I was talking about the method rename (to remove the "test" prefix). If this ML is the right place to continue the discussion or make a vote, ok then. Regards, Itamar
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
Hi.
Le jeu. 17 févr. 2022 à 21:33, Itamar C a écrit :
>
> Hello,
>
> My suggestion: I'll work on the methods without renaming and after the
> migration is completed, if we decide to rename, it's not difficult to
> rename all test methods with a script and put in a new PR.
>
> A simple regexp like
> "^\\s*@Test\\s*\n\\s*(.+)\\s+test(\\w)(\\w+)\\s*\\(.*"
> changing to
> m.group(1) + " " + m.group(2).toLowerCase() + m.group(3) + "("
> would do the trick.
>
> Maybe it's time to create a ticket in Jira for this discussion to move
> there?
Which discussion (since this thread covered more than one subject)?
If you mean the "migration to Junit 5" task for [Codec], it's already
there.[1]
If you mean the method rename (to remove the "test" prefix), then
the "dev" ML is where to continue the discussion (and/or start a vote
if there is no clear agreement).
Regards,
Gilles
[1] https://issues.apache.org/jira/projects/CODEC/issues/CODEC-285
>>> [...]
-
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,
My suggestion: I'll work on the methods without renaming and after the
migration is completed, if we decide to rename, it's not difficult to
rename all test methods with a script and put in a new PR.
A simple regexp like
"^\\s*@Test\\s*\n\\s*(.+)\\s+test(\\w)(\\w+)\\s*\\(.*"
changing to
m.group(1) + " " + m.group(2).toLowerCase() + m.group(3) + "("
would do the trick.
Maybe it's time to create a ticket in Jira for this discussion to move
there?
Itamar
On Thu, Feb 17, 2022 at 3:28 PM Gilles Sadowski
wrote:
> Hello.
>
> Le jeu. 17 févr. 2022 à 16:18, Gary Gregory a
> écrit :
> >
> > Well, it is explicitly in the sense that I would guess that 95% of the
> test
> > methods in Commons follows that style and that one our documented
> > guidelines is "follow the style of the file you are editing".
>
> When migrating to the newer Junit, the "same style" rule is
> intentionally broken; hence it is *not* obvious that one should
> not also change the method name.
> It certainly would not hurt to add a sentence to that effect, and
> it would avoid repeating ourselves.
>
> Gilles
>
> >
> > Gary
> >
> > On Thu, Feb 17, 2022, 09:16 Gilles Sadowski
> wrote:
> >
> > > Hello.
> > >
> > > Le jeu. 17 févr. 2022 à 13:11, Gary Gregory a
> > > écrit :
> > > >
> > > > I have encountered what Sebb mentions more than once, I do like the
> > > "test"
> > > > prefix to make it obvious what is and is not intended to be a test.
> Same
> > > > reason I like to make test methods public: clear intent. I know
> Junit 5
> > > > proposes to change these conventions, the benefit do not outweigh the
> > > > convention we use in Commons today for me.
> > >
> > > OK.
> > > But shouldn't we make that explicit somewhere (or is it already?), in
> > > order to let people know that we considered it and made a choice,
> > > (thus reducing the chance that a contribution is based on another
> > > convention that's perhaps becoming more natural for new developers)?
> > >
> > > Thanks,
> > > Gilles
> > >
> > > > > > [...]
>
> -
> 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 jeu. 17 févr. 2022 à 16:18, Gary Gregory a écrit : > > Well, it is explicitly in the sense that I would guess that 95% of the test > methods in Commons follows that style and that one our documented > guidelines is "follow the style of the file you are editing". When migrating to the newer Junit, the "same style" rule is intentionally broken; hence it is *not* obvious that one should not also change the method name. It certainly would not hurt to add a sentence to that effect, and it would avoid repeating ourselves. Gilles > > Gary > > On Thu, Feb 17, 2022, 09:16 Gilles Sadowski wrote: > > > Hello. > > > > Le jeu. 17 févr. 2022 à 13:11, Gary Gregory a > > écrit : > > > > > > I have encountered what Sebb mentions more than once, I do like the > > "test" > > > prefix to make it obvious what is and is not intended to be a test. Same > > > reason I like to make test methods public: clear intent. I know Junit 5 > > > proposes to change these conventions, the benefit do not outweigh the > > > convention we use in Commons today for me. > > > > OK. > > But shouldn't we make that explicit somewhere (or is it already?), in > > order to let people know that we considered it and made a choice, > > (thus reducing the chance that a contribution is based on another > > convention that's perhaps becoming more natural for new developers)? > > > > Thanks, > > Gilles > > > > > > > [...] - 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 [...])
Well, it is explicitly in the sense that I would guess that 95% of the test methods in Commons follows that style and that one our documented guidelines is "follow the style of the file you are editing". Gary On Thu, Feb 17, 2022, 09:16 Gilles Sadowski wrote: > Hello. > > Le jeu. 17 févr. 2022 à 13:11, Gary Gregory a > écrit : > > > > I have encountered what Sebb mentions more than once, I do like the > "test" > > prefix to make it obvious what is and is not intended to be a test. Same > > reason I like to make test methods public: clear intent. I know Junit 5 > > proposes to change these conventions, the benefit do not outweigh the > > convention we use in Commons today for me. > > OK. > But shouldn't we make that explicit somewhere (or is it already?), in > order to let people know that we considered it and made a choice, > (thus reducing the chance that a contribution is based on another > convention that's perhaps becoming more natural for new developers)? > > Thanks, > Gilles > > > > > [...] > > - > 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 jeu. 17 févr. 2022 à 13:11, Gary Gregory a écrit : > > I have encountered what Sebb mentions more than once, I do like the "test" > prefix to make it obvious what is and is not intended to be a test. Same > reason I like to make test methods public: clear intent. I know Junit 5 > proposes to change these conventions, the benefit do not outweigh the > convention we use in Commons today for me. OK. But shouldn't we make that explicit somewhere (or is it already?), in order to let people know that we considered it and made a choice, (thus reducing the chance that a contribution is based on another convention that's perhaps becoming more natural for new developers)? Thanks, Gilles > > > [...] - 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 [...])
I have encountered what Sebb mentions more than once, I do like the "test"
prefix to make it obvious what is and is not intended to be a test. Same
reason I like to make test methods public: clear intent. I know Junit 5
proposes to change these conventions, the benefit do not outweigh the
convention we use in Commons today for me.
Gary
On Thu, Feb 17, 2022, 07:03 sebb wrote:
> On Thu, 17 Feb 2022 at 01:16, Gilles Sadowski
> wrote:
> >
> > Hello.
> >
> > > [...]
> > >
> > > One more practical question: since the tests are not anymore based on
> the
> > > methods name and are indicated by annotations now, I've seen tests
> without
> > > this "test" in the beginning. Looks like common practice (including
> it's
> > > the way it's presented in the JUnit 5 docs). Since I'll dig into all
> the
> > > tests, I can make this change as well. I like this style, because it
> looks
> > > more "clean" to me. What do you think, should I change the methods
> names as
> > > well?
> > >
> >
> > Gary notes the practical reason for not mixing types of changes
> > but you can certainly start a discussion about changing the
> > convention. I agree that, in
> > ---CUT---
> > @Test
> > public void testSomething() {
> > // ...
> > }
> > ---CUT---
> > there is one "test" too many.
>
> Yes and no.
>
> Apart from it being unnecessary to change the name, it can be helpful
> to distinguish top-level test methods from helper methods.
> Makes it easier to check if there is a missing (or spurious) annotation.
>
> > Regards,
> > Gilles
> >
> > > > [...]
> >
> > -
> > 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
>
>
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
On Thu, 17 Feb 2022 at 01:16, Gilles Sadowski wrote:
>
> Hello.
>
> > [...]
> >
> > One more practical question: since the tests are not anymore based on the
> > methods name and are indicated by annotations now, I've seen tests without
> > this "test" in the beginning. Looks like common practice (including it's
> > the way it's presented in the JUnit 5 docs). Since I'll dig into all the
> > tests, I can make this change as well. I like this style, because it looks
> > more "clean" to me. What do you think, should I change the methods names as
> > well?
> >
>
> Gary notes the practical reason for not mixing types of changes
> but you can certainly start a discussion about changing the
> convention. I agree that, in
> ---CUT---
> @Test
> public void testSomething() {
> // ...
> }
> ---CUT---
> there is one "test" too many.
Yes and no.
Apart from it being unnecessary to change the name, it can be helpful
to distinguish top-level test methods from helper methods.
Makes it easier to check if there is a missing (or spurious) annotation.
> Regards,
> Gilles
>
> > > [...]
>
> -
> 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
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
I suggest just migrate 1 or 2 tests first, and create a pr, and we discuss
it there.
Discussing without codes seems hollow.
Gilles Sadowski 于2022年2月17日周四 09:16写道：
> Hello.
>
> > [...]
> >
> > One more practical question: since the tests are not anymore based on the
> > methods name and are indicated by annotations now, I've seen tests
> without
> > this "test" in the beginning. Looks like common practice (including it's
> > the way it's presented in the JUnit 5 docs). Since I'll dig into all the
> > tests, I can make this change as well. I like this style, because it
> looks
> > more "clean" to me. What do you think, should I change the methods names
> as
> > well?
> >
>
> Gary notes the practical reason for not mixing types of changes
> but you can certainly start a discussion about changing the
> convention. I agree that, in
> ---CUT---
> @Test
> public void testSomething() {
> // ...
> }
> ---CUT---
> there is one "test" too many.
>
> Regards,
> Gilles
>
> > > [...]
>
> -
> 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.
> [...]
>
> One more practical question: since the tests are not anymore based on the
> methods name and are indicated by annotations now, I've seen tests without
> this "test" in the beginning. Looks like common practice (including it's
> the way it's presented in the JUnit 5 docs). Since I'll dig into all the
> tests, I can make this change as well. I like this style, because it looks
> more "clean" to me. What do you think, should I change the methods names as
> well?
>
Gary notes the practical reason for not mixing types of changes
but you can certainly start a discussion about changing the
convention. I agree that, in
---CUT---
@Test
public void testSomething() {
// ...
}
---CUT---
there is one "test" too many.
Regards,
Gilles
> > [...]
-
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 [...])
Please do not remove "test" from method names, it's the convention we use today, there is no reason to make a PR noisier than it has to be. Recall that a human has to do a review ;-) TY, Gary On Wed, Feb 16, 2022, 19:28 Itamar C wrote: > > > > > There is too much information and some of them are inconsistent. For > > > example: > > > https://issues.apache.org/jira/projects/CODEC/issues/CODEC-286 is open > > > but > > > https://github.com/apache/commons-codec/pull/40 is closed > > > > > > Maybe there should be a better integration between GH and Jira. Use GH > > > Actions to change the Jira issue status on some events. > > > > I'm not sure I understand what this means in practice, but there > > is already too much noise caused by automatic messages (whose > > information contents is lower than the time it takes to figure that > > out!). > > > For example: when a pull request is merged, the final commit can include in > the comment section some kind of keyword like "CLOSE-JIRA-CODEC-286" and a > GitHub Action automatically closes the JIRA issue associated. > > Commons VFS needs help migrating to Junit 5. It still has tests on Junit 3. > > > Let's do one step at a time. If everything goes well on CODEC, I can look > into VFS. =) > > IntelliJ has a useful feature for helping automate migration of JUnit > > tests. Works wherever you have tests that don't use rules or > parameterized > > tests (those need to be manually migrated still). > > > Thanks for the tip. I'll look into it. > > One more practical question: since the tests are not anymore based on the > methods name and are indicated by annotations now, I've seen tests without > this "test" in the beginning. Looks like common practice (including it's > the way it's presented in the JUnit 5 docs). Since I'll dig into all the > tests, I can make this change as well. I like this style, because it looks > more "clean" to me. What do you think, should I change the methods names as > well? > > Regards, > > Itamar > > > On Wed, Feb 16, 2022 at 3:15 PM Gary Gregory > wrote: > > > Commons VFS needs help migrating to Junit 5. It still has tests on Junit > 3. > > > > Gary > > > > On Wed, Feb 16, 2022, 13:11 Matt Sicker wrote: > > > > > IntelliJ has a useful feature for helping automate migration of JUnit > > > tests. Works wherever you have tests that don't use rules or > > > parameterized tests (those need to be manually migrated still). > > > > > > On Wed, Feb 16, 2022 at 9:17 AM Alex Herbert > > > > wrote: > > > > > > > > On Wed, 16 Feb 2022 at 14:30, Gilles Sadowski > > > wrote: > > > > > > I've finally found that CODEC-285 is an issue that maybe I can > help > > > > > > (Upgrade to JUnit v5.6.0). But there are already 4 PRs there. I'm > > > not sure > > > > > > from where I should start: create a branch from the master or > from > > > some > > > > > > branch in those PRs? Starting from the master it's possible to > have > > > > > > conflicts when merging all PRs. My plan is really to convert > *all* > > > tests in > > > > > > CODEC to Junit 5. Can I do it in a single massive PR or should I > > > create a > > > > > > PR for each package? > > > > > > > > > > A good start for another post (changing the "Subject:" line). > > > > > > > > This has been done before in a single massive PR, e.g. for CSV [1]. > > > > > > > > It requires a change to use the JUnit5 pom, then a find and replace > of > > > > Test and Assert -> Assertions. The later requires swapping the order > > > > of all messages to Assert. > > > > > > > > Things to watch out for are: > > > > > > > > - Any assertions that compare double values with a delta of zero. The > > > > delta can be removed unless comparing +0.0 and -0.0. > > > > - Any string formatted messages can be replaced with lambdas > > > > - The try-catch pattern can be replaced with Assertions.assertThrows > > > > > > > > You can go ahead and start a PR on this and see how it goes. It does > > > > not have to fix everything but it would be welcomed in any form as > the > > > > newer Junit framework indicates a continued commitment to keep the > > > > project active. > > > > > > > > Alex > > > > > > > > [1] https://issues.apache.org/jira/browse/CSV-252 > > > > > > > > - > > > > 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 > > > > > > > > >
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
> > > There is too much information and some of them are inconsistent. For > > example: > > https://issues.apache.org/jira/projects/CODEC/issues/CODEC-286 is open > > but > > https://github.com/apache/commons-codec/pull/40 is closed > > > > Maybe there should be a better integration between GH and Jira. Use GH > > Actions to change the Jira issue status on some events. > I'm not sure I understand what this means in practice, but there > is already too much noise caused by automatic messages (whose > information contents is lower than the time it takes to figure that > out!). For example: when a pull request is merged, the final commit can include in the comment section some kind of keyword like "CLOSE-JIRA-CODEC-286" and a GitHub Action automatically closes the JIRA issue associated. Commons VFS needs help migrating to Junit 5. It still has tests on Junit 3. Let's do one step at a time. If everything goes well on CODEC, I can look into VFS. =) IntelliJ has a useful feature for helping automate migration of JUnit > tests. Works wherever you have tests that don't use rules or parameterized > tests (those need to be manually migrated still). Thanks for the tip. I'll look into it. One more practical question: since the tests are not anymore based on the methods name and are indicated by annotations now, I've seen tests without this "test" in the beginning. Looks like common practice (including it's the way it's presented in the JUnit 5 docs). Since I'll dig into all the tests, I can make this change as well. I like this style, because it looks more "clean" to me. What do you think, should I change the methods names as well? Regards, Itamar On Wed, Feb 16, 2022 at 3:15 PM Gary Gregory wrote: > Commons VFS needs help migrating to Junit 5. It still has tests on Junit 3. > > Gary > > On Wed, Feb 16, 2022, 13:11 Matt Sicker wrote: > > > IntelliJ has a useful feature for helping automate migration of JUnit > > tests. Works wherever you have tests that don't use rules or > > parameterized tests (those need to be manually migrated still). > > > > On Wed, Feb 16, 2022 at 9:17 AM Alex Herbert > > wrote: > > > > > > On Wed, 16 Feb 2022 at 14:30, Gilles Sadowski > > wrote: > > > > > I've finally found that CODEC-285 is an issue that maybe I can help > > > > > (Upgrade to JUnit v5.6.0). But there are already 4 PRs there. I'm > > not sure > > > > > from where I should start: create a branch from the master or from > > some > > > > > branch in those PRs? Starting from the master it's possible to have > > > > > conflicts when merging all PRs. My plan is really to convert *all* > > tests in > > > > > CODEC to Junit 5. Can I do it in a single massive PR or should I > > create a > > > > > PR for each package? > > > > > > > > A good start for another post (changing the "Subject:" line). > > > > > > This has been done before in a single massive PR, e.g. for CSV [1]. > > > > > > It requires a change to use the JUnit5 pom, then a find and replace of > > > Test and Assert -> Assertions. The later requires swapping the order > > > of all messages to Assert. > > > > > > Things to watch out for are: > > > > > > - Any assertions that compare double values with a delta of zero. The > > > delta can be removed unless comparing +0.0 and -0.0. > > > - Any string formatted messages can be replaced with lambdas > > > - The try-catch pattern can be replaced with Assertions.assertThrows > > > > > > You can go ahead and start a PR on this and see how it goes. It does > > > not have to fix everything but it would be welcomed in any form as the > > > newer Junit framework indicates a continued commitment to keep the > > > project active. > > > > > > Alex > > > > > > [1] https://issues.apache.org/jira/browse/CSV-252 > > > > > > - > > > 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 > > > > >
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
Commons VFS needs help migrating to Junit 5. It still has tests on Junit 3. Gary On Wed, Feb 16, 2022, 13:11 Matt Sicker wrote: > IntelliJ has a useful feature for helping automate migration of JUnit > tests. Works wherever you have tests that don't use rules or > parameterized tests (those need to be manually migrated still). > > On Wed, Feb 16, 2022 at 9:17 AM Alex Herbert > wrote: > > > > On Wed, 16 Feb 2022 at 14:30, Gilles Sadowski > wrote: > > > > I've finally found that CODEC-285 is an issue that maybe I can help > > > > (Upgrade to JUnit v5.6.0). But there are already 4 PRs there. I'm > not sure > > > > from where I should start: create a branch from the master or from > some > > > > branch in those PRs? Starting from the master it's possible to have > > > > conflicts when merging all PRs. My plan is really to convert *all* > tests in > > > > CODEC to Junit 5. Can I do it in a single massive PR or should I > create a > > > > PR for each package? > > > > > > A good start for another post (changing the "Subject:" line). > > > > This has been done before in a single massive PR, e.g. for CSV [1]. > > > > It requires a change to use the JUnit5 pom, then a find and replace of > > Test and Assert -> Assertions. The later requires swapping the order > > of all messages to Assert. > > > > Things to watch out for are: > > > > - Any assertions that compare double values with a delta of zero. The > > delta can be removed unless comparing +0.0 and -0.0. > > - Any string formatted messages can be replaced with lambdas > > - The try-catch pattern can be replaced with Assertions.assertThrows > > > > You can go ahead and start a PR on this and see how it goes. It does > > not have to fix everything but it would be welcomed in any form as the > > newer Junit framework indicates a continued commitment to keep the > > project active. > > > > Alex > > > > [1] https://issues.apache.org/jira/browse/CSV-252 > > > > - > > 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 > >
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
IntelliJ has a useful feature for helping automate migration of JUnit tests. Works wherever you have tests that don't use rules or parameterized tests (those need to be manually migrated still). On Wed, Feb 16, 2022 at 9:17 AM Alex Herbert wrote: > > On Wed, 16 Feb 2022 at 14:30, Gilles Sadowski wrote: > > > I've finally found that CODEC-285 is an issue that maybe I can help > > > (Upgrade to JUnit v5.6.0). But there are already 4 PRs there. I'm not sure > > > from where I should start: create a branch from the master or from some > > > branch in those PRs? Starting from the master it's possible to have > > > conflicts when merging all PRs. My plan is really to convert *all* tests > > > in > > > CODEC to Junit 5. Can I do it in a single massive PR or should I create a > > > PR for each package? > > > > A good start for another post (changing the "Subject:" line). > > This has been done before in a single massive PR, e.g. for CSV [1]. > > It requires a change to use the JUnit5 pom, then a find and replace of > Test and Assert -> Assertions. The later requires swapping the order > of all messages to Assert. > > Things to watch out for are: > > - Any assertions that compare double values with a delta of zero. The > delta can be removed unless comparing +0.0 and -0.0. > - Any string formatted messages can be replaced with lambdas > - The try-catch pattern can be replaced with Assertions.assertThrows > > You can go ahead and start a PR on this and see how it goes. It does > not have to fix everything but it would be welcomed in any form as the > newer Junit framework indicates a continued commitment to keep the > project active. > > Alex > > [1] https://issues.apache.org/jira/browse/CSV-252 > > - > 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
Re: [All] Maintenance (Re: [GitHub] [... PR] #104: Maven Wrapper [...])
On Wed, 16 Feb 2022 at 14:30, Gilles Sadowski wrote: > > I've finally found that CODEC-285 is an issue that maybe I can help > > (Upgrade to JUnit v5.6.0). But there are already 4 PRs there. I'm not sure > > from where I should start: create a branch from the master or from some > > branch in those PRs? Starting from the master it's possible to have > > conflicts when merging all PRs. My plan is really to convert *all* tests in > > CODEC to Junit 5. Can I do it in a single massive PR or should I create a > > PR for each package? > > A good start for another post (changing the "Subject:" line). This has been done before in a single massive PR, e.g. for CSV [1]. It requires a change to use the JUnit5 pom, then a find and replace of Test and Assert -> Assertions. The later requires swapping the order of all messages to Assert. Things to watch out for are: - Any assertions that compare double values with a delta of zero. The delta can be removed unless comparing +0.0 and -0.0. - Any string formatted messages can be replaced with lambdas - The try-catch pattern can be replaced with Assertions.assertThrows You can go ahead and start a PR on this and see how it goes. It does not have to fix everything but it would be welcomed in any form as the newer Junit framework indicates a continued commitment to keep the project active. Alex [1] https://issues.apache.org/jira/browse/CSV-252 - 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 mer. 16 févr. 2022 à 15:05, Itamar C a écrit :
>
> That's my first message on this list, but I've been reading the messages
> for some months.
>
> I'm interested in contributing to Apache Commons, but it was a little
> confusing to find where to help. Some of the issues in Jira are very old,
> but not solved. It's difficult for a newcomer like me to understand if that
> issue is not relevant (and maybe should have been discarded) or if it's
> only a matter of lack of someone to get it and have it done. Maybe using
> some labels, much like it's used in GH, like "help wanted", "bug",
> "enhancement" or even "good first issue".
Well, that this information can be inaccurate also results from
"not enough maintainers".
Help is certainly welcome on that front too, i.e. review JIRA
reports and comment there about your findings ("inconsistent",
"already solved", "PR available (and current)", ...).
>
> There is too much information and some of them are inconsistent. For
> example:
> https://issues.apache.org/jira/projects/CODEC/issues/CODEC-286 is open
> but
> https://github.com/apache/commons-codec/pull/40 is closed
>
> Maybe there should be a better integration between GH and Jira. Use GH
> Actions to change the Jira issue status on some events.
I'm not sure I understand what this means in practice, but there
is already too much noise caused by automatic messages (whose
information contents is lower than the time it takes to figure that
out!).
> There are also some issues that were closed and reopened, because there is
> no consensus on what should be done, like CODED-253 [open] (and CODEC-257
> [closed]), about moving from Java 7 to 8.
Oops. :-}
> That's the kind of thing that
> scares newcomers.
"Commons" is a strange beast...
> I'm even afraid that this message can be misinterpreted
> as somehow aggressive. That's not my intention, I only want to give you a
> view from outside.
If you are a user, please consider yourself "inside". :-)
You are welcome to start a discussion on the ML, comment on
your preference about some issue, ...
>
> I've finally found that CODEC-285 is an issue that maybe I can help
> (Upgrade to JUnit v5.6.0). But there are already 4 PRs there. I'm not sure
> from where I should start: create a branch from the master or from some
> branch in those PRs? Starting from the master it's possible to have
> conflicts when merging all PRs. My plan is really to convert *all* tests in
> CODEC to Junit 5. Can I do it in a single massive PR or should I create a
> PR for each package?
A good start for another post (changing the "Subject:" line).
>
> Should I step in on this issue?
Sure. Welcome!
> Can someone guide me in those small doubts
> I have?
Hopefully yes.
Best,
Gilles
>
> Regards,
>
> Itamar Carvalho
>
>
>
>>> [...]
-
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 [...])
That's my first message on this list, but I've been reading the messages for some months. I'm interested in contributing to Apache Commons, but it was a little confusing to find where to help. Some of the issues in Jira are very old, but not solved. It's difficult for a newcomer like me to understand if that issue is not relevant (and maybe should have been discarded) or if it's only a matter of lack of someone to get it and have it done. Maybe using some labels, much like it's used in GH, like "help wanted", "bug", "enhancement" or even "good first issue". There is too much information and some of them are inconsistent. For example: https://issues.apache.org/jira/projects/CODEC/issues/CODEC-286 is open but https://github.com/apache/commons-codec/pull/40 is closed Maybe there should be a better integration between GH and Jira. Use GH Actions to change the Jira issue status on some events. There are also some issues that were closed and reopened, because there is no consensus on what should be done, like CODED-253 [open] (and CODEC-257 [closed]), about moving from Java 7 to 8. That's the kind of thing that scares newcomers. I'm even afraid that this message can be misinterpreted as somehow aggressive. That's not my intention, I only want to give you a view from outside. I've finally found that CODEC-285 is an issue that maybe I can help (Upgrade to JUnit v5.6.0). But there are already 4 PRs there. I'm not sure from where I should start: create a branch from the master or from some branch in those PRs? Starting from the master it's possible to have conflicts when merging all PRs. My plan is really to convert *all* tests in CODEC to Junit 5. Can I do it in a single massive PR or should I create a PR for each package? Should I step in on this issue? Can someone guide me in those small doubts I have? Regards, Itamar Carvalho On Mon, Feb 14, 2022 at 1:38 PM Gilles Sadowski wrote: > 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 [...])
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 > >
