Le 12/05/2011 16:58, Nicole Engard a écrit : > On Thu, May 12, 2011 at 10:56 AM, Paul Poulain > <paul.poul...@biblibre.com> wrote: >> I'm not requesting to remove the sign-off. I'm saying our code reaches >> bugzilla already "signed-off" at least twice (project manager and >> customer/library), > > Paul, > > I'm very confused, if your stuff is "signed off" why not just stick > the -s in the format-patch command and be done with it? Show everyone > that it's signed off and it will go to QA and not have to wait for the > rest of us to sign off again. > > If your patches are signed off, just show that in the patch itself. > > Nicole
Nicole We have a merge workflow rather than a sign off on individual patches. That way, features can be tested and integrated much more smoothly. Unfortunately, signing off changes the commit id. And it requires some more actions, that our project manager will not be able and not be willing to add in their process. So that, Paul is speaking of a user sign off but not a git sign-off. That 'git sign-off' all mighty process looks strange to me. It supposes a feature touches only some little parts of Koha, and quite often, it is not the case or makes very little changes. The problem is that those not signed-off patches were rebased from our code, then re-process by Paul and then by Chris, and we kept from signing off on those because Chris wanted some other company to sign them... And Chris kept from having them signed-off by one of his catalyst teammate because he wanted some one else to have a look at them. Problem is that then... noone tests them sign off on them. Your workflow doesnot fit merge workflow. How would we cope with a git-pullrequest ? would we ask for a signoff in every single patch ? would we just test the branch, see how it works and do the merge and if that does not merge straight forward, ask for rebase ? And when you develop things once, twice and then 4 times, one ends up quite nervous at getting things behind. We participated and play our part in sign off, and development process. Some features were not contributed though talked about for some time now. I think because of that kind of thing (thinking of EDI for instance, but maybe some other RFID process). It takes time to reprocess things and to adapt them when new features come into the way. Maybe libraries are ok with that. But in my opinion, when their features have not reached the trunk, they have wasted their money, and developers wasted their time. -- 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/