On Nov 2, 2010, at 11:47 AM, Jason van Zyl wrote: > > On Nov 2, 2010, at 11:38 AM, Stephen Connolly wrote: > >> On 2 November 2010 10:10, Jason van Zyl <ja...@maven.org> wrote: >>> >>> >>> That's perfectly reasonable, people who object commit to signing up to >>> maintain the plugin. I think it's also fair to say if someone does this and >>> then doesn't follow through loses the right to vote again to save a plugin >>> a plugin from retirement. There should be consequences to objecting and >>> then doing little or nothing. >>> >> >> If we are going to hae consequences then we need to be very clear up >> front what the commitment is that somebody is signing up to. >> >> If we say that the commitment associated with a -1 is: >> >> * At least one release per year >> > > Not good enough. I think the model Eclipse has is reasonable where there is a > release everywhere 6 weeks where a release does not have to happen unless > there are regressions introduced in the last cycle. At a bare minimum the > regressions need to be dealt with. I would rather have 10 plugins where we > can accomplish this then 40 that no one pays attention to.
Sorry, jetlag and no sleep for a while. A release cycle of every six weeks - If there are regressions those at a bare minimum must be addressed - A best effort to process patches - A best effort to process improvements Regressions simply cannot be left floating around. i don't think anyone can disagree with that. > >> * JIRA which includes a patch with integration tests remains open >> for more than two releases >> > > Remains open, or doesn't remain open for more then two release cycles? > >> Then that is fine... somebody saying -1 knows up front what they are >> committing to... but we cannot set the bar after the -1 vote. >> > > Why not? Release slated for every 6 weeks to account for bug fixes and at a > minimum regressions. > >> Similarly I think the committment should be the committment that we as >> Apache Maven Committers are giving in terms of an SLA for the Apache >> Maven hosted plugins... so that frames the vote for removal being we >> cannot meet the commitment of our SLA with the community >> > > For core lifecycle plugins I think we have to follow the 6 week cycle and > Eclipse has been doing this for years and it works for them, and their users > are pretty happy. Regressions in lifecycle related plugins like the niggly > thing in the WAR plugin just can't linger. > > For heavily used plugins we should try and do the same. Once a year when > regressions exist we simply can't do. That's just wrong. > > For site and other plugins I will follow the policy other people set forward. > >> -Stephen >> >> --------------------------------------------------------------------- >> 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 > --------------------------------------------------------- > > A language that doesn’t affect the way you think about programming is not > worth knowing. > > -— Alan Perlis > > > Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl --------------------------------------------------------- People develop abstractions by generalizing from concrete examples. Every attempt to determine the correct abstraction on paper without actually developing a running system is doomed to failure. No one is that smart. A framework is a resuable design, so you develop it by looking at the things it is supposed to be a design of. The more examples you look at, the more general your framework will be. -- Ralph Johnson & Don Roberts, Patterns for Evolving Frameworks
