Kenneth was updating all default plugins on twiki.org using the BuildContrib
. The above mentioned topic version shows the content of the SlideShowPlugin
instead of the SmiliesPlugin
Looks like a BuildContrib
See possibly related Item3454
This is obviously not easily reproducable, as BuildContrib
is used to update plugins on t.o on a daily basis without any error. Therefore we need to know exactly what steps were followed to create this situation, and whether any manual steps (such as copying topic texts from one plugin directory to another) were followed. Thanks.
I was updating a large number of the default plugins over a period of 3 days.
For some plugins I was first updating the form fields of the topic by hand such as clicking on Test on 4.1
Then from my build svn checkout I ran - inside twikiplugins/SomePlugin/lib/TWiki/Plugins/SomePlugin I ran..
perl build.pl release
perl build.pl upload
Answering just 'y'
Never saw any errors.
For many plugins I finally had to hide the attachments that are graphics (a real pain in the butt to do when there are 30 of them).
It happened quite often that the revision written was 1. There is another bug item on this. I did not notice at the time. Same with SmiliesPlugin
. I never noticed that the entire text was wrong. It was an addembly line process I was doing with updating many plugins in a row.
And more than 24 hours had passed before anyone noticed that SmiliesPlugin
has the text from SlideShowPlugin
I never uploaded the text in a plugin manually. But I edited some manually afterwards when the original had some text at the top. This was not the case with SmiliesPlugin
One thing we have to remember is that twiki.org still runs on the old buggy 4.0.2 code. Hopefully all mod_perl or Speedy stuff is turned off.
I doubt it's t.o's problem. I find it very hard to imagine how any of the code could do this, unless a file crossed between the two plugins....
I think the only thing with this one is to "park" it for a while to see if it happens again. Now we will know to check and can better analyse what happened if it happens again.
Flipping to "Waiting for Feedback"
Don't expect me (the reporter) to provide more feedback.
Guess CC just picked the one of our states that best fits the - monitor - state that we do not have.
If it is New everybody will continue to open it to see if it is something they can fix.
There has been no feedback on this, and no indication it is reproducable. So I'm setting it "No Action" - if it happens again, I'm sure it will be reported soon enough, but right now this report has no value.
This is not the first time a bug is dismissed "just like this". So let it be as "no action required", but I find dismissing real bugs has no value in reporting bugs either.