Red Hat Bugzilla – Bug 861277
RFE: Automatic revision history
Last modified: 2015-09-27 22:54:45 EDT
Any major updates to a topic should optionally be included in the revision history with a command like --populate-revision-history or something. Note that the revision history requires an email address, which we might be able to get from the description of the assigned writer tag assigned to the topic.
The other issue with this, as we discussed, is how do you tell if a revision message should be included between CSP builds, as we don't currently capture publishes.
Continuing on from Bug #958331 comment 5. You could do that, however then the topic would have to be used from one of our internal tools and you couldn't just use an xi:include. I think a better solution might be to set a property tag to specify the last time the revision history was generated. I had thought about maybe using the Last Modified field on the topic, but that has issues if you are using the second approach where a user has to edit the generated Revision History, which would be a requirement.
Oops, that was meant to be Bug #958331 comment 7.
Here's how it currently works on the Press Star ("Rockstar workflow for PressGang"): http://post-office.corp.redhat.com/archives/pressgang-ccms/2013-May/msg00010.html I've considered local time differences. At the moment it takes the date from the Revision History entry, and then grabs all commit messages after that date. Since the timestamps are all assigned on the PressGang server (in the same timezone) there should be no problem. The only edge case would be if someone in Brisbane generates a Revision History, then does some work, then someone in Brno or India attempts to include those revisions on the same day. This is a sufficiently unusual situation at the moment that I haven't catered to it in the initial release. As far as conditional changes go -that's a good point. I don't use conditions, so I haven't included this in the initial release. How widely and effectively conditions are used, and in what way that interacts with Revision History generation needs some more examination.
Ya. Duplicate entries are not a problem - it's missed entries that would be problematic. I'll have to spend some time with the code to figure out the exact implication of the local time of the browser. I think we are pretty safe in the meantime though, because everyone's browsers will be either at the same local time or behind the local time on the PressGang server (GMT +10). So there may be duplicates (which can always be manually groomed), but there shouldn't be any missed entries.
Related bug: https://bugzilla.redhat.com/show_bug.cgi?id=912202
An automated Revision History would also have to * accommodate the situation where a reused chunk has bugs attached to it that are applicable to the book for which it was written but not the current book (and for the reverse case where we need to attach bugs applicable for just the book in which this chunk is now being included) ** ideally, provide a one-click facility to clone existing bugs to the current book (and then include those in the Revision History) * "grandfather in" and extend an existing Revision History that existed in a book prior to its import into PressGang * accommodate changes (and any associated bugs) that relate to the organisation of the book map rather than its constitutent chunks * handle revisions from translated versions of the book
Oh, and: * suggest or default to an appropriate Version-Release combo for the package, based on the level of change detected in the map from the previous build of the book. Bonus points if PressGang can verify that the proposed NVR is available in the build system prior to sending it there.
With the automated revision function, would it be possible to only increment the revision history when a build is finalized? For example, if a book is built, multiple bugs are addressed and then the book is built again, it would be cleaner to have them all added to the same revision rather than creating a new revision for each bug or change.
Two more requests: 1. If changes are made to a topic that is included in several content specs, would it be possible to update the revision history in those books as well? I imagine this would need to account for books that are no longer 'active' so that changes are only applied to books in which the updated content will appear. Likewise, would it be possible to prompt for the user name and email address when updating revision history? 2. Would it be possible to account for dead links? For example, if the revision history includes some function for pointing to changes in a book, the topics that include those changes might be removed, which would result in a dead link.