On 2 November 2010 10:50, Jason van Zyl <ja...@maven.org> wrote: > > 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. >
I was not saying what our SLA should be. I was just trying to illustrate what should be in our SLA and what I see as being an absolute minimum SLA for a community driven project. I do think we need to have an SLA, and the minimum for a community driven project should be one release per year... and I don't think that is what the minimum SLA for Maven should be BTW. I think we should have a separate discussion on what our SLA with the Maven users should be / can be. Once we decide on our initial SLA (we can always increase our SLA afterwards) then we decide what we can keep in agreement with that SLA. as for punishment, there is no point in punishment without hope of redemption. We would need a mechanism whereby the -1's who fail to step up and maintain their favourite plugins can recover their vote... and all that needs to be defined before we think about punishment -Stephen >> >>> * 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org For additional commands, e-mail: dev-h...@maven.apache.org
