Red Hat Bugzilla – Bug 838984
csprocessor builds now break if topic title is changed
Last modified: 2014-10-19 19:01:02 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%
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.
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. :-)
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.
Added in 0.25.2. The processor will now operate as indicated above.
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.