On 18 February 2014 22:47, Jason van Zyl <ja...@takari.io> wrote: > > On Feb 18, 2014, at 2:19 PM, Stephen Connolly < > stephen.alan.conno...@gmail.com> wrote: > > > On Tuesday, 18 February 2014, Jason van Zyl <ja...@takari.io> wrote: > > > >> > >> On Feb 18, 2014, at 11:47 AM, Stephen Connolly < > >> stephen.alan.conno...@gmail.com <javascript:;>> wrote: > >> > >> That it's releasing for releasing sake, and not trying to address the > real > >> issue of lack of movement in the core. I think if you fix some bugs it's > >> fine for them to collect over 6 weeks. The vast majority of users are in > >> organizations where there is no way they are going to absorb these > changes. > >> For people who are heavily involved can take CI builds and try them, > >> otherwise a 6 weeks cadence I believe is quite good. > >> > >>> If anything it means that if you fix a bug in 3.2.x it will be released > >>> quickly... 3.2.x has taken far far too long. > >> > >> By what measure? > > > > > > It was supposed to be a quick release the first week if Oct 2013... We > > still have not released it > > > > So? There were 26 issues, some harder than others and though we should try > to keep some form of schedule it's improving. If you consider that 3.0.5 > was purely for a critical security issue there was an 18 month gap between > 3.0.4 and 3.1.0 and it's improving. Between 3.1.0 and 3.1.1 was about 10 > weeks, and between 3.1.1 and 3.1.2 is about 6 months so that's not great. > At least quarterly would be good. > > Why are we holding on to fixes and making releases big things?
All we are doing is increasing the amount of change in a release and preventing the users who need the fix from getting the fix. I will repeat. If there are no changes in master since the last release then there is nothing to release. If there are changes and everything looks good then and only then would there be a release. > > > >> > >>> High cadence when there are > >>> changes to release is a better way. > >> > >> Again high cadence compared to what? > > > > > > Compared to our average cadence over the past N years. > > > > It's not. The last couple releases have come out faster. > Weekly is still a higher cadence than what we have used to date. > > > This is a three month experiment. If it doesn't work we will try > something > > else. If the rest if the PMC gets pissed off then the releases will not > get > > enough binding voted and it will come to a natural halt > > > > Previously you have suggested a 4-6 week cadence... That cadence failed > to > > deliver... Weekly is probably the fastest cadence you can have at ASF > (and > > it may prove to be too fast for ASF) but we won't know unless we try. > > > > So I am suggesting that we try shipping code as fast as we can and step > > back if that speed isn't working > > > >> > >>> I will act as RM if nobody else steps > >>> up during this 3 month experiment (but I would encourage other > committers > >>> to pick up the role for practice) > >> > >> So you're deciding I'm not the RM now after having done the last two > >> releases? How does that work? > > > > > > The RM has always been whoever stands up and says "I am cutting a > release" > > > > I was just saying that if it is too much effort for you, I am willing to > > step up and cut the release. > > > > You're just dictatorially deciding that we're now releasing weekly based > on some weak arguments without any discourse. Not kosher. I disagree as the > RM right now so unless the rules have changed here then I plan to cut the > 3.2.2 when the list of issues there is done. I'm not planning on cutting > weekly because I don't think it's a good idea. So unless there is some > provision whereby you're removing me as the current RM and removing my > decision to decide when to release, then you're just deciding by yourself > to release weekly and that if I say I don't agree I forfeit the RM role. > Sorry, that line of reasoning doesn't fly. > > If we are to have a discussion and people aren't happy with me as the RM > and want you as the RM, that's fine. I'll step down. Otherwise we're not > releasing weekly. > > Well for one that is not how RM works or has worked here. 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" 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. 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. 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. -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. > > >
