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. 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. 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. 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. 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. 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]
