2015-07-22
A modest little change I'd like to see in bug reporting systems
It is my opinion that sometimes little elements of wording and culture matter. One of those little elements of culture that has been nagging at me lately is the specifics of how Bugzilla and probably other bug reporting systems deal with duplicate bug reports; they are set to 'closed as a duplicate of <other bug>'.
On the one hand, this is perfectly accurate. On the other hand, almost all of the time one of my bug reports is closed out this way I wind up feeling like I shouldn't have filed it at all, because I should have been sufficiently industrious to find the original bug report. I suspect that I am not alone in feeling this way in this situation. I further suspect that feeling this way serves as a quiet little disincentive to file bug reports; after all, it might be yet another duplicate.
Now, some projects certainly seem to not want bug reports in the first place. And probably some projects get enough duplicate bug reports that they want to apply pressure against them, especially against people who do it frequently (although I suspect that this isn't entirely going to work). But I suspect that this is not a globally desirable thing.
As a result, what I'd like to see bug reporting systems try out is simply renaming this status to the more neutral 'merged with <other bug>'.
Would it make any real difference? I honestly don't know; little cultural hacks are hard to predict. But I don't think it would hurt and who knows, something interesting could happen.
(In my view, 'closed as duplicate' is the kind of thing that makes perfect sense when your bug reporting system is an internal one fed by QA people who are paid to do this sort of stuff efficiently and accurately. In that situation, duplicate bugs often are someone kind of falling down on the job. But this is not the state of affairs with public bug reporting systems, where you are lucky if people even bother to jump through your hoops to file at all.)
Some thoughts on log rolling with date extensions
For a long time everyone renamed old logs in the same way; the most
recent log got a .0 on the end, the next most recent got a .1
on the end, and so on. About the only confusion between systems was
that some started from .0 and some from .1, and also whether
or not your logs got gzip'd. These days, the Red Hat and Fedora
derived Linuxes have switched to lograte's dateext setting, where
the extension that old logs get is date based, generally in the
format -YYYYMMDD. I'm not entirely sure how I feel about this so
far and not just because it changes what I'm used to.
On the good side, this means that a rolled log has the same file name
for as long as it exists. If I look at allmessages-20150718 today, I
know that I can come back tomorrow or next week and find it with the
same name; I don't have to remember that what was allmessages.3 today
is allmessages.4 tomorrow (or next week). It also means that logs sort
lexically in time order, which is not the case with numbered logs; .10
is lexically between .1 and .2, but is nowhere near them in time.
(The lexical order is also forward time order instead of reverse time order, which means that if you grep everything you get it in forward time order instead of things jumping around.)
On the down side, rolled logs having a date extension means that I
can no longer look at the most recently rolled log just by using
<name>.0 (or .1); instead I need to look at what log files there
are (this is especially the case with logs that are rolled weekly).
It also means that I lose the idiom of grep'ing or whatever through
<name>.[0-6] to look through the last week's worth of logs; again,
I need to look at the actual filenames or at least resort to something
like 'grep ... $(/bin/ls -1t <name>.* | sed 7q)' (and I can do
that with any log naming scheme).
I'm sure that Red Hat had its reasons to change the naming scheme around. It certainly makes a certain amount of things consistent and obvious. But on the whole I'm not sure I actually like it or if I'd rather have things be the old fashioned way that Ubuntu and others still follow.
(I don't care enough about this to change my Fedora machines or our CentOS 6 and 7 servers.)