thanks uwe - I am ok with the respin all it takes it entering a screen press the up arrow, enter a password and wait :) It the process not the execution. I think I will keep this RC out for longer if needed just to gather feedback even if the vote fails.
simon On Sun, Feb 23, 2014 at 8:05 PM, Uwe Schindler <[email protected]> wrote: > 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]
