> 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: [email protected] > >> [mailto:[email protected]] 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 > >> <[email protected]> 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: [email protected] For > >>>> additional commands, e-mail: [email protected] > >>>> > >>> > >>> Thanks, > >>> > >>> Jason > >>> > >>> ---------------------------------------------------------- > >>> Jason van Zyl > >>> Founder, Apache Maven > >>> http://twitter.com/jvanzyl > >>> ---------------------------------------------------------- > >>> > >>> > >>> > >> > --------------------------------------------------------------------- > >>> 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] > >> > >> > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > Thanks, > > Jason > > ---------------------------------------------------------- > Jason van Zyl > Founder, Apache Maven > http://twitter.com/jvanzyl > ---------------------------------------------------------- > > > --------------------------------------------------------------------- > 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]
