Bug 861277 - RFE: Automatic revision history
RFE: Automatic revision history
Status: NEW
Product: PressGang CCMS
Classification: Community
Component: CSProcessor (Show other bugs)
1.0
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: pressgang-ccms-dev
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-28 00:13 EDT by Matthew Casperson
Modified: 2015-09-27 22:54 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Matthew Casperson 2012-09-28 00:13:06 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.
Comment 1 Lee Newson 2012-10-09 02:26:06 EDT
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.
Comment 2 Lee Newson 2013-05-05 22:08:42 EDT
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.
Comment 3 Lee Newson 2013-05-05 22:09:41 EDT
Oops, that was meant to be Bug #958331 comment 7.
Comment 4 Joshua Wulf 2013-05-05 23:33:01 EDT
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.
Comment 6 Joshua Wulf 2013-05-06 07:15:28 EDT
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.
Comment 7 Matthew Casperson 2014-01-12 16:47:03 EST
Related bug: https://bugzilla.redhat.com/show_bug.cgi?id=912202
Comment 8 Ruediger Landmann 2014-03-05 22:30:53 EST
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
Comment 9 Ruediger Landmann 2014-03-05 22:33:17 EST
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.
Comment 10 Andrew Dahms 2014-03-06 01:12:15 EST
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.
Comment 11 Andrew Dahms 2014-03-06 01:19:39 EST
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.

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