Bug 838984 - csprocessor builds now break if topic title is changed
csprocessor builds now break if topic title is changed
Status: CLOSED CURRENTRELEASE
Product: PressGang CCMS
Classification: Community
Component: CSProcessor (Show other bugs)
1.x
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Lee Newson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-10 10:50 EDT by Joshua Wulf
Modified: 2014-10-19 19:01 EDT (History)
3 users (show)

See Also:
Fixed In Version: 0.25.2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-06-06 21:29:21 EDT
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 Joshua Wulf 2012-07-10 10:50:30 EDT
[jwulf@radhe Messaging_Programming_Reference]$ csprocessor build
CSProcessor client version: 0.25.1
Loading configuration from /home/jwulf/.config/csprocessor.ini
Loading project configuration from csprocessor.cfg
Connecting to Skynet server: http://skynet.usersys.redhat.com:8080/TopicIndex/

Starting to parse...
Attempting to download all the latest topics...
Starting to validate...
ERROR: Line 67: Invalid Topic! Existing topic title doesn't match.
       -> Specified: A Simple Messaging Program in Java JMS [8039]
       -> Topic 8039: Java JMS "Hello World" Program Listing
ERROR: The Content Specification is not valid.

I'm fairly sure that csprocessor build would not halt on a topic title / ID mismatch previously, because my automated scripts do not check for this condition - they rely on the fact that the ID/title match is only done when the spec is pushed.

==============================
Generated Details:

Package: cspclient-0.25.1-1.noarch

OS: Fedora release 16 (Verne)

JAVA: java version "1.7.0"
Java(TM) SE Runtime Environment (build 1.7.0-b147)
Java HotSpot(TM) Client VM (build 21.0-b17, mixed mode, sharing)


CSProcessor client version: 0.25.1
Loading configuration from /home/jwulf/.config/csprocessor.ini
Loading project configuration from csprocessor.cfg
Connecting to Skynet server: http://skynet.usersys.redhat.com:8080/TopicIndex/

Content Specification ID: 8025
Content Specification Revision: 158032
Content Specification Title: Messaging Programming Reference

Starting to calculate the statistics...
Total Number of Topics: 229
Number of Topics with XML: 44
Percentage Complete: 19.21%
Comment 1 Lee Newson 2012-07-10 18:46:02 EDT
The reason that used to work was because of a bug where builds weren't validated first. I also can't see any reason why you should not be able to build an invalid content specification, so unless you have a good reason why you should be able to build an invalid content specification, then I'm going to mark this as closed.
Comment 2 Joshua Wulf 2012-07-10 20:09:05 EDT
When a human pushes a Content Spec, the robot has to make sure that it unambiguously understands what the human wants to do.

An "invalid content spec" is one where the robot says: "I'm sorry sir, I'm not sure that I understand precisely what you want me to do here. Did you want a topic with title "FooBar", or the topic with the ID 63, whose title is "FoodBar"?"

I then tell the robot: "thanks for getting back to me, and not just running off and making your own arbitrary guesstimate. I actually want topic 63 with title FoodBar." 

I can do this quickly by pushing with -p.

Once that's done, the robot and I are both clear on which topics are in the book, and where they go, and the robot goes on happily rebuilding my book automatically.

Later on, I change the title of topic 63 in Skynet to read "Food Bar". 

Then I try to rebuild.

The robot then says: "I'm sorry, I can't build this. Do you want topic 63, or the topic with the title 'Food Bar'?"

And I say: "Are you are retard? We already had this conversation and we clarified which topics are in the book. All I did was edit a title. Now you're confused? What's your problem?"

Which I can get around by writing a script that says "build -p". So it's not a breaker, but it's important from a usability perspective to understand that in this case the content spec is not "invalid" like it is when pushing.

In this case, the robot doesn't have to punish the human for not dancing the right way, because the intent was clarified earlier, and what's happened in 99.9% of cases is that a correction has been made to a topic title.

For my automated build system, most of the time people are correcting, improving or changing the titles between builds, and previously it built with no problem. The content spec was not "invalid". The titles were being edited. The content spec built fine, and the book looked the way I expected it to look.

For the robot to suddenly come back and say: "Hi, I used to do what you would naturally expect, but now you have to do what I expect! Once I was the servant, NOW I AM THE MASTER!" was kind of a surprise. :-)
Comment 3 Lee Newson 2012-07-10 21:02:02 EDT
Hmm very good points. I'll change it so that when building from an ID (ie a spec that has been pushed) it'll by default set the -p flag. However when building from a content spec file it may not have been pushed and will need to be validated.
Comment 4 Lee Newson 2012-07-13 00:38:21 EDT
Added in 0.25.2.

The processor will now operate as indicated above.
Comment 5 Lee Newson 2013-06-06 21:29:21 EDT
Closing and setting as current release as no QA was performed by the original reporter. If there is still an issue with this bug still than please re-open it.

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