Hi Simon, thanks for your writeup! I totally agree! FYI, If we have to respin again, I will do the next run, ok?
Uwe ----- Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: [email protected] > -----Original Message----- > From: Simon Willnauer [mailto:[email protected]] > Sent: Sunday, February 23, 2014 8:01 PM > To: [email protected] > Subject: Re: [VOTE] Lucene / Solr 4.7.0 RC3 > > On Sat, Feb 22, 2014 at 5:39 PM, Mark Miller <[email protected]> > wrote: > > I’ve been sick and am sick, so take it for what it’s worth with my head > swirling, but I wrote down a few of my thoughts on releases. > > > > It’s all encompassed in a big “in my opinion”. It’s not necessarily to > > refute > anyone or argue with any existing points. It’s just the thoughts I had when > thinking about the topic. > > Hey mark, > > get well though hope it's not too bad! > > > > Releases > > > > I think we have to balance the utility of getting code into users hands > > faster > with the utility of solid and stable releases. Balance the needs of new users > and existing users. > > I agree in general but IMO we need to make a difference between feature > releases and bugfix releases but I will come back to this laster further down > the email. > > > > > We shouldn't discourage review and reporting back of problems with the > release. That is the entire point of the review and vote. We learn which bugs > are worth a respin with discussion and consensus. > > > > We should be lenient on the first couple RCs and more strict over time. > Let's aim for quality. > > I have done some releases here in lucene land but this time something was > fundamentally different which made me worry a much more about the job > and the responsibility of the RM. The last couple of releases I ran the > release > script always with a -smoke but this time I didn't and stuff was failing all > over > me with the solr tests as I mentioned in another email. Yet, I haven't > realised > until then that -smoke disables running the tests and we are essentially build > a release candidate without passing tests. Mark said he is watching every test > failure and there is nothing to worry about. (I will need to reply to that > which > I had no time yet but I think this is very very concerning but yet another > story). For me as a RM I have only once choice and trust mark here since if I > wouldn't I had to -1 every RC since the tests fail. > That far the quality discussion but we need to have a sep. discussion about > this. > > > > > We should discuss issues and not try and move at light speed. We are a > large group of diverse developers - it's okay for things to move at a pace of > days. It's actually the Apache Way IMO. > > I could not agree more. Here are my problems on how things work today... > The last couple of release we always had the discussion about when to cut > the Release Branch and this time I tried to not step on people toes and > announce it a couple of days earlier which was good. > Then on wed. we build an RC and suddenly one bug per RC shows up. This is > the annoying part that really bugs me since we are wasting a ton of time on > rebuilding the RCs etc. and that is the part that annoys me because it seems > folks rush stuff in to get the next RC out. I admit now that I took a step > back > that this is also the fault of the RM (me in this case since I wanted to move > fast rather than towards a stable release). The changes that go it don't get a > lot of CI runs, they don't get run in tests during Release. This doesn't > really > give me much confidence neither for the change nor for the release. > That said I think what brings up these bugs is that folks actually installing > the > RC in their environment and runs smoke tests with their apps which is what > we want and should encourage people to do. Now bugs come in and we > respin and respin and respin which makes those windows smaller and smaller > between change and RC. That just doesn't make much sense to me. What > would make more sense to me is a process where we can draw a clear line > between respin-worthy and not-respin-worthy. I thought about this today > and I don't think we can draw a clear line here but I though about a potential > improvement of the process that would address at least my concerns and > would allow folks to test and report back changes. Here is what I have in > mind for a feature release > > - We cut a release branch with 3 or 4 days of notice and from that point on > there are no features backported to this branch anymore. > - We start CI builds for this branch and have a close eye on it for the solr > part > if there are failures (mark I rely on you and the guys around you) > - We build an RC that is out there for a couple of days without a vote for > folks > to test and for us to gather feedback. During that period we only commit > bugfixes / changes cleanups etc. essentially things that seem to be wrong > with that unvoted RC. > - Once we had that out there for a couple of days maybe a week and > gathered feedback, ported bugfixes to that branch and hardened stuff out > we can build an RC, sign it and vote. > > It would make things for the RM much more straight forward since there > would not be respin after respin and the responsibility on the RM would be > reduced with RC and time at least that would make me feel much better. > > > > > Potential RMs that don't want to respin may not be the best candidate > RM's. Or they should be willing to hand off the reigns for another to respin. > That doesn’t mean you have to respin or can’t argue against it. But it seems > like you should be pretty open to the idea if their strong support for it. > > I think there are a bunch of different camps along those lines. For what it's > worth I think not every bug should cause a respin but the critical ones for > sure like the BW compat. My frustration came more from the things I > mentioned above rather than running that script again which doesn't cost me > much. The process is still sucks. I don't think its a question of "want" but > rather what makes sense from a process point of view and that is why we > have the discussion to improve. > > Simon > > > > > Releasing often should be a goal. Making releases easy to do should be a > goal. Releasing fast is not necessarily a good goal. We should strive for > quality. People choose a release and are often stuck on it for a very long > time. A respin amounts to running a few cmds. It is mostly waiting. And it’s > easily passed off if your busy. Robert happily picked up the last bits of the > 4.6.1 release for me when I had to go out of town for a few days. I would do > the same for anyone here. > > > > I can't think of a reason for delaying a release a few days or even a week > > if > we can make it higher quality in a way discussion and consensus has deemed > important. Company deadlines seem like the only reason we wouldn't do this > and they shouldn't play a role in our releases. I don’t think we should try > and > setup a system that tries to avoid discussion and consensus - I think you just > need a fail safe to help ensure it doesn’t go on to long. I think discussion > and > consensus with the community of developers we have put together is a good > failsafe. In general, we all seem pretty good at coming to consensus in most > cases. I can’t be the only one to notice how we seem to end up working > almost everything out pretty nicely in the end. > > > > Common sense has always worked for us in the past - the community > would not delay a release for weeks just to fix a few superficial bugs. > > > > Looking critically at our last half dozen releases, I think things went > > pretty > well and at a great pace. > > > > - Mark > > > > http://about.me/markrmiller > > > > > > > > > > On Feb 21, 2014, at 10:27 AM, Robert Muir <[email protected]> wrote: > > > >> > >> > >> > >> On Fri, Feb 21, 2014 at 10:23 AM, Uwe Schindler <[email protected]> > wrote: > >> > >> A similar thing was already discussed on the board. I think we have to > >> stick > with the 72 hours (for now?). We can do releases once per week; we can also > do them "automatically" - the problem here is the GPG signature: It has to be > done by a real person (the RM). A machine as RM is therefore not possible. > >> > >> I agree a machine cannot be the complete RM, but it could take over > more. For example, a machine could prepare-release-no-sign and verify it > (actually this is what 'ant nightly-smoke' does!), and if it succeeds, someone > could take those artifacts, sign them, and call a vote. > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] For > > additional commands, e-mail: [email protected] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] For additional > commands, e-mail: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
