Perhaps a stupid question, however if no change goes in, and it kicks off and gives the same gold star as the previous week, then there's no point to releasing it, because it's the same thing, what takes care of this? Just the human going "well, actually there were no commits, so this email is spurious"?
I see no problem with a thorough test rig like this, though. It seems purely positive. And if phrased more like "This gold star means it's OK to make a release" as opposed to "This gold star means a human should think about making a release" then it'd provoke no technical offense, probably. Releases are inherently human. It could be that it gold star with 3 out of a 5 commit patch that makes no sense to release, even if it passes all tests (tests missing?). You get a release out by making a clear decision about what will be in it, working towards that solidly, and not creeping to other related/new things. If at some point you realise you bit off more than could be chewed, you trim the excess and re-decide what'll be in the release, which brings it closer, or even to the point of occurring. My 2c about which I welcome feedback and abuse. :-) Fred. On Wed, Feb 19, 2014 at 11:19 AM, 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: > > > > > Well all this will be for the moment is a reminder that the best tests > we > > > have say it is releasable and that a *human* can think about cutting a > > > release. > > > > > > Right now it will fail to notify because there are failing integration > > > tests (need a 3.2.1 in central to fix the three failing tests) > > > > > > If we switch master to a 4.x line I will switch the job to follow the > > 3.2.x > > > branch. > > > > > > > I think that will be a few weeks as I'm in the middle of trying to punch > > out flipping the core to jsr330, refactor some of the resolution and get > us > > to a place where we can make a punch list of what we're going to eject > from > > the core. I think once everything is marked as deprecated we'll have to > > make some decisions about what we're going to nuke for the 4.x. I think > we > > need to make at least one release once everything is deprecated, maybe it > > doesn't matter. > > > > > What I want this to do is ensure that any fixes for 3.2.x get released > > > quickly. > > > > > > > Sure, I don't disagree but again I think it's curating the issues and > > having something to release. The core issue is having something to > release. > > > Which is what the build chain establishes. If the hash gets a gold star, we > have something to consider releasing and a mail suggesting that we should > cut a release > > > > I plan to work on the 3.2.2 list and maybe we agree to leave it that > size > > and when it's done release it. I would rather agree that a set of issues > > are in a release and release it when it's done, and if it's taking too > long > > shear off some issues and release. > > > > > The major changes will be towards 4.x, where a slower release cycle is > > fine. > > > > > > Given that 3.2.x should only have bug fixes how do you see this as > risky? > > > > 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 > > > > > > > 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. > > 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. > > 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. > > > > > > > > > - Stephen > > > > > > On Tuesday, 18 February 2014, Jason van Zyl <ja...@takari.io > <javascript:;>> > > wrote: > > > > > >> Sorry, but I don't think this is a good way to do releases. Honestly I > > >> think it's a potential recipe for disaster. > > >> > > >> As I said before, it's the lack of work being done in the core that is > > the > > >> issue. Releases aren't being made because until recently there isn't a > > lot > > >> of activity in the core. Just jumping into weekly releases is not the > > >> solution for having not released for 3 months. > > >> > > >> The issues need to be curated, a lot more tests need to done, and a > good > > >> chunk of the core needs to be cleaned up before having more frequent > > >> releases. Having a public weekly release I don't think is going to be > > >> helpful. I think shooting for a release every 4-6 weeks as official > > >> releases is a good start, and then patch releases possibly more > > frequent. > > >> > > >> I'm not in favor of this and I think it's too drastic a change and > isn't > > >> going to help. > > >> > > >> On Feb 18, 2014, at 7:26 AM, Stephen Connolly < > > >> stephen.alan.conno...@gmail.com <javascript:;> <javascript:;>> wrote: > > >> > > >>> I have set up a chain of build jobs in Jenkins. > > >>> > > >>> The root of the chain is > > >>> https://builds.apache.org/job/maven-3.2-release-status/ > > >>> > > >>> This builds at midnight UTC every monday. > > >>> > > >>> If there are changes to the master branch of Maven since the last > > release > > >>> of Maven then that build will pass and kick off the chain. > > >>> > > >>> The next build in the chain is > > >>> https://builds.apache.org/job/maven-3.2-release-status-build/ > > >>> > > >>> This checks out the GIT hash provided by > > >>> https://builds.apache.org/job/maven-3.2-release-status/ and verifies > > >> that > > >>> it builds using the apache-release profile (and a throwaway GPG key > to > > >> sign > > >>> everything - we need a GPG key to enable the profile) > > >>> > > >>> If that build succeeds then > > >>> https://builds.apache.org/job/maven-3.2-release-status/ gets a green > > >> star > > >>> promotion badge and > > >>> https://builds.apache.org/job/maven-3.2-release-status-test/ gets > > >> triggered. > > >>> > > >>> https://builds.apache.org/job/maven-3.2-release-status-test/ uses > the > > >> built > > >>> version of Apache Maven from > > >>> https://builds.apache.org/job/maven-3.2-release-status-build/ and > runs > > >> the > > >>> integration tests against that binary. > > >>> > > >>> If that build succeeds then > > >>> https://builds.apache.org/job/maven-3.2-release-status/ gets a gold > > star > > >>> promotion badge. > > >>> > > >>> After Monday, if it all works according to plan, then I will tweak > the > > >> job > > >>> to send an email on success alerting us that we can cut a release of > > >> Maven > > >>> core. > > >>> > > >>> I would hope that a release manager would step forward (it may be > me... > > >> it > > >>> could be anyone who feels up to cutting a release) and we would then > > cut > > >> a > > >>> release sometime after the mail. > > >>> > > >>> If there is no gold star on the build... then there will not be a > > release > > >>> that week... or at least I will not be pushing for one. > > >>> > > >>> If this pipeline works out ok, we can see about enhancing it with > > further > > >>> tests, e.g. windows integration tests, etc. > > >> > > >> Thanks, > > >> > > >> Jason > > >> > > >> ---------------------------------------------------------- > > >> Jason van Zyl > > >> Founder, Apache Maven > > >> http://twitter.com/jvanzyl > > >> http://twitter.com/takari_io > > >> --------------------------------------------------------- > > >> > > >> Simplex sigillum veri. (Simplicity is the seal of truth.) > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > >> > > > > > > -- > > > Sent from my phone > > > > Thanks, > > > > Jason > > > > ---------------------------------------------------------- > > Jason van Zyl > > Founder, Apache Maven > > http://twitter.com/jvanzyl > > http://twitter.com/takari_io > > --------------------------------------------------------- > > > > Three people can keep a secret provided two of them are dead. > > > > -- Benjamin Franklin > > > > > > > > > > > > > > > > > > > > > > -- > Sent from my phone >
