Transition-Regression Tag

[C de-Avillez]

On Tue, 2009-06-02 at 10:41 -0700, Brian Murray wrote:
> It seems to me that this type of a bug, a functional regression caused
> by changing the default application from one to another, is actually a
> subset of the regression-potential tag.  Subsequently, I think tagging
> these as 'regression-potential' is the best idea but that a secondary
> tag, perhaps 'default-application', would be highly beneficial.  By
> having this secondary tag we could then separate the
> 'default-application' potential regressions from other potential
> regressions. 

I agree, sort of. I agree that we need to group all *possible*
regressions under one theoretical umbrella -- and, right now, Brian's
proposal is the nearest we can get.

But.

I would really like to see a hierarchy on tags. Tags are, by definition,
ad-hoc in relation to the BTS (i.e., they provide some information that
the BTS does not directly support). As such, we can have -- literally --
anything as a tag.

On the other hand, some situations arise where we would like to be able
to group together some tags, perhaps because they are specific cases of
a general concept. The easiest way to get it done would be by forcing a
hierarchy on tag naming (on these cases, *not* generically):

regression
   regression-potential
   regression-default-app
   regression-required
apport
   apport-i386-retrace
   apport-amd64-retrace
   apport-retrace-failed
etc, etc.

So (given, of course, that LP would allow us) if I want to see all types
of regression, I would search for -- say -- "regression*", or
"regression". If I just want to see regressions caused by default
applications (in the meaning proposed by Brian C), I then would search
only for "regression-default-app".

And so on.

On yet another hand, this would create a lot more of work, *unless* LP
is adjusted to support it. Still. one can dream ;-)

One thing to be kept in mind is that a BTS is a living entity: it starts
in one form (as designed), and then usage imposes other views. For
Malone/LP, or any other BTS, to survive useful, adaptations *must* be
discussed, analysed, designed, and implemented (of course, the last two
only if the adaptation is considered useful).



-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/ubuntu-bugsquad/attachments/20090602/951b6dc4/attachment.pgp