On Feb 18, 2014, at 4:32 PM, Benson Margulies <bimargul...@gmail.com> wrote:
> Looking for common ground here, how about we start by documenting the core > release procedure so that someone else could plausibly take a turn? Without > knowing the details of the release process, I don't see how I could disagree > with JvZ. > It should be push button, but it's pretty tedious right now. All the documentation is there but anyone new trying it will suffer unnecessarily. Small incremental changes like making RAT report on every build helps us move toward things being in a releasable state. Having a CI that isn't broken all the time would also help, there doesn't seem to be single line of the IT builds that are working. To me these steps toward having the core build in an always releasable state is the work that needs to be done. A few more things I can have thought about: - automatic staging of the site - automatic production of the vote email based on a Nexus staging rule - automatic execution of the source-release-validator and posting of results (previous the sebbalizer -- I so much more liked that name :-)) - closing out the release in JIRA - updating all the site documentation that can be (obviously the release notes need to be written but there's a lot of other manual busy work) And then if someone wants to go figure out how this all works they can but it should just work and we're so far away from that now. > It mostly seems to me that Stephen's desired schedule could best arrive > organically; it we make fixes in the core that people care about, and if we > make the procedure easy, we can make more releases. If that verges on every N > weeks, OK, we make a schedule. > If all the above are done then it's possible because we'll have builds that are always available, and really each of those steps could be automated to happen all the time. But honestly we have a CI that's generally unreliable so maybe that's one of the first issues that needs to be addressed. > On February 18, 2014 7:23:19 PM EST, Stephen Connolly > <stephen.alan.conno...@gmail.com> wrote: >> On 18 February 2014 23:58, Jason van Zyl <ja...@takari.io> wrote: >> >>> >>> 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. >>> >> >> If they are releases that we intend users picking up, then there needs >> to >> be a vote. >> >> I don't mind if we call these 3.2.2-alpha-x releases or some other >> version. >> The simple fact is that -SNAPSHOTs do not get tested. Things called >> alpha >> or beta don't get tested, and if we want to stick to semver type >> version >> numbers then 3.2.x is really just bug fixes and anything else is 3.3.x. >> I >> am not suggesting weekly releases for 3.3.x only for 3.2.x >> >> So for example MNG-5577, from what I understand, is an API change... a >> backwards compatible one true... but still not a bug fix... so perhaps >> significant enough that it should be 3.3.x... (and remember this >> experiment >> only targets 3.2.x) >> >> Precisely because we have held back releases we end up in this state >> where >> we are afraid to bump minor or major versions because we do not have >> enough >> changes in them... and then we try to cram more changes into what >> should be >> patch releases. >> >> A patch release is to fix a bug... if it is an improvement then IMHO it >> should be in the next minor version... if it is a breaking change then >> the >> next major... >> >> If you see a different scope of what should be in for 3.2.2 (or 3.2.3 >> if >> the vote for 3.2.1 fails) then there is a different disconnect there. >> >> If we want to show that Maven is listening to users, sticking to patch >> releases fix bugs, minor releases add features, major releases may >> break >> things is what users want... and if we are only fixing bugs in 3.2.x >> then >> what is the issue? The bug is fixed, let's get that fix in the hands of >> our >> users. >> >> >>> 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 >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity. Thanks, Jason ---------------------------------------------------------- Jason van Zyl Founder, Apache Maven http://twitter.com/jvanzyl http://twitter.com/takari_io --------------------------------------------------------- There's no sense in being precise when you don't even know what you're talking about. -- John von Neumann
