Bug 895660 - RFE: Throw error when revision entry is missing one of day/month/year.
RFE: Throw error when revision entry is missing one of day/month/year.
Product: Publican
Classification: Community
Component: publican (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jeff Fearn
Depends On:
  Show dependency treegraph
Reported: 2013-01-15 13:14 EST by Stephen Gordon
Modified: 2013-04-26 00:12 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2013-04-17 22:25:44 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Stephen Gordon 2013-01-15 13:14:14 EST
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.
Comment 1 Stephen Gordon 2013-01-15 13:18:30 EST
Note of course this solution wouldn't help for books that have revision history entries in this state already.
Comment 2 Jeff Fearn 2013-02-11 00:38:55 EST
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.
Comment 3 Jeff Fearn 2013-04-17 22:25:44 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.