Re: Yearly JIRA cleanup
On Mon, Dec 9, 2019 at 3:18 PM Michael Osipov wrote: > > Am 2019-12-08 um 18:08 schrieb Elliotte Rusty Harold: > > Please don't. There are certainly some real and important issues in > > there. More importantly, users spent a great deal of effort and time > > to file those. Bulk closing them tells those users we don't value > > their feedback or effort. It is useful to triage these issues and > > consider them individually. Doubtless many of these issues are already > > fixed, moot, or things we expressly chose not to do. However this > > should be decided case by case. We can't simply close our eyes and > > pretend they're all irrelevant. > > Hi Elliotte, > We have almost 2000 open issues. How would you reasonably sieve between > them? even if you allocate 10 min per ticket, you would need two months > of work to triage them. > Use the time we have to fix as much as we can. Leave the rest open. Some will never be touched but some will be when someone encounters the same problem and finds the bug again. It's better to leave it open and unaddressed than to close it without giving it a fair look. As to time spent triaging, it's worth considering whether permissions could be opened up further. Right now, almost anyone can file a bug but few people can resolve and close them. I can't, for example, even when I see one that's clearly no longer relevant. :-( -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Yearly JIRA cleanup
Take your time, you have at least three weeks. Am 2019-12-08 um 18:23 schrieb Tibor Digana: Hi Michael, What's up :-) Thx for making the list of issues. Pls give me one day to see it completely. I will get back to you tomorrow. Cheers Tibor17 On Sun, Dec 8, 2019 at 6:08 PM Elliotte Rusty Harold wrote: Please don't. There are certainly some real and important issues in there. More importantly, users spent a great deal of effort and time to file those. Bulk closing them tells those users we don't value their feedback or effort. It is useful to triage these issues and consider them individually. Doubtless many of these issues are already fixed, moot, or things we expressly chose not to do. However this should be decided case by case. We can't simply close our eyes and pretend they're all irrelevant. On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov wrote: Hi folks, after at least one year of silence, I'd like to perform another JIRA issue cleanup for issues which have been not touched for more than three years. Query: https://issues.apache.org/jira/issues/?filter=12333204&jql=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC Stats: 567 issues not touched for more than three years of which * 68 have fix version set * 36 were already reopened, should they be excluded? * 1 in progress by Karl Type breakdown: * 200 bugs * 164 improvements * 72 new features * 6 subtasks * 13 tasks * 12 wishes If there are issues still valid for you please leave a comment on the issue and they will not appear in the query anymore. Please also raise your voice if you have anything to discuss. If the issue is not modified or no objection has been raised, I will autoclose those issues with a comment by 2019-12-30. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org -- Elliotte Rusty Harold elh...@ibiblio.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Yearly JIRA cleanup
Am 2019-12-08 um 18:08 schrieb Elliotte Rusty Harold: Please don't. There are certainly some real and important issues in there. More importantly, users spent a great deal of effort and time to file those. Bulk closing them tells those users we don't value their feedback or effort. It is useful to triage these issues and consider them individually. Doubtless many of these issues are already fixed, moot, or things we expressly chose not to do. However this should be decided case by case. We can't simply close our eyes and pretend they're all irrelevant. Hi Elliotte, I share your concerns. I do traverse through tickets once in a while and check for samples projects. Please also feel free to go through the list and update them. At the end we need to be honest. I.e., if we weren't to triage them within three years, we likely never won't. We honestly tell that we acknowledge the issue, but are simply unable to do anything fruitful. We have almost 2000 open issues. How would you reasonably sieve between them? even if you allocate 10 min per ticket, you would need two months of work to triage them. Regards, Michael On Sun, Dec 8, 2019 at 7:50 AM Michael Osipov wrote: Hi folks, after at least one year of silence, I'd like to perform another JIRA issue cleanup for issues which have been not touched for more than three years. Query: https://issues.apache.org/jira/issues/?filter=12333204&jql=category%20%3D%20Maven%20AND%20updated%20%3C%3D%20-153w%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20issuetype%20DESC%2C%20created%20DESC Stats: 567 issues not touched for more than three years of which * 68 have fix version set * 36 were already reopened, should they be excluded? * 1 in progress by Karl Type breakdown: * 200 bugs * 164 improvements * 72 new features * 6 subtasks * 13 tasks * 12 wishes If there are issues still valid for you please leave a comment on the issue and they will not appear in the query anymore. Please also raise your voice if you have anything to discuss. If the issue is not modified or no objection has been raised, I will autoclose those issues with a comment by 2019-12-30. Michael - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: Integration Tests of Maven Core
The community has no/few resources thus for sure we need to think to it first. If we change the current setup and make it too complex we know that it will be useless and people won't use it (I'm sure that Jason isn't the only one to have done such kind consultancy). The idea of having tags/branches could be an option if it's really a problem for the community and there is a gain to remove them. I am just not sure about the gain. They are skipped. Will we reduce the build time without them ? On Mon, Dec 9, 2019 at 11:09 AM Tibor Digana wrote: > Having some comparison tests might be good to have especially if an old > feature is maintained in the master. > I am not saying that the old behavior was right. A fix can be backported > too. > > We should answer some questions before making any decision: > > 1. Do we have the effort to maintain the old versions? > 2. We are testing the development version. > Would we branch the old Tags, maintain them and submit their DIST to > the common/current ITs? > 3. Would we rather branch the ITs together with the Maven-Core? (ITs_branch > : Maven_branch = 1:1) > > I think the effort was discussed a year ago and we decided to deprecate > some versions. > 4. So the non-deprecated versions should be maintained and tested? > > On Mon, Dec 9, 2019 at 10:22 AM Arnaud Héritier > wrote: > > > I agree with what Jason shared. > > It's a reality. Probably a sad one but a lot of users are still running > on > > ancient version of Maven (didn't we have a discussion recently about the > > minimum version of Java to support ?) > > There are some kind of business where you don't touch what is doing the > > job. It is especially true when you outsource the maintenance of your > > software. > > > > Having a separate repository and such big referential of tests is from my > > POV one of the best thing done in the project. > > Having a separate repo avoids that you refactor a test with the codebase > > and thus you have to explicitly update the IT if you change something. > > Having the whole history is helping to maintain old versions and even if > > it's not done by us (the community) it is useful for others > > > > On Mon, Dec 9, 2019 at 8:40 AM Enrico Olivelli > > wrote: > > > > > Karl, > > > In my opinion I would like to drop anything that is not useful. > > > > > > I would also like to merge the integration tests repository with the > > maven > > > core repository, this way it is clear that the ITs are for the same > > > version. > > > > > > Can you tell more about the reasons behind having two separate repos? > > > > > > Enrico > > > > > > Il lun 9 dic 2019, 07:59 Jason van Zyl ha scritto: > > > > > > > Please don’t ever remove any of the integration tests. If they don’t > > > apply > > > > to specific versions they are skipped as you see and there’s no harm. > > > > > > > > They serve as a historical record of what features work in a > particular > > > > version. I’ve not done specific Maven work for any customer recently, > > but > > > > it has happened where in a highly regulated industry (nuclear, > > aerospace) > > > > changes are prohibitively expensive and so no one wants to upgrade > > > anything > > > > especially build tools. They will make the minimal patch from > anything > > > > upstream to make their changes work. I’ve helped consultants make > small > > > > patches in Maven, and used the integration tests to verify everything > > > else > > > > worked. > > > > > > > > Yes, they will always be in the history but I can’t imagine it would > be > > > > very nice for someone in that situation to go hunting through the > > history > > > > to bring back tests in order to verify a change. I think we would all > > be > > > > pretty shocked how many people still actually use Maven 2.x. The > > support > > > > cycle on things like airplanes is upwards of 50 years and no one will > > > > change a thing if they don’t have to. I’m sure there’s lots of Maven > > 1.x > > > > and Ant in a bunch of nooks and crannies for that very reason. > Didn’t > > > > someone just post about writing a book about Maven 2.x? :-) > > > > > > > > JvZ > > > > > > > > > On Dec 8, 2019, at 2:10 PM, Karl Heinz Marbaise > > > > > wrote: > > > > > > > > > > Hi, > > > > > I'm diving a little bit into the integration tests of maven core... > > > > > > > > > > and I realized that at the moment this list of IT's is SKIPPED > > > > > based on the version of Maven Core: > > > > > > > > > > > mng5889FindBasedir(MvnFileLongOptionModule).SKIPPED - > > > > > Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1) > > > > > > mng5889FindBasedir(MvnFileShortOptionModule)SKIPPED - > > > > > Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1) > > > > > > mng5889FindBasedir(MvnFileShortOption)..SKIPPED - > > > > > Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1) > > > > > > mng5889FindBasedir(MvnFileLongOption)...SKIPPED - > > > > >
Re: Integration Tests of Maven Core
Having some comparison tests might be good to have especially if an old feature is maintained in the master. I am not saying that the old behavior was right. A fix can be backported too. We should answer some questions before making any decision: 1. Do we have the effort to maintain the old versions? 2. We are testing the development version. Would we branch the old Tags, maintain them and submit their DIST to the common/current ITs? 3. Would we rather branch the ITs together with the Maven-Core? (ITs_branch : Maven_branch = 1:1) I think the effort was discussed a year ago and we decided to deprecate some versions. 4. So the non-deprecated versions should be maintained and tested? On Mon, Dec 9, 2019 at 10:22 AM Arnaud Héritier wrote: > I agree with what Jason shared. > It's a reality. Probably a sad one but a lot of users are still running on > ancient version of Maven (didn't we have a discussion recently about the > minimum version of Java to support ?) > There are some kind of business where you don't touch what is doing the > job. It is especially true when you outsource the maintenance of your > software. > > Having a separate repository and such big referential of tests is from my > POV one of the best thing done in the project. > Having a separate repo avoids that you refactor a test with the codebase > and thus you have to explicitly update the IT if you change something. > Having the whole history is helping to maintain old versions and even if > it's not done by us (the community) it is useful for others > > On Mon, Dec 9, 2019 at 8:40 AM Enrico Olivelli > wrote: > > > Karl, > > In my opinion I would like to drop anything that is not useful. > > > > I would also like to merge the integration tests repository with the > maven > > core repository, this way it is clear that the ITs are for the same > > version. > > > > Can you tell more about the reasons behind having two separate repos? > > > > Enrico > > > > Il lun 9 dic 2019, 07:59 Jason van Zyl ha scritto: > > > > > Please don’t ever remove any of the integration tests. If they don’t > > apply > > > to specific versions they are skipped as you see and there’s no harm. > > > > > > They serve as a historical record of what features work in a particular > > > version. I’ve not done specific Maven work for any customer recently, > but > > > it has happened where in a highly regulated industry (nuclear, > aerospace) > > > changes are prohibitively expensive and so no one wants to upgrade > > anything > > > especially build tools. They will make the minimal patch from anything > > > upstream to make their changes work. I’ve helped consultants make small > > > patches in Maven, and used the integration tests to verify everything > > else > > > worked. > > > > > > Yes, they will always be in the history but I can’t imagine it would be > > > very nice for someone in that situation to go hunting through the > history > > > to bring back tests in order to verify a change. I think we would all > be > > > pretty shocked how many people still actually use Maven 2.x. The > support > > > cycle on things like airplanes is upwards of 50 years and no one will > > > change a thing if they don’t have to. I’m sure there’s lots of Maven > 1.x > > > and Ant in a bunch of nooks and crannies for that very reason. Didn’t > > > someone just post about writing a book about Maven 2.x? :-) > > > > > > JvZ > > > > > > > On Dec 8, 2019, at 2:10 PM, Karl Heinz Marbaise > > > wrote: > > > > > > > > Hi, > > > > I'm diving a little bit into the integration tests of maven core... > > > > > > > > and I realized that at the moment this list of IT's is SKIPPED > > > > based on the version of Maven Core: > > > > > > > > mng5889FindBasedir(MvnFileLongOptionModule).SKIPPED - > > > > Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1) > > > > mng5889FindBasedir(MvnFileShortOptionModule)SKIPPED - > > > > Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1) > > > > mng5889FindBasedir(MvnFileShortOption)..SKIPPED - > > > > Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1) > > > > mng5889FindBasedir(MvnFileLongOption)...SKIPPED - > > > > Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1) > > > > mng5805PkgTypeMojoConfiguration(PkgTypeMojoConfiguration)...SKIPPED - > > > > Maven version 3.7.0-SNAPSHOT not in range (3.3.3,3.5.0-alpha) > > > > mng4428FollowHttpRedirect(itHttpToHttps)SKIPPED - > > > > Maven version 3.7.0-SNAPSHOT not in range [2.2.0,2.2.0] > > > > mng4428FollowHttpRedirect(itHttpsToHttp)SKIPPED - > > > > Maven version 3.7.0-SNAPSHOT not in range [2.2.0,2.2.0] > > > > mng4279WagonProviderFailover(it)SKIPPED - > > > > Maven version 3.7.0-SNAPSHOT not in range [2.2.1,3.0-alpha-1) > > > > mng4254SelectableWagonProviders(DefaultHttpsWagon)..SKIPPED - > > > > Maven version 3.7.0-SNAPSHOT not in range (2.2.0,3
Re: Integration Tests of Maven Core
I agree with what Jason shared. It's a reality. Probably a sad one but a lot of users are still running on ancient version of Maven (didn't we have a discussion recently about the minimum version of Java to support ?) There are some kind of business where you don't touch what is doing the job. It is especially true when you outsource the maintenance of your software. Having a separate repository and such big referential of tests is from my POV one of the best thing done in the project. Having a separate repo avoids that you refactor a test with the codebase and thus you have to explicitly update the IT if you change something. Having the whole history is helping to maintain old versions and even if it's not done by us (the community) it is useful for others On Mon, Dec 9, 2019 at 8:40 AM Enrico Olivelli wrote: > Karl, > In my opinion I would like to drop anything that is not useful. > > I would also like to merge the integration tests repository with the maven > core repository, this way it is clear that the ITs are for the same > version. > > Can you tell more about the reasons behind having two separate repos? > > Enrico > > Il lun 9 dic 2019, 07:59 Jason van Zyl ha scritto: > > > Please don’t ever remove any of the integration tests. If they don’t > apply > > to specific versions they are skipped as you see and there’s no harm. > > > > They serve as a historical record of what features work in a particular > > version. I’ve not done specific Maven work for any customer recently, but > > it has happened where in a highly regulated industry (nuclear, aerospace) > > changes are prohibitively expensive and so no one wants to upgrade > anything > > especially build tools. They will make the minimal patch from anything > > upstream to make their changes work. I’ve helped consultants make small > > patches in Maven, and used the integration tests to verify everything > else > > worked. > > > > Yes, they will always be in the history but I can’t imagine it would be > > very nice for someone in that situation to go hunting through the history > > to bring back tests in order to verify a change. I think we would all be > > pretty shocked how many people still actually use Maven 2.x. The support > > cycle on things like airplanes is upwards of 50 years and no one will > > change a thing if they don’t have to. I’m sure there’s lots of Maven 1.x > > and Ant in a bunch of nooks and crannies for that very reason. Didn’t > > someone just post about writing a book about Maven 2.x? :-) > > > > JvZ > > > > > On Dec 8, 2019, at 2:10 PM, Karl Heinz Marbaise > > wrote: > > > > > > Hi, > > > I'm diving a little bit into the integration tests of maven core... > > > > > > and I realized that at the moment this list of IT's is SKIPPED > > > based on the version of Maven Core: > > > > > > mng5889FindBasedir(MvnFileLongOptionModule).SKIPPED - > > > Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1) > > > mng5889FindBasedir(MvnFileShortOptionModule)SKIPPED - > > > Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1) > > > mng5889FindBasedir(MvnFileShortOption)..SKIPPED - > > > Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1) > > > mng5889FindBasedir(MvnFileLongOption)...SKIPPED - > > > Maven version 3.7.0-SNAPSHOT not in range [3.5.0,3.5.1) > > > mng5805PkgTypeMojoConfiguration(PkgTypeMojoConfiguration)...SKIPPED - > > > Maven version 3.7.0-SNAPSHOT not in range (3.3.3,3.5.0-alpha) > > > mng4428FollowHttpRedirect(itHttpToHttps)SKIPPED - > > > Maven version 3.7.0-SNAPSHOT not in range [2.2.0,2.2.0] > > > mng4428FollowHttpRedirect(itHttpsToHttp)SKIPPED - > > > Maven version 3.7.0-SNAPSHOT not in range [2.2.0,2.2.0] > > > mng4279WagonProviderFailover(it)SKIPPED - > > > Maven version 3.7.0-SNAPSHOT not in range [2.2.1,3.0-alpha-1) > > > mng4254SelectableWagonProviders(DefaultHttpsWagon)..SKIPPED - > > > Maven version 3.7.0-SNAPSHOT not in range (2.2.0,3.0-alpha-1) > > > mng4254SelectableWagonProviders(DefaultHttpWagon)...SKIPPED - > > > Maven version 3.7.0-SNAPSHOT not in range (2.2.0,3.0-alpha-1) > > > mng4254SelectableWagonProviders(SettingsUsage)..SKIPPED - > > > Maven version 3.7.0-SNAPSHOT not in range (2.2.0,3.0-alpha-1) > > > mng4254SelectableWagonProviders(CliUsage)...SKIPPED - > > > Maven version 3.7.0-SNAPSHOT not in range (2.2.0,3.0-alpha-1) > > > mng4126ParentProfilesXml(itReactorBuild)SKIPPED - > > > Maven version 3.7.0-SNAPSHOT not in range > [2.0,2.1.0),(2.1.0,3.0-alpha-1) > > > mng4126ParentProfilesXml(itChildOnlyBuild)..SKIPPED - > > > Maven version 3.7.0-SNAPSHOT not in range > [2.0,2.1.0),(2.1.0,3.0-alpha-1) > > > mng4086ExplicitPluginMetaversion(itRelease).SKIPPED - > > > Maven version 3.7.0-SNAPSHOT not in range [2.0.6,3.0-alpha-3) > > > mng4086ExplicitPluginMet
