On Tue, 2013-09-10 at 08:45 -0700, Josh Andler wrote:
Adding features is fun, fixing bugs is tedious and often a complete pain.
I put some of that down to the job of seeing thousands of users enjoy the result, as apposed to the silence of fixing a critical bug.
Don't have the ability to pretend to be upbeat about this.
If you can't be genuinely upbeat about it, then it's time for a break... at least that's been my experience. Otherwise you'll tear a gear in your happy machine.
We don't have to date the actual release. We can instead date an open-ended freeze process. Pencil in a /want/ for a release, but no date of release.
This proposition already defeats the purpose. Dating something that is knowingly open-ended is the same as having no date if people tend to procrastinate or don't have a lot of free time.
I think you misunderstand. We'd have a date for lock-down and some targets for as long as it takes. But after freeze date, there'd be pressure to get bugs fixed with a view to have the release. We'd be in labour (so to speak) even if it's a really protracted labour, but while there wouldn't be a firm release date, there would be a fixed freeze date.
I know it's not your intention, but I'm really starting to get the feeling that I just need to not be involved anymore.
Unsubscribe, see how you feel for a week or two. Process any leadership change-over after that. Find your balance.
Perhaps we try to have a new policy for the next dev cycle where no new features can be committed to trunk if a blocker has existed for X amount of time.
Good idea, I wonder how flexible those smoke test scripts are for automatic merging.
Martin,