On Thu, May 12, 2011 at 11:30 AM, Paul Poulain <paul.poulain@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,
Greetings all, 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. As a minor developer (I submitted an enhancement that the librarian where I work wanted implemented) I can say that I welcomed the help of the community, including the feedback during the process as well as some revisions to my code to make it cleaner. The process was a little daunting for a total newbie but I got a lot of help and was happy to have the requirement in place that someone else sign off on my changes. But I am the IT support person for a small non-profit that includes an academic library. This is a small part of my job, not my primary business. I don't mind having different rules for me than for those that are providing the primary development and support for Koha. So perhaps a simple change fixes this, allowing an internal sign off for any bug/enhancement, not just for the "minor" ones. Then push to master so no one has to rebase constantly. Or am I missing something crucial? Regards, Doug Dearden Director, IT School for Advanced Research (505)954-7220 sarweb.org -----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] On Behalf Of LAURENT Henri-Damien Sent: Thursday, May 12, 2011 10:51 AM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] Release Manager 3.6 Le 12/05/2011 17:34, Nicole Engard a écrit : 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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/