[Koha-devel] Release Manager 3.6

[LAURENT Henri-Damien]

Le 12/05/2011 17:34, Nicole Engard a écrit :
> On Thu, May 12, 2011 at 11:30 AM, Paul Poulain
> <paul.poulain at biblibre.com> wrote:
>> Can I say you're saying: "BibLibre has a problem, fix BibLibre"? So
>> you've inclined to vote 2 to my previous question?
>> (Or do I go too far, and it's not what you want to say)
> 
> I'm saying that you're not giving your librarian/project manager
> enough credit. I'm saying that as a trainer I hate it when people say
> that a librarian can't do something cause they're a librarian.
> 
> Nicole
Well,
 translations, trainings, project management, interface with libraries
in the global design are already HUGE tasks. It is not a matter of
'credit', it is a matter of time.
I donot want to ask them to spend time on what looks geeky stuff to
them. They have a role, with enough responsablility and are devoted
enough not to add them a task, taking the git code onto their laptop,
and adding sign-off on the patch.
But ok it is not out of reach to imagine that future patches will have
sign offs when they are submitted, even fancy ones like Limoges and
Saint Etienne...
Even though, sign off changes the commit id. With a merge workflow, it
breaks the whole thing. But OK the community despises merge workflow. We
could send patches onlist. Fair enough... For the future, if we can
continue to contribute.
But we have some old patches there. And those patches are touching
serious parts (circulation and members). And those patches are important
both for us and for some of our libraries.
And rebasing, having to reengineer them over and over makes that more
and more risky. Adding a REBASE tag to the patch and resending all the
patches that need rebasing any time they need rebasing would quite spam
the list I guess with the 150 patches waiting sign-off (I am not
speaking of BibLibre particularly there but xss patch for instance.).
Friendly
-- 
Henri-Damien LAURENT