Red Hat Bugzilla – Bug 895660
RFE: Throw error when revision entry is missing one of day/month/year.
Last modified: 2013-04-26 00:12:15 EDT
Description of problem:
A user approached me because they were having a difficulty building a book, they were receiving this familiar error:
error: %changelog not in descending chronological order
The latest revision entry looked ok but after some time I worked out that the issue was a revision that had been added in the distant past with a date of the following form (no year):
Thurs Sept 20
The book had built with this entry for some time, it appears the reason is that somewhere (the XSL?) the year to use in the corresponding changelog entry in the spec file is "guessed" based on the current year if it is missing. As a result the book continued to build OK in 2012, the year the errant entry was added, but once the year changed to 2013 it broke because it ended up looking something like this:
* Mon Sep 24 2012 Dude McPants <Dude.McPants@redhat.com> - 1-137
* Fri Sep 20 2013 Dude McPants <Dude.McPants@redhat.com> - 1-136
* Tue Sep 4 2012 Dude McPants <Dude.McPants@redhat.com> - 1-135
Debugging this ended up being quite hard because there were many subsequent revisions in the file all of which were known to have build successfully. I think that it would be more appropriate if we detected this situation (where a revision entry is missing one of the date values, particularly year or month) and threw a fatal error up front.
Not doing this and relying on the "guessing" of the missing value as we do now defers an inevitable error to some poor soul in the future.
Note of course this solution wouldn't help for books that have revision history entries in this state already.
All date parsing modules default to the current year. We'd have to select a specific format to use a regex to match it on.
We could expose that to brands so they can enforce their own standards. We won't do it by default though, since it'd pretty rude to try and force it people who may have their own preferred format.
Putting this in the too hard basket. Given there is no constraint on the format used for inputting dates the amount of effort required to do this far out weighs the benefits.