Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
On Fri, Nov 27, 2009 at 3:42 PM, Brett Porter br...@apache.org wrote: Brian, I'm not sure if you were replying to me or others, but you quoted me and snipped my actual point: I'm fine with either more or less frequent releases... I'm not fine with circumventing review or pushing releases outside the ASF. I agree with everything you said below. I was saying we need to keep the 72h voting window because there are good reasons for it. It's not that everyone has to review - just that everyone has the opportunity to. We're in agreement, except the license allows 3rd parties to produce forks or binaries so I don't think we need to be concerned about that possibility. It's not clear to me what the implications for naming are but that's an entirely separate bike shed. - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
I'm also not pushing for duration for testing purposes. That's part of it, but as Jason said automation can reduce the need over time (though it's never going to be 100% so there's some value in testing). However, it is mostly for an opportunity to review changes. If we do 8 releases a day, 8 releases a day or even 2 a day is just a straw man setup to refute the speed of releases. Noone is really going to do that at Apache because it's pointless, so it's pointless to even discuss it. If the releases are coming out too fast for you, don't test them if you don't want. The rules say at least 3 PMC must vote, but it most certainly does not say ALL PMCs must vote on every release. I haven't had time to look at every one so I haven't voted. I only vote on things I've checked out and that's what every PMC member has the responsibility to do. The Apache requirements state that we need to validate the basics like license, buildability of the source bundle etc. It does not mean we have to manually QA every bit, although generally people do make sure it does in fact work. All these things can be automated, and they will be shortly on r.a.o. If that satisfies your criteria, then you can use that to vote. The rules don't say exactly how you have to make up your mind, it's up to you. I'm actually surprised that people are complaining about weekly releases. If I thought it was worth the time, I could find hundreds of requests to release faster. Sheesh. --Brian - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Brian, I'm not sure if you were replying to me or others, but you quoted me and snipped my actual point: I'm fine with either more or less frequent releases... I'm not fine with circumventing review or pushing releases outside the ASF. I agree with everything you said below. I was saying we need to keep the 72h voting window because there are good reasons for it. It's not that everyone has to review - just that everyone has the opportunity to. - Brett On 28/11/2009, at 1:40 AM, Brian Fox wrote: I'm also not pushing for duration for testing purposes. That's part of it, but as Jason said automation can reduce the need over time (though it's never going to be 100% so there's some value in testing). However, it is mostly for an opportunity to review changes. If we do 8 releases a day, 8 releases a day or even 2 a day is just a straw man setup to refute the speed of releases. Noone is really going to do that at Apache because it's pointless, so it's pointless to even discuss it. If the releases are coming out too fast for you, don't test them if you don't want. The rules say at least 3 PMC must vote, but it most certainly does not say ALL PMCs must vote on every release. I haven't had time to look at every one so I haven't voted. I only vote on things I've checked out and that's what every PMC member has the responsibility to do. The Apache requirements state that we need to validate the basics like license, buildability of the source bundle etc. It does not mean we have to manually QA every bit, although generally people do make sure it does in fact work. All these things can be automated, and they will be shortly on r.a.o. If that satisfies your criteria, then you can use that to vote. The rules don't say exactly how you have to make up your mind, it's up to you. I'm actually surprised that people are complaining about weekly releases. If I thought it was worth the time, I could find hundreds of requests to release faster. Sheesh. --Brian - 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: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
I can only speak from experience with what we have done here internally but I can also attest that releasing too often is a real pain. You end up having a bunch of releases publicized that no one cares about. It only serves to clutter a repository and makes it confusing to consumers wrt which one to use. I love the agile model of development but I don't think this equates to releasing something immediately if there are fixes available as Jason put it. The release needs to be weighed against the value it provides and the extra time and effort the community needs to soak and test that release. Agile states that your software should be releasable at anytime, but it does not state that it should be continually released. Of course, the opposite (ie: not releasing enough) is just as bad if not worse. Have to find that sweet spot ;-). --- Todd Thiessen -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On Behalf Of Paul Benedict Sent: Wednesday, November 25, 2009 9:21 PM To: Maven Developers List Subject: Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5 I would also like to contribute my frustration with the current build process. It's great the alpha releases are coming out often, but I cannot possibly be testing them at the frequency you guys are currently tagging and voting. I thought the once a week alpha was a good idea until it actually happened. If you guys voted once every three weeks, it would be much easier for me to participate. I wonder if others believe the same. Paul On Wed, Nov 25, 2009 at 7:48 PM, Jason van Zyl ja...@maven.org wrote: Let's not beat the dead horse. No one cares. There's not good reason for not releasing something immediately if there are fixes available. That's just not the way it works here, that's fine and not a big deal. On 2009-11-25, at 7:52 PM, Brett Porter wrote: On 26/11/2009, at 6:24 AM, Jason van Zyl wrote: If ever we really needed to push out builds more frequently I would just do it from Sonatype. I've given up trying to be truly agile at Apache, it's just not going to happen. I don't understand what the issue is with the current process. Benjamin is already getting them out faster than the majority of people will be able to test and review them. Any faster and you might as well just be using the CI builds for whatever purpose you have in mind. You're not going to be able to push out anything from Sonatype that's any more official than those, so what benefit does anyone get from a build that loses the frequency of CI builds and loses the benefit of being reviewed before publishing? The rules about not promoting snapshots to users are there for good reasons - to make sure the PMC does actually authorize releases and the users know what they are getting, and to encourage actually doing releases (instead of everyone running their own version of trunk). I don't see any upside to a change that loses those. There's no problem pointing individuals to the grid for *testing* purposes as far as I know, as long as they know what they are getting is not a release and may not work at all. Thanks, Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
RE: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
The logic here is flawed because it is from a single perspective of an individual who finds it burdensome to validate each and every release. It isn't just me. Both Paul and Brett expressed similar concerns ;-). To keep this short, I simply disagree with Jason's assertion that a fix should be synonymous with a release. We could go on ad-nauseam but I think we both have more important things to do ;-). If I ever get more involved with Maven development (which I have really wanted to do, but corporate policies get in the way) I may bring it up again. But until then I will just bite my tongue as I realize my opinion carries very littie weight ;-). The value of releasing everyday if there is a fix is because that fix may be very valuable to a user. I pushed extremely aggressively against Benjamin and Igor to put in place the regression test suite and performance framework so that we don't have to fear validation for the most part. I'm confident at this point that we're going to find the problems before any of you do 95% of the time. This is how it should be. When we have a fix it should be made immediately available in a consumable form by the general public because it probably matters to someone. We are at this point responding to people taking the time to accurate report errors. If you watch the process that happens it usually a matter of hours before Benjamin fixes it. The release process here is entirely broken from a users perspective, but that's the Apache Way. Here people think developers are more important then users which is why we have the contorted set of practices we have here now. The work needs to be instantly validated and we can do that now, and once that criterion is met it should be released. This is not the case with many of our plugins which can have a dire impact on users because the tests for critical plugins that just haven't gotten the attention they need yet. I plan to help try and fix this as well but there's only so much that can be done at a time. These are alphas and getting them out as soon as the rules allow here is important for people trying to evaluate 3.x. --- Todd Thiessen -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On Behalf Of Paul Benedict Sent: Wednesday, November 25, 2009 9:21 PM To: Maven Developers List Subject: Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5 I would also like to contribute my frustration with the current build process. It's great the alpha releases are coming out often, but I cannot possibly be testing them at the frequency you guys are currently tagging and voting. I thought the once a week alpha was a good idea until it actually happened. If you guys voted once every three weeks, it would be much easier for me to participate. I wonder if others believe the same. Paul On Wed, Nov 25, 2009 at 7:48 PM, Jason van Zyl ja...@maven.org wrote: Let's not beat the dead horse. No one cares. There's not good reason for not releasing something immediately if there are fixes available. That's just not the way it works here, that's fine and not a big deal. On 2009-11-25, at 7:52 PM, Brett Porter wrote: On 26/11/2009, at 6:24 AM, Jason van Zyl wrote: If ever we really needed to push out builds more frequently I would just do it from Sonatype. I've given up trying to be truly agile at Apache, it's just not going to happen. I don't understand what the issue is with the current process. Benjamin is already getting them out faster than the majority of people will be able to test and review them. Any faster and you might as well just be using the CI builds for whatever purpose you have in mind. You're not going to be able to push out anything from Sonatype that's any more official than those, so what benefit does anyone get from a build that loses the frequency of CI builds and loses the benefit of being reviewed before publishing? The rules about not promoting snapshots to users are there for good reasons - to make sure the PMC does actually authorize releases and the users know what they are getting, and to encourage actually doing releases (instead of everyone running their own version of trunk). I don't see any upside to a change that loses those. There's no problem pointing individuals to the grid for *testing* purposes as far as I know, as long as they know what they are getting is not a release and may not work at all. Thanks, Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
On 2009-11-26, at 10:27 AM, Todd Thiessen wrote: The logic here is flawed because it is from a single perspective of an individual who finds it burdensome to validate each and every release. It isn't just me. Both Paul and Brett expressed similar concerns ;-). That's fine don't look at them, it's pretty simple. To keep this short, I simply disagree with Jason's assertion that a fix should be synonymous with a release. We could go on ad-nauseam but I think we both have more important things to do ;-). If I ever get more involved with Maven development (which I have really wanted to do, but corporate policies get in the way) I may bring it up again. But until then I will just bite my tongue as I realize my opinion carries very littie weight ;-). The value of releasing everyday if there is a fix is because that fix may be very valuable to a user. I pushed extremely aggressively against Benjamin and Igor to put in place the regression test suite and performance framework so that we don't have to fear validation for the most part. I'm confident at this point that we're going to find the problems before any of you do 95% of the time. This is how it should be. When we have a fix it should be made immediately available in a consumable form by the general public because it probably matters to someone. We are at this point responding to people taking the time to accurate report errors. If you watch the process that happens it usually a matter of hours before Benjamin fixes it. The release process here is entirely broken from a users perspective, but that's the Apache Way. Here people think developers are more important then users which is why we have the contorted set of practices we have here now. The work needs to be instantly validated and we can do that now, and once that criterion is met it should be released. This is not the case with many of our plugins which can have a dire impact on users because the tests for critical plugins that just haven't gotten the attention they need yet. I plan to help try and fix this as well but there's only so much that can be done at a time. These are alphas and getting them out as soon as the rules allow here is important for people trying to evaluate 3.x. --- Todd Thiessen -Original Message- From: paulus.benedic...@gmail.com [mailto:paulus.benedic...@gmail.com] On Behalf Of Paul Benedict Sent: Wednesday, November 25, 2009 9:21 PM To: Maven Developers List Subject: Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5 I would also like to contribute my frustration with the current build process. It's great the alpha releases are coming out often, but I cannot possibly be testing them at the frequency you guys are currently tagging and voting. I thought the once a week alpha was a good idea until it actually happened. If you guys voted once every three weeks, it would be much easier for me to participate. I wonder if others believe the same. Paul On Wed, Nov 25, 2009 at 7:48 PM, Jason van Zyl ja...@maven.org wrote: Let's not beat the dead horse. No one cares. There's not good reason for not releasing something immediately if there are fixes available. That's just not the way it works here, that's fine and not a big deal. On 2009-11-25, at 7:52 PM, Brett Porter wrote: On 26/11/2009, at 6:24 AM, Jason van Zyl wrote: If ever we really needed to push out builds more frequently I would just do it from Sonatype. I've given up trying to be truly agile at Apache, it's just not going to happen. I don't understand what the issue is with the current process. Benjamin is already getting them out faster than the majority of people will be able to test and review them. Any faster and you might as well just be using the CI builds for whatever purpose you have in mind. You're not going to be able to push out anything from Sonatype that's any more official than those, so what benefit does anyone get from a build that loses the frequency of CI builds and loses the benefit of being reviewed before publishing? The rules about not promoting snapshots to users are there for good reasons - to make sure the PMC does actually authorize releases and the users know what they are getting, and to encourage actually doing releases (instead of everyone running their own version of trunk). I don't see any upside to a change that loses those. There's no problem pointing individuals to the grid for *testing* purposes as far as I know, as long as they know what they are getting is not a release and may not work at all. Thanks, Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
On Nov 26, 2009, at 5:04 AM, Todd Thiessen wrote: I can only speak from experience with what we have done here internally but I can also attest that releasing too often is a real pain. You end up having a bunch of releases publicized that no one cares about. It only serves to clutter a repository and makes it confusing to consumers wrt which one to use. Users just use the latest one you give them. Most users will avoid a release named project-n.n-alpha-n because they don't want to screw around with stuff that is unstable. However, there will be a tiny set of users for which the particular fixes in the alpha is important. I love the agile model of development but I don't think this equates to releasing something immediately if there are fixes available as Jason put it. The release needs to be weighed against the value it provides and the extra time and effort the community needs to soak and test that release. Agile states that your software should be releasable at anytime, but it does not state that it should be continually released. Releases named alpha or beta are for testing new functionality. They should not be considered release candidates and they certainly should not be used for production purposes. I would be much more concerned if these were non-alpha or beta type releases. Yes, I have found it difficult to keep up with the pace and have so far been only able to test one alpha. Since 3 votes are required to approve a release I would assume that various PMC members are confirming different releases. However, if it gets to the point where releases are being approved only by members with the same affiliation then I would be concerned. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
On Nov 26, 2009, at 5:56 AM, Jason van Zyl wrote: On 2009-11-26, at 8:04 AM, Todd Thiessen wrote: I can only speak from experience with what we have done here internally but I can also attest that releasing too often is a real pain. You end up having a bunch of releases publicized that no one cares about. It only serves to clutter a repository and makes it confusing to consumers wrt which one to use. I love the agile model of development but I don't think this equates to releasing something immediately if there are fixes available as Jason put it. The release needs to be weighed against the value it provides and the extra time and effort the community needs to soak and test that release. Agile states that your software should be releasable at anytime, but it does not state that it should be continually released. Of course, the opposite (ie: not releasing enough) is just as bad if not worse. Have to find that sweet spot ;-). The logic here is flawed because it is from a single perspective of an individual who finds it burdensome to validate each and every release. I don't understand why that logic is flawed. The individual in question would be on the Maven PMC and not have time to validate all the releases. Asking them to spend their time every week validating releases is a bit much. The value of releasing everyday if there is a fix is because that fix may be very valuable to a user. That value is illusory. The end user is far more likely to get pissed off that their Maven version is always out of date. People really don't like upgrading all that often. Alphas are a little different since end users obviously have some reason that they want to test the new functionality, but even there you can't expect them to download a release start testing their stuff and before they are even done a new release is out. I pushed extremely aggressively against Benjamin and Igor to put in place the regression test suite and performance framework so that we don't have to fear validation for the most part. I'm confident at this point that we're going to find the problems before any of you do 95% of the time. This is how it should be. When we have a fix it should be made immediately available in a consumable form by the general public because it probably matters to someone. We are at this point responding to people taking the time to accurate report errors. If you watch the process that happens it usually a matter of hours before Benjamin fixes it. I have no problem with building in test coverage. More is better. The release process here is entirely broken from a users perspective, but that's the Apache Way. You know, I really dislike it when you throw this nonsense around. It gives the board the impression that the Maven community doesn't belong at Apache when these sentiments are mostly just yours. The Apache Way is community over code. That means sometimes you have to do things that are beneficial for the community that may not be beneficial to a single individual. Here people think developers are more important then users which is why we have the contorted set of practices we have here now. No. The community is more important than a single user. I don't view the requirement of having at least 3 PMC members test a release and approve it as contorted. The work needs to be instantly validated and we can do that now, and once that criterion is met it should be released. This is not the case with many of our plugins which can have a dire impact on users because the tests for critical plugins that just haven't gotten the attention they need yet. I plan to help try and fix this as well but there's only so much that can be done at a time. These are alphas and getting them out as soon as the rules allow here is important for people trying to evaluate 3.x. No one is arguing about getting alphas out quickly. But taking your argument to its logical conclusion would imply that a fix is done in the morning and a release is performed by lunch. Then another fix is done and a release is performed in the afternoon. Or perhaps we have 8 releases that day. Where is the value in that? The simple fact is that there is a point at which people are comfortable with releases being made. IMO once a day is too much and once a month is way too slow. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
On 2009-11-26, at 11:04 AM, Ralph Goers wrote: On Nov 26, 2009, at 5:04 AM, Todd Thiessen wrote: I can only speak from experience with what we have done here internally but I can also attest that releasing too often is a real pain. You end up having a bunch of releases publicized that no one cares about. It only serves to clutter a repository and makes it confusing to consumers wrt which one to use. Users just use the latest one you give them. That's not been the case with the 3.x alphas. We have lots of people picking them up especially the alpha-5. Most users will avoid a release named project-n.n-alpha-n because they don't want to screw around with stuff that is unstable. However, there will be a tiny set of users for which the particular fixes in the alpha is important. I love the agile model of development but I don't think this equates to releasing something immediately if there are fixes available as Jason put it. The release needs to be weighed against the value it provides and the extra time and effort the community needs to soak and test that release. Agile states that your software should be releasable at anytime, but it does not state that it should be continually released. Releases named alpha or beta are for testing new functionality. They should not be considered release candidates and they certainly should not be used for production purposes. I would be much more concerned if these were non-alpha or beta type releases. Yes, I have found it difficult to keep up with the pace and have so far been only able to test one alpha. Since 3 votes are required to approve a release I would assume that various PMC members are confirming different releases. However, if it gets to the point where releases are being approved only by members with the same affiliation then I would be concerned. Ralph - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
On 27/11/2009, at 2:27 AM, Todd Thiessen wrote: The logic here is flawed because it is from a single perspective of an individual who finds it burdensome to validate each and every release. It isn't just me. Both Paul and Brett expressed similar concerns ;-). I don't think this was my point. I'm fine with either more or less frequent releases (just not as infrequent as 2.0 - 3.0-alpha-1 or 3.0-alpha-2 - 3.0-alpha-3 :) I'm not fine with circumventing review or pushing releases outside the ASF. I'm also not pushing for duration for testing purposes. That's part of it, but as Jason said automation can reduce the need over time (though it's never going to be 100% so there's some value in testing). However, it is mostly for an opportunity to review changes. If we do 8 releases a day, then the chances of something undesirable slipping in that others might have noticed increases greatly. We've had things go into actual releases that can do bad things to the remote repo that we may need to live with forever, so it's not unthinkable that such things would be more common under more frequent releases. Sadly, I think the review aspect is frequently lost as people +1 releases they haven't looked at the code changes for, and sometimes haven't even tested. I actually think frequent releases during alphas is less important than frequent releases after final (3.0.1, 3.0.2, etc). Those consuming the alphas are going to be much more bleeding edge and happy with nightlies / source code. We just need regular milestones for those that have come to depend on it like Archiva, or Tycho as Jason mentioned. So, in summary - ain't broke, don't fix it :) - Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
If ever we really needed to push out builds more frequently I would just do it from Sonatype. I've given up trying to be truly agile at Apache, it's just not going to happen. On 2009-11-25, at 2:10 PM, Dan Fabulich wrote: Niall Pemberton wrote: On Mon, Nov 23, 2009 at 7:59 PM, Paul Gier pg...@redhat.com wrote: I wonder if we really need a full vote for every alpha. Especially if this is going to happen every two weeks. Why not just vote for a 2 week alpha release schedule and then don't do another vote until it's time for beta 1? The ASF requires a vote on the artifacts being released. You can't just sign a blank cheque for any future release. On that basis someone could put something that isn't allowed (e.g. a copy of some GPL code) into maven and then just cut an alpha release. I tried to find something in the ASF docs, but the release FAQ only says Each PMC must obey the ASF requirements on approving any release - but I can't find something that specifically says what the requirements on approving any release are. http://www.apache.org/dev/release.html That's written up under http://www.apache.org/foundation/voting.html Adding a link to the voting doc from the release doc would probably be wise, but it's always a huge mess when somebody tries to modify release.html :-) -Dan - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
On 26/11/2009, at 6:24 AM, Jason van Zyl wrote: If ever we really needed to push out builds more frequently I would just do it from Sonatype. I've given up trying to be truly agile at Apache, it's just not going to happen. I don't understand what the issue is with the current process. Benjamin is already getting them out faster than the majority of people will be able to test and review them. Any faster and you might as well just be using the CI builds for whatever purpose you have in mind. You're not going to be able to push out anything from Sonatype that's any more official than those, so what benefit does anyone get from a build that loses the frequency of CI builds and loses the benefit of being reviewed before publishing? The rules about not promoting snapshots to users are there for good reasons - to make sure the PMC does actually authorize releases and the users know what they are getting, and to encourage actually doing releases (instead of everyone running their own version of trunk). I don't see any upside to a change that loses those. There's no problem pointing individuals to the grid for *testing* purposes as far as I know, as long as they know what they are getting is not a release and may not work at all. Thanks, Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
Let's not beat the dead horse. No one cares. There's not good reason for not releasing something immediately if there are fixes available. That's just not the way it works here, that's fine and not a big deal. On 2009-11-25, at 7:52 PM, Brett Porter wrote: On 26/11/2009, at 6:24 AM, Jason van Zyl wrote: If ever we really needed to push out builds more frequently I would just do it from Sonatype. I've given up trying to be truly agile at Apache, it's just not going to happen. I don't understand what the issue is with the current process. Benjamin is already getting them out faster than the majority of people will be able to test and review them. Any faster and you might as well just be using the CI builds for whatever purpose you have in mind. You're not going to be able to push out anything from Sonatype that's any more official than those, so what benefit does anyone get from a build that loses the frequency of CI builds and loses the benefit of being reviewed before publishing? The rules about not promoting snapshots to users are there for good reasons - to make sure the PMC does actually authorize releases and the users know what they are getting, and to encourage actually doing releases (instead of everyone running their own version of trunk). I don't see any upside to a change that loses those. There's no problem pointing individuals to the grid for *testing* purposes as far as I know, as long as they know what they are getting is not a release and may not work at all. Thanks, Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
Re: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
I would also like to contribute my frustration with the current build process. It's great the alpha releases are coming out often, but I cannot possibly be testing them at the frequency you guys are currently tagging and voting. I thought the once a week alpha was a good idea until it actually happened. If you guys voted once every three weeks, it would be much easier for me to participate. I wonder if others believe the same. Paul On Wed, Nov 25, 2009 at 7:48 PM, Jason van Zyl ja...@maven.org wrote: Let's not beat the dead horse. No one cares. There's not good reason for not releasing something immediately if there are fixes available. That's just not the way it works here, that's fine and not a big deal. On 2009-11-25, at 7:52 PM, Brett Porter wrote: On 26/11/2009, at 6:24 AM, Jason van Zyl wrote: If ever we really needed to push out builds more frequently I would just do it from Sonatype. I've given up trying to be truly agile at Apache, it's just not going to happen. I don't understand what the issue is with the current process. Benjamin is already getting them out faster than the majority of people will be able to test and review them. Any faster and you might as well just be using the CI builds for whatever purpose you have in mind. You're not going to be able to push out anything from Sonatype that's any more official than those, so what benefit does anyone get from a build that loses the frequency of CI builds and loses the benefit of being reviewed before publishing? The rules about not promoting snapshots to users are there for good reasons - to make sure the PMC does actually authorize releases and the users know what they are getting, and to encourage actually doing releases (instead of everyone running their own version of trunk). I don't see any upside to a change that loses those. There's no problem pointing individuals to the grid for *testing* purposes as far as I know, as long as they know what they are getting is not a release and may not work at all. Thanks, Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - 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: voting was: [VOTE] Release Apache Maven 3.0-alpha-5
2009/11/26 Paul Benedict pbened...@apache.org: I would also like to contribute my frustration with the current build process. It's great the alpha releases are coming out often, but I cannot possibly be testing them at the frequency you guys are currently tagging and voting. I thought the once a week alpha was a good idea until it actually happened. If you guys voted once every three weeks, it would be much easier for me to participate. I wonder if others believe the same. IMHO, once a week vs once every three weeks makes little difference. The important metric is is the next release X bugs better than the last release. Personally, if at least 5 bugs have been fixed and it has been at least 1 week since the last alpha, I say run a release again especially given that running a release of a 3.0-alpha seems to be so much easier. These are alpha's, we have a great IT framework (thanks to benjamin), so voting +1 has got to be easier. If you don't feel like testing every release, test every other release and only vote only for those you feel comfortable voting for (i.e. you tested) -Stephen Paul On Wed, Nov 25, 2009 at 7:48 PM, Jason van Zyl ja...@maven.org wrote: Let's not beat the dead horse. No one cares. There's not good reason for not releasing something immediately if there are fixes available. That's just not the way it works here, that's fine and not a big deal. On 2009-11-25, at 7:52 PM, Brett Porter wrote: On 26/11/2009, at 6:24 AM, Jason van Zyl wrote: If ever we really needed to push out builds more frequently I would just do it from Sonatype. I've given up trying to be truly agile at Apache, it's just not going to happen. I don't understand what the issue is with the current process. Benjamin is already getting them out faster than the majority of people will be able to test and review them. Any faster and you might as well just be using the CI builds for whatever purpose you have in mind. You're not going to be able to push out anything from Sonatype that's any more official than those, so what benefit does anyone get from a build that loses the frequency of CI builds and loses the benefit of being reviewed before publishing? The rules about not promoting snapshots to users are there for good reasons - to make sure the PMC does actually authorize releases and the users know what they are getting, and to encourage actually doing releases (instead of everyone running their own version of trunk). I don't see any upside to a change that loses those. There's no problem pointing individuals to the grid for *testing* purposes as far as I know, as long as they know what they are getting is not a release and may not work at all. Thanks, Brett - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org Thanks, Jason -- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl -- - 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 - To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
