please don't squash qa-untestable tags

https://bugs.edge.launchpad.net/malone/+bug/221947 is an example of it doing this.

If one doesn't want the qa-untestable tag to be replaced by needstesting, needs to commit the fix accordingly: use the no-qa tag. That should be enough. Are you suggesting something else?

On Wed, Aug 25, 2010 at 5:58 AM, Ursula Junque <email address hidden> wrote:
> If one doesn't want the qa-untestable tag to be replaced by
> needstesting, needs to commit the fix accordingly: use the no-qa tag.
> That should be enough. Are you suggesting something else?

Yes. no-qa is incompatible with also doing qa.

Here is the situation. There are two bugs, bug A is QA able, bug B is
internal tech debt.

In the course of fixing bug B, bug A is also fixed.

bug B can be QA'd, thus --no-qa on ec2-land is inappropriate.
bug A cannot be QA'd, its internal only.

So I'm saying that the tagger should honour tags put in place by the
engineer when they are sensible. (qa-ok would not be sensible,
qa-untestable is, because you can tell that in advance).

qa-untestable is also the tag of an incremental fix, so I can't (the way things work today) keep qa-untestable bugs untouched because when the last commit of a series of incremental ones lands, qa-tagger needs to change the bug from qa-untestable to qa-needstesting.

I believe we should use another tag to say a bug is definitely untestable, maybe by differentiating qa-untestable from qa-unneeded, which are different imo. Untestable: this cannot be tested, even if I want to; Unneeded: this doesn't need QA, don't touch it. What do you think?

uhm, so this speaks to the tension between 'fit for purpose' and 'fit for deployment'.

Our qa system is (by observation when I started) used primarily to detect 'ok to deploy'.

So incremental changes on a feature represented by multiple bugs *should not* be qa-untestable. They should each get qa verified asap to allow deployment to proceed.

Does this help?

We discussed on the phone; perhaps the best thing is to keep it simple:
 - if a commit alters many bugs, and any need qa, all need qa.
 - as developers, don't set qa-* flags until the commit lands

I will mail the list to seek more input.

End result was - keep it simple; just don't set tags until the commit is on qastaging. We're working on making that faster.