Bug 895660

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>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.0	CC:	lnovich, rglasz, rlandman+disabled, rlandman
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-04-18 02:25:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Stephen Gordon 2013-01-15 18:14:14 UTC

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> - 1-137
* Fri Sep 20 2013 Dude McPants <Dude.McPants> - 1-136
* Tue Sep  4 2012 Dude McPants <Dude.McPants> - 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 18:18:30 UTC

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 05:38:55 UTC

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-18 02:25:44 UTC

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.