Le 12/05/2011 19:17, Galen Charlton a écrit :
Hi,
On Thu, May 12, 2011 at 1:03 PM, Doug Dearden <dearden@sarsf.org> wrote:
Reading this thread I think the core issue is this. Can a *big* enhancement that has been developed by one company be signed off by that company as well. Currently the work flow suggests that anything more than minor bugs should not be signed off by someone in the same company. However, if within the company developer A has done the work, developer B has tested it and signed off internally, and it is in use at a library that the company supports and is running without issue, then is that enough to allow it to be pushed to the master branch of that release? I think it is.
I disagree. Successful use in a library is evidence that the feature meets that particular library's needs. It is not sufficient evidence that the implementation of the feature is good and does not interfere with other libraries' use of Koha. It is also not sufficient evidence that the work has been constructed, documented or explained enough for other users or developers to understand, build on, or enhance the feature.
The larger the feature, the more independent review matters. I would consider one developer working for a given employer signing off on the work of another employee to be the bare minimum of acceptable process, and for small patches, that's often enough. For larger features, particularly ones that involve architectural changes, I will make a flat out assertion: sign-offs within the same employer doesn't cut it. It has to work well enough and be explained well enough that, at minimum, the QA manager and the release manager can understand it and test.
One key thing is that larger features *must* be developed incrementally, in the open, and with as much discussion as possible. Well on that regard, we have never been developped in the background.
It has been announced with RFCs, it has been added with bugs. Discussion, with whom, when, where ? At least we never avoided that. For many aspects, we have tried to provoke discussion before. The fact is that we cannot always beg for comments externally and wait for ppl to realise that we are working. We also have due dates. Every one has. If ppl are not willing to discuss the moment we need to discuss, when things are done, if there is discussion, then ppl may also share the work and not just burry others with idle criticisms. And about documentation and explanation, well, it seems quite strange to say so when you look at the current status of most of the current code and all the oddities in behaviour or coding standards we have seen. I reckon we also took a part in that. And maybe you will say that our contributions are so terrible we should not even dare. But still, the remove items branch was quite a common work... even if it took much time. And I think it was valuable, although you missed one of the important point I tried to assign : display. (it was done maybe quite awkwardly for want of time, but done) And then again, documentation is nice, but also needs to be maintained and detailed. And something that may seems obvious to one person can not be for someone else... For what it is worth, most of the time, we have to dive into the code and cannot rely on the documented behaviour. -- Henri-Damien LAURENT