Hey, The QA process is a little iffy, but I do try awful hard :)
The process, in short: - Mailing list is layer 1 of QA process. Patches for release are first vetted here. - I am the final layer of QA process for the stable tree... Patches are tested (almost always...), reviewed, then included. All patches are individually build-tested locally. - In a happier world we'd have buildbot run at this point, but I kinda broke that and need to fix it, sorry. - When enough patches are in, we ready for a release candidate (-rc). I usually fire up VM's for 4-5 different OS's and run a build test, review the patches queued again, then send out a release candidate for public testing. - We wait a few days to a week between -rc's until no new bug reports come in. - We tag, stamp, and release the next stable. I don't usually, but for 1.2.7 and beyond, will be dogfooding the -rc in Six Apart's memcached cluster before release... Swap in one server and see how it does... After giving to the developers/etc. I'd encourage others do so as well. I'm excessively paranoid about the quality of memcached's releases, and can say with certainty that we've been removing more bugs than we've been adding for the last three. If I can get my head out of my ass we'll even be able to move faster and release more often :) have fun, -Dormando On Tue, 4 Nov 2008, Victor wrote: > > Hi, > I'm wondering if anyone can tell me which QA activities are in > involved everytime we release a new memcached version. I had planned > to attend the Hackathon and talk to people about this there but I was > not able to go. If the answer to my question is very simple that's > fine - I just want to know what the situation is right now ... and I'm > not going to suggest that we change anything right now either. > However, if anyone wants to make suggestions that's fine too. > > Thanks, > Victor >
