Hello all,
the truth is that I should have separated this email into two threads. However they have a
relation, so let's discuss them in one place.
The first:
While is not mandatory begin an eqawarn with "QA Notice" and thus there are no rules
about that I think it helps while grepping on build logs.
All of us agree that is should be fixed in the eqawarn function, but it won't happen soon.
So, if you are interested to get bug reports (at least from me) about unprefixed eqawarn,
please add the usual "QA Notice:" prefix as we did in https://bugs.gentoo.org/728046[1]
If you think that add "QA Notice:" will break existing scripts or so, please let us know.
I'm adding as attachment the list of eqawarn that miss the 'QA Notice' prefix.
The second:
By filing bugs for eqawarn/qa notice, I have been pointed out, for some class of issues,
that a bugreport is not needed.
At this point, since bugs can be filed by everyone, I think is better introduce something
that make clear that we do not expect a bugreport about a particular issue.
An example is here:
eqawarn "QA (Dev) Notice: ........"
eqawarn "......"
eqawarn "......"
eqawarn "Please remember that QA (Dev) Notice do not deserve a bugreport"
In other words a "QA (Dev) Notice:" is supposed to be one or more of the following:
- something useful for maintainer at the bump time
- something that is not worth for a bugreport
- something that is not worth for an immediate fix
- something that will disappear soon with a new version of a package
Two side notes:
1)
I have tried to introduce that on irc in #gentoo-qa to get a feedback about that, but I have
not received a response, so this should be the proper place.
So this is NOT to point the finger to people that did not answer, but it's just to say that I'm
not expecting something like: "why you didn't discuss this with us first" from qa ;)
2)
@ionen already pointed out to me that configure.in qa notice in autotools.eclass no dot
deserve a qa notice.
What do you think?
Agostino
--------
[1] https://bugs.gentoo.org/728046
the truth is that I should have separated this email into two threads. However they have a
relation, so let's discuss them in one place.
The first:
While is not mandatory begin an eqawarn with "QA Notice" and thus there are no rules
about that I think it helps while grepping on build logs.
All of us agree that is should be fixed in the eqawarn function, but it won't happen soon.
So, if you are interested to get bug reports (at least from me) about unprefixed eqawarn,
please add the usual "QA Notice:" prefix as we did in https://bugs.gentoo.org/728046[1]
If you think that add "QA Notice:" will break existing scripts or so, please let us know.
I'm adding as attachment the list of eqawarn that miss the 'QA Notice' prefix.
The second:
By filing bugs for eqawarn/qa notice, I have been pointed out, for some class of issues,
that a bugreport is not needed.
At this point, since bugs can be filed by everyone, I think is better introduce something
that make clear that we do not expect a bugreport about a particular issue.
An example is here:
eqawarn "QA (Dev) Notice: ........"
eqawarn "......"
eqawarn "......"
eqawarn "Please remember that QA (Dev) Notice do not deserve a bugreport"
In other words a "QA (Dev) Notice:" is supposed to be one or more of the following:
- something useful for maintainer at the bump time
- something that is not worth for a bugreport
- something that is not worth for an immediate fix
- something that will disappear soon with a new version of a package
Two side notes:
1)
I have tried to introduce that on irc in #gentoo-qa to get a feedback about that, but I have
not received a response, so this should be the proper place.
So this is NOT to point the finger to people that did not answer, but it's just to say that I'm
not expecting something like: "why you didn't discuss this with us first" from qa ;)
2)
@ionen already pointed out to me that configure.in qa notice in autotools.eclass no dot
deserve a qa notice.
What do you think?
Agostino
--------
[1] https://bugs.gentoo.org/728046
Attached Files:
-
eqawarn.txt (2.45 KB)