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]
