Red Hat Bugzilla – Full Text Bug Listing
|Summary:||RFE: Throw error when revision entry is missing one of day/month/year.|
|Product:||[Community] Publican||Reporter:||Stephen Gordon <sgordon>|
|Component:||publican||Assignee:||Jeff Fearn <jfearn>|
|Status:||CLOSED WONTFIX||QA Contact:||tools-bugs <tools-bugs>|
|Version:||3.0||CC:||lnovich, rglasz, r.landmann, rlandman|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-04-17 22:25:44 EDT||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
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.