QA Process

[John J. McDonough]

On Wed, 2010-11-24 at 10:22 -0500, Eric "Sparks" Christensen wrote:

> It isn't that cumbersome.  It would take me less than a minute to post a
> patch on BZ.

I challenge you to do ANYTHING in BZ in a minute.  But posting the patch
seems silly.  Post the commmit.  You need the commit anyway to identify
the particular commit that was QAed.

> But once the change is in the repo it is too late.  You shouldn't commit
> a change before it is QA'd.  If the change is in the repo then there is
> a high chance that the change will make it to the final guide without
> being checked.

No, no, no.  The whole point of a repo like git is to make working
collaboratively easy.  For that to work you need to commit frequently.
The idea that somehow what is in the repo is sacred is a view that makes
working together hard.  Sure, it may have held some sway back in the RCS
days before collaborative RCSs were available, or maybe even with CVS
where doing anything is so bloody hard and fraught with risk, but wit
git there is no argument not to commit, certainly not if you have a way
to identify QAed commits.

For a lot of the guides you can get away with it because there is only
one person working on the guide.  If more than one are working at the
same time you absolutely must commit frequently or you stand the risk of
tripping all over each other.

> The pending list already exists...  it's called BZ.

It only exists if you go through all the extra manual steps.  And
finding what you want to publish could be a real challenge.  Sure, for
QA its easy, just search on open bugs with a QA needed tag.  But when
you want to publish something, you will be looking in closed bugs which
eventually will get to be quite a list.  And how do you know what
release?  Do you go searching through all the commits until you find the
matching patch?

> When was the last time you tried to roll back an edit that was made
> several pushes ago?

I fail to see what's so tough about git checkout QA-DONE-17 or whatever.
The only messy bit I see is that you would probably want to keep the
history of QAed commits, so each completed QA would want to have a new
name, probably a serial number.  I could see multiple QA requests as
well, although I see less need for keeping the history.

> I'm good with 2-4.  I hadn't really thought about doing something like
> this.  I don't know that this is possible in SVN, though.

It is.  Of course, like everything in SVN it's slower and more
complicated, but the tagging idea is pretty similar.  It's just that SVN
has no concept of a global commit, so the author has to be careful to
tag a complete, coherent set of commits.

> nb?

That was the first thought that came to my mind.

> Well, I was talking more about a tag that isn't there but should/could
> be and not a broken tag.

I hadn't thought about that.  That could be a big win.

--McD