277572 - Functions for message output in checksetup

Status: NEW

(Bugzilla :: Installation & Upgrading, enhancement, P3)

Description

[Max Kanat-Alexander]

I think that we should centralize how messages are output in checksetup. Then we
could have more control over them, like making errors more obvious (which is
some other bug that I forget about) and centralizing the "unless $silent" check.

The functions would probably be:

InfoMessage()
ErrorMessage()
DebugMessage()

Comment 1

[Max Kanat-Alexander]

We also need ChangeMessage().

From IRC:

<vladd> ...Info messages need to be split it one-timers and reproductible :)
<avatraxiom> Oh, that's true, too.
<avatraxiom> Although reproduceable messages should be ErrorMessages, I'd think.
<vladd> Stuff like "Adding new field..." or "Upgrading DB..." is a one-timer,
and the informational "Finished DB check" is another one :)
<avatraxiom> Ohh, right.
<avatraxiom> So maybe ChangeMessage().
<avatraxiom> To be used whenever there's a change made by checksetup.
<vladd> Yeah, I'd hesitate to call "Finished DB check" a DebugMessage() :-)
<avatraxiom> :-)
<vladd> $silent should display then only ErrorMessage() and ChangeMessage(), and
InfoMessage() should be displayed only with $silent=0.

Comment 2

[Vlad Dascalu]

Basically, we have now 4 severities, in this order:

* ErrorMessage()  # errors that require user's attention.
* ChangeMessage() # messages not reproductible when running again checksetup.pl
                  # e.g.: "Adding field xxx to table yyy"
* InfoMessage()   # reproductible, informational messages.
* DebugMessage()  # really verbose output, used for debug purposes.

The current policy is:

+------------------------------+----------------+-------------------+
|       Function name          | Displayed with |  Displayed with   |
|                              |  $silent = 0   |    $silent = 1    |
+------------------------------+----------------+-------------------+
| ErrorMessage()               |     YES        |        YES        |
| ChangeMessage()              |     YES        |        YES        |
| InfoMessage()                |     YES        |        NO         |
| DebugMessage()               |     NO         |        NO         |
+------------------------------+----------------+-------------------+

It doesn't make sense to have a situation where we should display ErrorMessage()
but suppress ChangeMessage(). Even crontab runners want both of them. If users
are picky, we could do "checksetup.pl > output.txt" and only ErrorMessage()
would appear to the screen (ErrorMessage() should output to strerr, BTW).

Instead, probably we want a $debug mode or something that displays
DebugMessage() as well.

"Checking xxx" is an InfoMessage() when output is generated if checking detects
no problem, and a DebugMessage() otherwise.

So "Checking for Perl packages" is an InfoMessage() because there will always be
input after it, even if everything is ok. "Checking if I should add field XXX to
table YYY" is a DebugMessage().

Comment 3

[Frédéric Buclin]

The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.

Comment 4

[Frédéric Buclin]

This bug is retargetted to Bugzilla 3.2 for one of the following reasons:

- it has no assignee (except the default one)
- we don't expect someone to fix it in the next two weeks (i.e. before we freeze the trunk to prepare Bugzilla 3.0 RC1)
- it's not a blocker

If you are working on this bug and you think you will be able to submit a patch in the next two weeks, retarget this bug to 3.0.

If this bug is something you would like to see implemented in 3.0 but you are not a developer or you don't think you will be able to fix this bug yourself in the next two weeks, please *do not* retarget this bug.

If you think this bug should absolutely be fixed before we release 3.0, either ask on IRC or use the "blocking3.0 flag".

Comment 5

[Max Kanat-Alexander]

Bugzilla 3.2 is now frozen. Only enhancements blocking 3.2 or specifically approved for 3.2 may be checked in to the 3.2 branch. If you would like to nominate your enhancement for Bugzilla 3.2, set the "blocking3.2" flag to "?". Then, either the target milestone will be changed back, or the blocking3.2 flag will be granted, if we will accept this enhancement for Bugzilla 3.2.

This particular bug has not been touched in over eight months, and thus is being retargeted to "---" instead of "Bugzilla 4.0". If you believe this is a mistake, feel free to retarget it to Bugzilla 4.0.