On 03/06/11 09:46, Ryan Lane wrote:
anyone's wondering what I think of this, I was pretty blunt
last time around:
To be any more blunt than that, I'd have to press the caps lock key ;)
This post seems to be a much more optimistic view of the 1.17
deployment than I remember. Wasn't it rolled back twice? I also
remember getting reports of random issues for weeks after the
deployment as well. People were asking for us to do a rollback a
couple weeks after the deployment even.
The first deployment caused disruption because we tried to deploy it
to all wikis at once, hopefully we're not going to try that again.
The second deployment caused disruption because it was done while I
was asleep, and the people involved decided to spend a long time
trying to debug the problem while the site mostly down, instead of
immediately reverting and isolating it offline. Hopefully we won't try
that again either.
Despite these "learning experiences", I think it went a lot better
than previous deployments. The number of bugs that needed fixing was
1.17 still doesn't have a tarball release. It is
*very* late. It
doesn't seem to me that this process is working.
We have a beta release, do you mean a stable release? That's mostly
due to priorities, not process. Also the Berlin meeting stopped pretty
much all work on it for a week, and there were a couple of security
issues reported that we'd like to get fixed before 1.17.0 is released.
I agree with the testing process, but I disagree with
process. We can apply the testing process to a continuous integration
deployment model. From an ops perspective, this is much nicer; if
something is going wrong, we know fairly quickly what caused it to go
I'm not sure what you're proposing here, in terms of how branches
would be used and what sort of testing would be done. Can you elaborate?
-- Tim Starling