Re: Rationale for which bugs make a release?
The test case attached doesn't work, there're missing dependencies On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: I guess I'm a little confused about how something is decided which release a fix goes into. Here's a good example: MNG-1898. This is functionality that was broken between 2.0 and 2.0.1. It is listed as a blocker and has reproducible test cases associated with it, yet this one didn't make the 2.0.3 release. The test case has been attached since just before 2.0.2 was released. Don't get me wrong, you guys have done geat work, but it's discouraging to see so many issues get bumped from revision to revision. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Rationale for which bugs make a release?
The jar is included in the other attachment. It's hard to see with all the other comments, but this is how to reproduce: Install the jar in test-1.0.zip to the local repo and build the plugin in test-case. Run the plugin by using mvn test:enhance In 2.0 it will print where it found the factory class, in 2.0.1 it will crash -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Monday, February 20, 2006 4:28 PM To: Maven Developers List Subject: Re: Rationale for which bugs make a release? The test case attached doesn't work, there're missing dependencies On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: I guess I'm a little confused about how something is decided which release a fix goes into. Here's a good example: MNG-1898. This is functionality that was broken between 2.0 and 2.0.1. It is listed as a blocker and has reproducible test cases associated with it, yet this one didn't make the 2.0.3 release. The test case has been attached since just before 2.0.2 was released. Don't get me wrong, you guys have done geat work, but it's discouraging to see so many issues get bumped from revision to revision. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rationale for which bugs make a release?
Well, the easier the test case is to use the faster it's solved. If i have to spend a lot of time just setting up the environment it's likely that it'll be delayed. Please see my attached test cases for a better test case fully automated. On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: The jar is included in the other attachment. It's hard to see with all the other comments, but this is how to reproduce: Install the jar in test-1.0.zip to the local repo and build the plugin in test-case. Run the plugin by using mvn test:enhance In 2.0 it will print where it found the factory class, in 2.0.1 it will crash -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Monday, February 20, 2006 4:28 PM To: Maven Developers List Subject: Re: Rationale for which bugs make a release? The test case attached doesn't work, there're missing dependencies On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: I guess I'm a little confused about how something is decided which release a fix goes into. Here's a good example: MNG-1898. This is functionality that was broken between 2.0 and 2.0.1. It is listed as a blocker and has reproducible test cases associated with it, yet this one didn't make the 2.0.3 release. The test case has been attached since just before 2.0.2 was released. Don't get me wrong, you guys have done geat work, but it's discouraging to see so many issues get bumped from revision to revision. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Rationale for which bugs make a release?
I tried to make it as easy as possible but maybe I could have done more. This is a complicated issue because of the classloading so it requires installation of a dependency in the repository to fully reproduce the issue. See the updated comment in the issue for the exact steps I just took to reproduce it with the original test case. Regardless of the specifics on this issue, I would have expected that if the test case was broken or someone was confused, that a comment would be added. That's the part that is frustrating: when you hear nothing on an issue and it gets bounced. I can appreciate that if it's too hard to reproduce or isn't very important, fine just say so. At least then I know why and can see what I can do to help. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Monday, February 20, 2006 4:42 PM To: Maven Developers List Subject: Re: Rationale for which bugs make a release? Well, the easier the test case is to use the faster it's solved. If i have to spend a lot of time just setting up the environment it's likely that it'll be delayed. Please see my attached test cases for a better test case fully automated. On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: The jar is included in the other attachment. It's hard to see with all the other comments, but this is how to reproduce: Install the jar in test-1.0.zip to the local repo and build the plugin in test-case. Run the plugin by using mvn test:enhance In 2.0 it will print where it found the factory class, in 2.0.1 it will crash -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Monday, February 20, 2006 4:28 PM To: Maven Developers List Subject: Re: Rationale for which bugs make a release? The test case attached doesn't work, there're missing dependencies On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: I guess I'm a little confused about how something is decided which release a fix goes into. Here's a good example: MNG-1898. This is functionality that was broken between 2.0 and 2.0.1. It is listed as a blocker and has reproducible test cases associated with it, yet this one didn't make the 2.0.3 release. The test case has been attached since just before 2.0.2 was released. Don't get me wrong, you guys have done geat work, but it's discouraging to see so many issues get bumped from revision to revision. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rationale for which bugs make a release?
Take a look at my last attachment to see how an it test should be made as simple as possible On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: I tried to make it as easy as possible but maybe I could have done more. This is a complicated issue because of the classloading so it requires installation of a dependency in the repository to fully reproduce the issue. See the updated comment in the issue for the exact steps I just took to reproduce it with the original test case. Regardless of the specifics on this issue, I would have expected that if the test case was broken or someone was confused, that a comment would be added. That's the part that is frustrating: when you hear nothing on an issue and it gets bounced. I can appreciate that if it's too hard to reproduce or isn't very important, fine just say so. At least then I know why and can see what I can do to help. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Monday, February 20, 2006 4:42 PM To: Maven Developers List Subject: Re: Rationale for which bugs make a release? Well, the easier the test case is to use the faster it's solved. If i have to spend a lot of time just setting up the environment it's likely that it'll be delayed. Please see my attached test cases for a better test case fully automated. On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: The jar is included in the other attachment. It's hard to see with all the other comments, but this is how to reproduce: Install the jar in test-1.0.zip to the local repo and build the plugin in test-case. Run the plugin by using mvn test:enhance In 2.0 it will print where it found the factory class, in 2.0.1 it will crash -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Carlos Sanchez Sent: Monday, February 20, 2006 4:28 PM To: Maven Developers List Subject: Re: Rationale for which bugs make a release? The test case attached doesn't work, there're missing dependencies On 2/20/06, Brian E. Fox [EMAIL PROTECTED] wrote: I guess I'm a little confused about how something is decided which release a fix goes into. Here's a good example: MNG-1898. This is functionality that was broken between 2.0 and 2.0.1. It is listed as a blocker and has reproducible test cases associated with it, yet this one didn't make the 2.0.3 release. The test case has been attached since just before 2.0.2 was released. Don't get me wrong, you guys have done geat work, but it's discouraging to see so many issues get bumped from revision to revision. -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- I could give you my word as a Spaniard. No good. I've known too many Spaniards. -- The Princess Bride - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Rationale for which bugs make a release?
Hi Brian, Some will be coming back in, but this probably won't be one. It's a difficult and risky fix with a known workaround (IIRC). It's a shame it got introduced initially, but now with a test case it will be easier to maintain after it is fixed. You're welcome to voice a -1 on the release vote if it is that important to you. At this point, all it will do is delay the release - it won't get the issue fixed any faster. The test case will help, patches will get it fixed even faster :) Given it is a regression, I would like to think it gets prioritised properly for a 2.0.4. The main reason for bringing forward a release was a different regression in 2.0.2 that was blocking a Continuum release. - Brett Brian E. Fox wrote: I guess I'm a little confused about how something is decided which release a fix goes into. Here's a good example: MNG-1898. This is functionality that was broken between 2.0 and 2.0.1. It is listed as a blocker and has reproducible test cases associated with it, yet this one didn't make the 2.0.3 release. The test case has been attached since just before 2.0.2 was released. Don't get me wrong, you guys have done geat work, but it's discouraging to see so many issues get bumped from revision to revision. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Rationale for which bugs make a release?
I wouldn't -1 for this (especially for a new continuum release), although if there is a work around, I don't know of it. I tried many different things when this first occurred and eventually gave up. I'll patiently wait for 2.0.4 but I had the same impression for 2.0.3: that there was a test case, it was a regression and it would be fixed in this release. (Especially since it even delayed 2.0.2 for a few hours while I worked out the test case and John took a look) -Original Message- From: Brett Porter [mailto:[EMAIL PROTECTED] Sent: Monday, February 20, 2006 7:38 PM To: Maven Developers List Subject: Re: Rationale for which bugs make a release? Hi Brian, Some will be coming back in, but this probably won't be one. It's a difficult and risky fix with a known workaround (IIRC). It's a shame it got introduced initially, but now with a test case it will be easier to maintain after it is fixed. You're welcome to voice a -1 on the release vote if it is that important to you. At this point, all it will do is delay the release - it won't get the issue fixed any faster. The test case will help, patches will get it fixed even faster :) Given it is a regression, I would like to think it gets prioritised properly for a 2.0.4. The main reason for bringing forward a release was a different regression in 2.0.2 that was blocking a Continuum release. - Brett Brian E. Fox wrote: I guess I'm a little confused about how something is decided which release a fix goes into. Here's a good example: MNG-1898. This is functionality that was broken between 2.0 and 2.0.1. It is listed as a blocker and has reproducible test cases associated with it, yet this one didn't make the 2.0.3 release. The test case has been attached since just before 2.0.2 was released. Don't get me wrong, you guys have done geat work, but it's discouraging to see so many issues get bumped from revision to revision. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
