[Koha-devel] Release Manager 3.6

[LAURENT Henri-Damien]

Le 12/05/2011 19:17, Galen Charlton a écrit :
> Hi,
> 
> On Thu, May 12, 2011 at 1:03 PM, Doug Dearden <dearden at 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