[Koha-devel] Release Manager 3.6

[Doug Dearden]

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 at lists.koha-community.org [mailto:koha-devel-bounces at lists.koha-community.org] On Behalf Of LAURENT Henri-Damien
Sent: Thursday, May 12, 2011 10:51 AM
To: koha-devel at lists.koha-community.org
Subject: Re: [Koha-devel] Release Manager 3.6

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
_______________________________________________
Koha-devel mailing list
Koha-devel at 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/