Hello,
i'm not aware of the exact rules regarding the bug-fixing freeze of the master branch, hence this question.
I accidentally introduced a needless string copy in sql_xquery(), sql_pvquery() and auth_db's load_credentials because i was unaware of the fact that pv_setf_t () already requires implementations to implement a string copy of their own.
As this is not strrictly a bug (everything works well but just a little less efficient), would removing this needles copy violate the 'freeze' rules, or can i consider it a bug fix?
The patch i'm proposing to commit is attached.
Alex wrote:
i'm not aware of the exact rules regarding the bug-fixing freeze of the master branch, hence this question. I accidentally introduced a needless string copy in sql_xquery(), sql_pvquery() and auth_db's load_credentials because i was unaware of the fact that pv_setf_t () already requires implementations to implement a string copy of their own. [..]
Hello Alex,
during the code freeze no new features or user/ developer visible interface changes are allowed. After the stable branch is created, the same rules applies also to there. Only bug fixes in code, documentation or utilities are allowed.
One could argue if a fix for a inefficient implementation is really a bug fix, as you also mentioned. In this particular case as its a new introduced functionality and its called for every execution of the PV (if I understand it correctly) it should be fixed now.
If its good tested I'd think it could be also fixed in a stable branch. It makes not that much sense to have stricter rules during a code freeze for stabilization purposes, as in a stable release which is used in production.
Best regards,
Henning
8 sep 2011 kl. 23:58 skrev Henning Westerholt:
Only bug fixes in code, documentation or utilities are allowed.
So while you are waiting you can spend time making sure
- That the documentation is up-to-date with your cool new code - That all the new core functions and variables are part of the wiki cookbook and docs - That you have configuration examples committed
Important question you need to ask yourself about your docs is not only if it's a good reference, but also if it clearly states the problem you are trying to solve. A reference just explains parameters - but that's not enough, you also need to explain why someone should use this module/function/pv and what's cool with it.
When your done with your own docs, feel free not to play games but to check existing documentation too.
Thanks - enjoy writing the docs before you restart coding new stuff after code freeze!
/O
-
Alex Hermann -
Henning Westerholt -
Juha Heinanen -
Olle E. Johansson