mh->fs: need approval by QA or PM for this.

fs->lho,ms: can I convince one of you both that such a keyword would
make sense?

Really difficult for me to see the reason behind that. Sounds like
your personal keyword, because if it is used once for a certain
purpose, I can't see how somebody else should use it without ruining
your queries. Most other existing keywords are more generic like
"needhelp", "Arabic" and so on. I would understand something like
"accessibility", but "meta", hm? Try your best to convince me, will be
difficult :-)

okay, I'll try :)

The reason why I submitted this is issue 10275:
It is a mere meta issue, which does not require explicit
implementations itself, but instead covers a broad topic (LDAP address
access), which consists of several "sub problems" which are to be
solved nearly independently. issue 10275 depends on 3 other issues,
and only if all of these other three are solved, the area "LDAP
address access" can be considered as fixed (or as "usable in the real
world", or whatever). Thus, people interested in the topic "LDAP
address access" can subscribe to one issue only, and nevertheless be
notified of everything which happens in this area.

Another use case for this would be a meta bug like "finalize
OpenOffice.org 1.1 Beta". This bug could depend on every bug which is
considered important enough to be included in 1.1 Beta, and so people
interested in this release can see the status with looking at the bug,
without hazzling with reports, or every single bug.
(This is how Mozilla handles their releases, and I admit I stole the
"meta idea" from BugZilla - see
http://bugzilla.mozilla.org/describekeywords.cgi and their reasoning
for "meta").

Hmm, forgot to mention that of course all of the above is not really a
reason to have the keyword - but if we consider these use cases as
valid, then we need such a keyword to distinguish these bugs from
"real ones" - and be it only for the statistics :)

one more aspect of the same use case, as I saw (and liked) it in
BugZilla: People can submit there _own_ tracking issues, kind of "make
this product not s#&*$§". If we consider this a valid use case (and a
valid feature for our users), too, then we again would need a
possibility to distinguish these bugs from the real ones.

Frank, how do you want people that are responsible for releases to
know, that these bugs themselves are not release-relevant? They need a
priority, a target milestone and show up as regular bugs. Please don't
say: take them out of release-relevant queries, that's not a feasible
solution. Another question: if 100 people use the keyword "meta", how
do you know which ones are yours?

@Michael:
> Please don't say: take them out of release-relevant queries, that's
> not a feasible solution.

Sorry, but: Why not? It's a question of sending the proper queries to
the database, nothing more. Provided that "not release relevant" is
_well_defined_, which would be the case here.
I still consider the use cases I tried to sketch above valid ones, and
would be interested in if you agree to this.

> if 100 people use the keyword "meta", how do you know which ones are
> yours?

What is "mine"? There are only meta bugs which somebody is /interested
in/ - she will appear on the cc-list then. By chance, somebody needs
to be the _owner_ of a meta bug - a project owner may be a canonic
person there, but this is no MUST and does not really have any relevance.
Other definitions than "I am interested in" are not applicable - by
definition, meta bugs don't require explicit action by anybody,
instead they allow to easily track other bugs which in turn require
action. These other bugs are "mine" or "somebody else'", not the meta
bugs themself.

I will not adjust queries all the time because we invent issue types
that don't need to be tracked. This is error prone, that's why I don't
like doing it.
You request might be valid one, for me it's a low priority RFE like
many others. Tracking certain kind of bugs should be mainly possible
via components.

Somebody MUST own meta bugs, I don't know why you say this is not the
case. Submitting an issue leads to a default owner, who certainly
doesn't want to be the owner of a meta bug.
I still don't get how you want to find the meta bugs YOU are
interested in, if 100 other people use the keyword, too. I guess by
querying for the ones you own?

> Somebody MUST own meta bugs, I don't know why you say this is not
> the case.

Sorry, I maybe was misleading. I don't say we do not need an owner, of
course somebody must own the issue. My "no MUST" was referring to the
project owner being the owner of a meta bug - the ownership of a meta
bug would be simply irrelevant.

> Submitting an issue leads to a default owner, who
> certainly doesn't want to be the owner of a meta bug.

Why?
Only because "being the owner of a bug" implies various things (being
tracked in statistics, for instance :). If "being the owner of a meta
bug" would not have such (potentially displeasing) implications,
everything would be fine.

> I still don't get how you want to find the meta bugs YOU are
> interested in, if 100 other people use the keyword, too. I guess by
> querying for the ones you own?

No, by querying for bugs which have the keyword meta, and where I
appear on the cc list. Being a member of the cc list is the canonic
and intended way to express interest in a bug - I don't necessarily
need to query for the meta keyword then.

> I will not adjust queries all the time because we invent issue types
> that don't need to be tracked.

I see the point, and I see that this should only be done for changes
which are worth it. As this seems to be the disagreement here (the
worthyness of a meta flag), I probably will close the issue.
(Actually, you promised it would be difficult to convince you :)

Thanks, anyway.

RESOLVing as WONTFIX

damn, not LATER, but WONTFIX. re-opening.

now really

closing