On Feb 18, 2014, at 3:20 PM, Stephen Connolly <stephen.alan.conno...@gmail.com> wrote:
> Well for one that is not how RM works or has worked here. > Really? When I have planned to release core it takes some effort that requires more effort than the normal components. So if it's not clear from trying to curate the issues for the next release and working on the core with the intent to release 3.2.2 when those issues are complete. > It's not a hat you keep. It is a hat you put on when you send the mail > saying "I am intending to cut a release in the next _ days" > All implied, nothing stated and I have always done a series of core releases because otherwise the overhead is generally pretty high. For a plugin maybe you can just do a couple days work and do a release but this is not how it works for the core. > If somebody objects then you take that on board as you see fit. Any > committer can step up and say they intend to cut a release of our > components. There is no persistent or sticky RM role. > You assume that the core RM is not sticky, I assume it is. If there is a huge gap sure, and like I said if after this 6 month gap you want to ask the group to have a new RM then you can. Otherwise I viewed it as implied with the work done of late that I am the RM for the next core release. So I'll state it explicitly that I plan to release 3.2.2. > I am happy with you cutting releases of core... in fact I am happy with > anyone who isn't me cutting releases of core or any plugin... largely > because it means less work for me... > > There is, however, a problem if we don't get more people acting as RM for > any releasable from our project... > > If you haven't cut a release, you fear the unknown involved in cutting a > release. > > My aim is to make releasing Maven core a non-event and trivially easy to > do. That has many benefits, not least making our work easier and getting > fixes into users sooner. > > Yes we could start with a less ambitious time frame, but my experience is > that it is easier to start with the small release deltas that come from > short time between releases and slow down if necessary. > > If you start with a process that is too fast, you are starting with a > process that is broken and slowing down until it is working. > > If you start with a process that is too slow, you are speeding up until it > breaks > > I do have to wonder what you are afraid of? > > You tend to work in branches and merge features when ready, so if you are > the only one making changes the build will have nothing to suggest until > you merge your branch to master. > > If other people have fixes for specific issues, what is wrong with letting > users get those fixes if they want. > Any one can fix anything they like. Michael and Robert added some fixes and improvements and they have gone in, and they were basically released a week or two after the fixes went in, but if they waited for a few more weeks I don't really see it as an issue. I have the opposite experience as you and organization's infrastructure does not change weekly, monthly or even quarterly. So taking more time and collecting changes is not a bad thing. I see little to no value for the majority of users and if we want people to try things we should make the nightlies very easy to consume. This does not require official releases. Anyone can get fixes whenever they want if we make it easy. This should just happen automatically and I think is a good thing. Official releases require a support commitment which I consider important and more of them is harder. > I'll make a deal with you, lets see how you feel after 1 month. I suspect > we will maybe have 1 release during the first month anyway... and may well > have none... but if we don't try we will never know. > I assumed I am the RM for 3.2.2 and I plan to release it when that list is done. I am vehemently against official weekly releases and this will require a discussion if this is to change. If you want to call them alphas or nightly and we make those easily available I have nothing against that and serves the small segment of the population that will try new things aggressively. If that falls into a pattern of availability for a 6 week release schedule that would be great. Ultimately anything built at any time should be a candidate for a release and those should be available for people to try but I don't think they should be official releases that we officially support. So maybe these are not nightlies but promoted nightlies that have fixes for those who really require them. But if anyone else thinks weekly releases are good speak up. I don't think we can really support them properly. I think 6 week releases would be fantastic and should be the first goal we strive for. Weekly releases to me are not valuable to most, generally not going to be consumed and not a great in practice. Continuous delivery with a stream of viable builds taken from the normal build stream would be great. Let people take those as fast as they can. But releases we should try to have better release notes (historically ours have been pretty terrible, myself particularly, admittedly) and generally a useful collection of fixes and hopefully features. I really doubt anyone would care about weekly Maven releases, it's just too much to absorb. > -Stephen > > >>> If you want to cut the releases, super. But I recognise that cutting >>> releases is work and switching to (max) one per week may be too much of >> an >>> ask for you. >>> >> Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- A party which is not afraid of letting culture, business, and welfare go to ruin completely can be omnipotent for a while. -- Jakob Burckhardt
