On 22/03/15 08:54, Patrick Schaaf wrote: >> Sure, I can agree on RFC all the things. > Probably not all things, but surely everything visible at the language > level, that would need documentation. Syntax, functions, function argument > changes. Probably also changes of official C level API for module authors > (thinking about session management, ZPP, etc). > > Pure C level refactoring - probably not. And not for bugfixing that brings > code behaviour fully inline with what's already documented.
While everything SHOULD be properly commented in the commit notes, isn't this just a matter of WHERE something is documented? If a bug is found and it's not got a record then a bug entry is raised and tagged in the commit log. That is where discussion takes place if there is something that needs discussing. If the bug fix goes beyond 'code behaviour fully inline with what's already documented' then it needs an RFC? I though that was already documented practice? 'Pure C level refactoring' is a grey area. Certainly the commit notes MUST have a reason justifying the change, but isn't this an area where refactoring may affect different builds in different ways? Again some means of hanging comments on a change would be useful, and the github tracker is not the place for that? So perhaps since it may actually introduce unseen bugs, it also needs a bug report? Even white space and style refactoring can be a pain at times when one is working through where a later regression originated? -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
