Traceability in plugin maintenance / process for plugin maintenance

There is not much traceability to be found in this bug item and all the checkins. It is a real pity!

-- KJL

FYI: I develop my plugins against my own repository and only upload released versions to SVN.

-- TW

But the end result is still that there is zero traceability between from the many changes done to your plugins and to the checkins on the TWiki SVN.

It adds a lot of value that you can look at a bug report and see exactly which bug or enhancement that triggered the change.

And it adds a lot of value that when you look at a given file with svn blame and /or svn log you can see the Item number from Bugs and go back and see why the code change was made. The 1-2 lines in the SVN message is rarely enough.

With your plugin checkins all we can see is that it is Item2870, a TW plugin. Duh! Crawford added a SVN script that checks that svn commit messages refers to an active Item for a good reason.

Traceability in software development is key to developing quality software.

Naturally plugin developers develop their plugins and upload them when they work. But I cannot see it is such a big deal to open a bug item, write a few lines of text what you have added of enhancements and fixes since last release, svn commit the changes, and close the report again.

It is perfectly OK to open a bug item for a plugin, and checkin 10 times small enhancements for the plugin on the same report and then close it when you upload the released version on twiki.org.

And it is also OK that we have a bug item for small core doc updates merged in from twiki.org continuously.

But this Item2870 is pure circumvention of the developer policy for this project. See TWiki:Codev.DeveloperResponsibilities

I am closing this bug item now TW.

-- KJL

I can also revert to maintain my plugins outside of SVN, if you so prefer... As I said, I am checking the plugins into SVN because it was requested, for convenience of others. I have them in my own CVS repository which is where I version manage these plugins.... I work off-line too often for me to depend on SVN as the configuration management tool... So your "policy" creates too much inconvenience. I respect that policy for managing the core code. But I should be entitled to manage the development of my plugins the way I see best fit, right?

-- TW

For any plugin that were to be part of the standard release, I agree with you, it should be maintained following the process for the core.

-- TW