Signing-off a patch for a customer
Hello koha-devel, I just pushed a follow-up for bug 6858. If you look at the patch, you'll see that the author is from BibLibre, as well as the sign-offer. But if you look more carefully on the patch comments, you may understand that Stephane Delaye has signed-off "in the name of the library". We're facing here a case where the library don't want/can't sign-off their patch (they don't know how to do it and don't want to bother with doing it. They just said this patch worked for them) At BibLibre, we have 3 project managers: Stéphane Delaye / Gaetan Boisson / François Charbonnier. They are librarians and are doing the glue between the library our customer and our developers. they know how to sign-off a patch. I want, in this mail, request that those 3 ppl from BibLibre (and only them) can be sign-offers for patches written by another BibLibre developer, once the library has confirmed it works. I propose that we define a standard message, something like Signed-off-by: Delaye Stephane <stephane.delaye@biblibre.com> patch validated by <LIBRARY NAME>, signed-off in their name Can I have your agreement with this idea ? (of course, in case another support provider has the same kind of situation, this would also be applicable. It's not something I want for BibLibre only) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Am 28.05.12 16:48, schrieb Paul Poulain:
Hello koha-devel,
I just pushed a follow-up for bug 6858. If you look at the patch, you'll see that the author is from BibLibre, as well as the sign-offer. But if you look more carefully on the patch comments, you may understand that Stephane Delaye has signed-off "in the name of the library". We're facing here a case where the library don't want/can't sign-off their patch (they don't know how to do it and don't want to bother with doing it. They just said this patch worked for them)
At BibLibre, we have 3 project managers: Stéphane Delaye / Gaetan Boisson / François Charbonnier. They are librarians and are doing the glue between the library our customer and our developers. they know how to sign-off a patch.
I want, in this mail, request that those 3 ppl from BibLibre (and only them) can be sign-offers for patches written by another BibLibre developer, once the library has confirmed it works.
I propose that we define a standard message, something like Signed-off-by: Delaye Stephane <stephane.delaye@biblibre.com> patch validated by <LIBRARY NAME>, signed-off in their name
Can I have your agreement with this idea ?
I have absolutely no problem with this. To me it sounds like "signed of by stephane delaye of biblibre, on behalf of <LIBRARY NAME>", which is a perfectly fine proxy situation.
(of course, in case another support provider has the same kind of situation, this would also be applicable. It's not something I want for BibLibre only)
- Marc
Hi Paul, On Mon, May 28, 2012 at 10:48 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
Hello koha-devel,
I just pushed a follow-up for bug 6858. If you look at the patch, you'll see that the author is from BibLibre, as well as the sign-offer. But if you look more carefully on the patch comments, you may understand that Stephane Delaye has signed-off "in the name of the library". We're facing here a case where the library don't want/can't sign-off their patch (they don't know how to do it and don't want to bother with doing it. They just said this patch worked for them)
At BibLibre, we have 3 project managers: Stéphane Delaye / Gaetan Boisson / François Charbonnier. They are librarians and are doing the glue between the library our customer and our developers. they know how to sign-off a patch.
I want, in this mail, request that those 3 ppl from BibLibre (and only them) can be sign-offers for patches written by another BibLibre developer, once the library has confirmed it works.
I propose that we define a standard message, something like Signed-off-by: Delaye Stephane <stephane.delaye@biblibre.com> patch validated by <LIBRARY NAME>, signed-off in their name
Can I have your agreement with this idea ? (of course, in case another support provider has the same kind of situation, this would also be applicable. It's not something I want for BibLibre only)
A look over the history of that bug seems to indicate that Biblibre has been responsible for: 1. Creation of the code 2. Sign-off of the code 3. QA of the code I am not comfortable with this situation. It is not particularly a "Biblibre" thing with me, but a matter of principle. And it is occurring with greater frequency. I believe we need to stick with the principles we agreed to. This patch clearly missed the "approval" of a dis-interested party in its initial commit to master. (Perhaps Katrin mentioned this at some point, but I'm not sure.) We need to take up the slack here and get a disinterested QA on this followup prior to pushing it to master. I am of the strong opinion that going forward we need to maintain a more strict compliance with this principle of dis-interested sign-off/QA. Clearly at times one or the other may be impractical, however, one *or* the other is always possible. Perhaps it may not fit the desired schedule of the vendor, but violation of this principle is the first step down a slippery slope. Kind Regards, Chris
Hi Paul and all, I agree with Chris N. here. Every exception we make, makes it harder to explain and stick to our rules. I tinkk every patch should at least have 2 parties involved. Katrin -----Ursprüngliche Nachricht----- Von: koha-devel-bounces@lists.koha-community.org im Auftrag von Chris Nighswonger Gesendet: Mo 28.05.2012 17:03 An: Paul Poulain Cc: koha-devel@lists.koha-community.org Betreff: Re: [Koha-devel] Signing-off a patch for a customer Hi Paul, On Mon, May 28, 2012 at 10:48 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
Hello koha-devel,
I just pushed a follow-up for bug 6858. If you look at the patch, you'll see that the author is from BibLibre, as well as the sign-offer. But if you look more carefully on the patch comments, you may understand that Stephane Delaye has signed-off "in the name of the library". We're facing here a case where the library don't want/can't sign-off their patch (they don't know how to do it and don't want to bother with doing it. They just said this patch worked for them)
At BibLibre, we have 3 project managers: Stéphane Delaye / Gaetan Boisson / François Charbonnier. They are librarians and are doing the glue between the library our customer and our developers. they know how to sign-off a patch.
I want, in this mail, request that those 3 ppl from BibLibre (and only them) can be sign-offers for patches written by another BibLibre developer, once the library has confirmed it works.
I propose that we define a standard message, something like Signed-off-by: Delaye Stephane <stephane.delaye@biblibre.com> patch validated by <LIBRARY NAME>, signed-off in their name
Can I have your agreement with this idea ? (of course, in case another support provider has the same kind of situation, this would also be applicable. It's not something I want for BibLibre only)
A look over the history of that bug seems to indicate that Biblibre has been responsible for: 1. Creation of the code 2. Sign-off of the code 3. QA of the code I am not comfortable with this situation. It is not particularly a "Biblibre" thing with me, but a matter of principle. And it is occurring with greater frequency. I believe we need to stick with the principles we agreed to. This patch clearly missed the "approval" of a dis-interested party in its initial commit to master. (Perhaps Katrin mentioned this at some point, but I'm not sure.) We need to take up the slack here and get a disinterested QA on this followup prior to pushing it to master. I am of the strong opinion that going forward we need to maintain a more strict compliance with this principle of dis-interested sign-off/QA. Clearly at times one or the other may be impractical, however, one *or* the other is always possible. Perhaps it may not fit the desired schedule of the vendor, but violation of this principle is the first step down a slippery slope. Kind Regards, Chris
Am 28.05.12 17:19, schrieb Fischer, Katrin:
Hi Paul and all,
I agree with Chris N. here. Every exception we make, makes it harder to explain and stick to our rules. I tinkk every patch should at least have 2 parties involved.
But, if the patch we speak about, has been tested at the library, that makes it already two involved parties, I would say. Or am I missing sth here? - Marc
Katrin
-----Ursprüngliche Nachricht----- Von: koha-devel-bounces@lists.koha-community.org im Auftrag von Chris Nighswonger Gesendet: Mo 28.05.2012 17:03 An: Paul Poulain Cc: koha-devel@lists.koha-community.org Betreff: Re: [Koha-devel] Signing-off a patch for a customer
Hi Paul,
On Mon, May 28, 2012 at 10:48 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
Hello koha-devel,
I just pushed a follow-up for bug 6858. If you look at the patch, you'll see that the author is from BibLibre, as well as the sign-offer. But if you look more carefully on the patch comments, you may understand that Stephane Delaye has signed-off "in the name of the library". We're facing here a case where the library don't want/can't sign-off their patch (they don't know how to do it and don't want to bother with doing it. They just said this patch worked for them)
At BibLibre, we have 3 project managers: Stéphane Delaye / Gaetan Boisson / François Charbonnier. They are librarians and are doing the glue between the library our customer and our developers. they know how to sign-off a patch.
I want, in this mail, request that those 3 ppl from BibLibre (and only them) can be sign-offers for patches written by another BibLibre developer, once the library has confirmed it works.
I propose that we define a standard message, something like Signed-off-by: Delaye Stephane <stephane.delaye@biblibre.com> patch validated by <LIBRARY NAME>, signed-off in their name
Can I have your agreement with this idea ? (of course, in case another support provider has the same kind of situation, this would also be applicable. It's not something I want for BibLibre only)
A look over the history of that bug seems to indicate that Biblibre has been responsible for:
1. Creation of the code 2. Sign-off of the code 3. QA of the code
I am not comfortable with this situation. It is not particularly a "Biblibre" thing with me, but a matter of principle. And it is occurring with greater frequency.
I believe we need to stick with the principles we agreed to. This patch clearly missed the "approval" of a dis-interested party in its initial commit to master. (Perhaps Katrin mentioned this at some point, but I'm not sure.) We need to take up the slack here and get a disinterested QA on this followup prior to pushing it to master.
I am of the strong opinion that going forward we need to maintain a more strict compliance with this principle of dis-interested sign-off/QA. Clearly at times one or the other may be impractical, however, one *or* the other is always possible. Perhaps it may not fit the desired schedule of the vendor, but violation of this principle is the first step down a slippery slope.
Kind Regards, Chris
_______________________________________________ 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/
Marc, But, if the patch we speak about, has been tested at the library, that
makes it already two involved parties, I would say.
Neither of the parties is disinterested. I think having the sign-off by the library is probably okay for this type of patch where there are only a certain number of parties who can test the feature, but in that case, Chris and Katrin suggested that QA should be done by someone other than party 1. For the patches where the only person who could do QA works for party 1 (not that I can imagine any situation in which case this would be true), a sign-off from someone without a financial interest in the patch should be required. Speaking as a Koha service provider, I am strongly in support of the requirement that at least one step in the approval process should be done by a disinterested party. It would certainly make developments commissioned by customers easier if I could mark the tested patch "signed off" on the basis of their testing, but I (and every other developer) rely on outside feedback for identifying the edge cases and bugs that just don't come up for our particular customers. If there isn't enough interest in a certain patch that's been "sitting around" too long, perhaps the solution is for the sponsor to place a non-monetary "bounty" on the patch. For example, "I will send half a batch of fudge to the first two people who provide useful feedback on the patch." We don't want rubber stamping. Often, I think, the reason a patch sits around too long is that no one else understands what the patch does. This is certainly the case for some of the patches that I've looked at. I can't figure out exactly what the patch does, so I don't want to *fail* it, but at the same time, I can't really sign off on it because I don't know if it's working. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Hi all, thanks Jared! That's what I meant. To bring this discussion back to Paul's initial question: I think we should encourage libraries to get involved in testing and participating in the community. The sandboxes are a tool to lower the barrier for libraries, which is great. I would like to see the library itself note the sign-off in bugzilla. It would be great if there were some notes about the testing (what, how, which configuration), but a short note would be a good start. It would be great if the credit could go to the library. We have talked about adding the 'sign offers' to the release notes as an additional encouragement for testers. I would love to see the names of lots of libraries showing up there. The other thing that would be a condition for me is "third party" (as Jared explained it) QA for those patches. Hope that makes sense, Katrin -----Ursprüngliche Nachricht----- Von: koha-devel-bounces@lists.koha-community.org im Auftrag von Jared Camins-Esakov Gesendet: Mo 28.05.2012 17:40 An: Marc Balmer Cc: koha-devel@lists.koha-community.org Betreff: Re: [Koha-devel] Signing-off a patch for a customer Marc, But, if the patch we speak about, has been tested at the library, that
makes it already two involved parties, I would say.
Neither of the parties is disinterested. I think having the sign-off by the library is probably okay for this type of patch where there are only a certain number of parties who can test the feature, but in that case, Chris and Katrin suggested that QA should be done by someone other than party 1. For the patches where the only person who could do QA works for party 1 (not that I can imagine any situation in which case this would be true), a sign-off from someone without a financial interest in the patch should be required. Speaking as a Koha service provider, I am strongly in support of the requirement that at least one step in the approval process should be done by a disinterested party. It would certainly make developments commissioned by customers easier if I could mark the tested patch "signed off" on the basis of their testing, but I (and every other developer) rely on outside feedback for identifying the edge cases and bugs that just don't come up for our particular customers. If there isn't enough interest in a certain patch that's been "sitting around" too long, perhaps the solution is for the sponsor to place a non-monetary "bounty" on the patch. For example, "I will send half a batch of fudge to the first two people who provide useful feedback on the patch." We don't want rubber stamping. Often, I think, the reason a patch sits around too long is that no one else understands what the patch does. This is certainly the case for some of the patches that I've looked at. I can't figure out exactly what the patch does, so I don't want to *fail* it, but at the same time, I can't really sign off on it because I don't know if it's working. Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Marc Balmer wrote
Am 28.05.12 17:19, schrieb Fischer, Katrin:
Hi Paul and all,
I agree with Chris N. here. Every exception we make, makes it harder to explain and stick to our rules. I tinkk every patch should at least have 2 parties involved.
But, if the patch we speak about, has been tested at the library, that makes it already two involved parties, I would say.
Or am I missing sth here?
I think the point is what Chris called a "dis-interested" party. Both BibLibre as the vendor and the library itself as the party that requested a patch have a strong interest in getting the patch pushed. There is no party involved that does not have own interest in seeing the patch pushed and will have an "unbiased" look at it. I agree that having this exemption is a problem. Not because I don't trust BibLibre in any way, but as a matter of principle. If we make exeptions for BibLibre, we have to make them for all other vendors too. Who will decide what vendors are allowed to work this way? What about new companies without a long Koha history? - Mirko
Le 28/05/2012 17:03, Chris Nighswonger a écrit :
Hi Paul,
I believe we need to stick with the principles we agreed to. This patch clearly missed the "approval" of a dis-interested party in its initial commit to master. (Perhaps Katrin mentioned this at some point, but I'm not sure.) We need to take up the slack here and get a disinterested QA on this followup prior to pushing it to master.
If you look at http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6858#c15, you'll see that MathildeF (from Nimes Public Library) tested the patch -during the hackfest-, so the initial patch has been "sign-off-ed" by her. Except she's a librarian and don't nothing about git. That's why I've setup sandboxes (and would like to improve them), but don't expect her to do more than this. (That's the same thing with the follow-up, except it's less clear on the bugzilla thread)
I am of the strong opinion that going forward we need to maintain a more strict compliance with this principle of dis-interested sign-off/QA. Clearly at times one or the other may be impractical, however, one *or* the other is always possible. I mostly agree with you here.
About the idea that i'm breaking our rule, i've reviewed all patches I've pushed since 3.8.0. Here is the list of the patches that are "BibLibre only" if you look at git: * 5a29c39c9fe838ba5af8f7c52937bb094b80d67a, trivial follow-up to the initial patch * 2338d02e9eded9dca6fdb6d425e1dc675c7c1a2d, patch signed-off by Nicole, does not appear because the patch had to be rebased (also tested by MathildeF with sandboxes) * b35d34e2ae4713c1f2f524ac565e2623e9f5243a, trivial follow-up to the initial patch * 18f21b32c6bfb4caefa00d8aaf650a67d1531d1c, trivial follow-up to the initial patch (I don't want to count bug 6858 in this list, because, for me, it has been tested by a dis-interested -well, in fact, calling the library "dis-interested" is maybe not the best term, but nevermind ;-) ) My conclusion is that I don't break the rule. When I do QA, I go from oldest to newest. If I see a patch that is from BibLibre only (which is already an uncommon case), I do my QA comments, but don't change the QA status, saying "I'll let someone else from the QA team change the status". I don't want to break the rule. I just request that 3 identified ppl from BibLibre can sign-off in the name of the customer (I like the Proxy term).
Perhaps it may not fit the desired schedule of the vendor, but violation of this principle is the first step down a slippery slope.
It's not only a "vendor schedule". It's also for users: if the author says it works, the library also say it works, fact that is expressed through "the proxy" of BibLibre project manager, I don't understand where's the problem ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Paul, et. al., Sorry about the second e-mail ten seconds after the first. (I don't want to count bug 6858 in this list, because, for me, it has
been tested by a dis-interested -well, in fact, calling the library "dis-interested" is maybe not the best term, but nevermind ;-) )
I don't see how the library that commissioned the development could be disinterested. I don't want to break the rule. I just request that 3 identified ppl
from BibLibre can sign-off in the name of the customer (I like the Proxy term).
In case this wasn't clear, I have absolutely no objection to this, provided the customer sticks a note on the bug so the history is clear. Actually, if I have time, I'd like to extend your sandbox code to allow libraries to sign off directly from the sandbox. I'd also like to add features to allow the sandbox system to handle testing indexing. Better to have your project managers test other patches than spend time inserting "Signed-off-by" lines for libraries that are using the sandbox but don't understand git. :) Regards, Jared -- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Paul, et. al.,
Sorry about the second e-mail ten seconds after the first.
(I don't want to count bug 6858 in this list, because, for me, it has been tested by a dis-interested -well, in fact, calling the library "dis-interested" is maybe not the best term, but nevermind ;-) )
I don't see how the library that commissioned the development could be disinterested. me too, but the term "dis-interested" was used by chris_n, so I used it too. But I agree everybody involved in a patch has an interest to see it
Le 28/05/2012 17:46, Jared Camins-Esakov a écrit : pushed ;-)
I don't want to break the rule. I just request that 3 identified ppl from BibLibre can sign-off in the name of the customer (I like the Proxy term). In case this wasn't clear, I have absolutely no objection to this, provided the customer sticks a note on the bug so the history is clear.
I think you missed something: don't expect a *french* librarian to create an account on bugzilla that is in this strange language called *english* ! Some of them will do, but that's only a small part. [ Just for information: at the beginning, we asked our first customers to use bugzilla to declare bugs. 4 bugs in 2 years (rough numbers). Then we opened mantis, internal to BibLibre. We've almost reached mantis number 10000 !!! -we also use it internally, for our projects, not only for Koha support- ]
Actually, if I have time, I'd like to extend your sandbox code to allow libraries to sign off directly from the sandbox. +1. That's also in my roadmap (but not on the top of my pile) I also want to submit again the new updatedatabase system. What is really bad with the current one is that patches with updatedatabase are almost always broken, they are almost impossible to test with sandboxes.
Note that Stéphane send a mail to all french libraries that came to Marseille hackfest to point some (5-10) bugs that could be signed-off. Without too much success in the feedback, but we will continue !
I'd also like to add features to allow the sandbox system to handle testing indexing. what do you mean by testing indexing ?
Better to have your project managers test other patches than spend time inserting "Signed-off-by" lines for libraries that are using the sandbox but don't understand git. :) +1 (and, also, we won't add the librarian as "signed-off-by", because they could recieve mail -from jenkins for example- that will well... look strange to them)
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Mon, May 28, 2012 at 12:08 PM, Paul Poulain <paul.poulain@biblibre.com>wrote:
Paul, et. al.,
Sorry about the second e-mail ten seconds after the first.
(I don't want to count bug 6858 in this list, because, for me, it has been tested by a dis-interested -well, in fact, calling the library "dis-interested" is maybe not the best term, but nevermind ;-) )
I don't see how the library that commissioned the development could be disinterested. me too, but the term "dis-interested" was used by chris_n, so I used it too. But I agree everybody involved in a patch has an interest to see it
Le 28/05/2012 17:46, Jared Camins-Esakov a écrit : pushed ;-)
By "disinterested" I specifically mean one who has no pecunary (cash) interest in seeing the patch pushed. This exlcue both ends of the transaction: the party paying and the party being paid. All others would be truly disinterested parties.
I don't want to break the rule. I just request that 3 identified ppl from BibLibre can sign-off in the name of the customer (I like the
Proxy
term). In case this wasn't clear, I have absolutely no objection to this, provided the customer sticks a note on the bug so the history is clear.
I think you missed something: don't expect a *french* librarian to create an account on bugzilla that is in this strange language called *english* ! Some of them will do, but that's only a small part.
Have them use *french* then... or whatever language they are comfortable in. There are enough resources to handle translation around here I think. Does BZ have a multi-lingual interface? Kind Regards, Chris
Le 28/05/2012 18:14, Chris Nighswonger a écrit :
Have them use *french* then... or whatever language they are comfortable in. There are enough resources to handle translation around here I think. Does BZ have a multi-lingual interface?
Yes it does. although the quality was quite average last time I've checked (many years ago). That would be a good + to have bugzilla in french, for sure ! -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On May 29, 2012 4:30 AM, "Paul Poulain" <paul.poulain@biblibre.com> wrote:
Le 28/05/2012 18:14, Chris Nighswonger a écrit :
Have them use *french* then... or whatever language they are comfortable in. There are enough resources to handle translation around here I
think.
Does BZ have a multi-lingual interface?
Yes it does. although the quality was quite average last time I've checked (many years ago). That would be a good + to have bugzilla in french, for sure !
Lucky bugzilla is also free software, we can fix translation issues. Be nice to give back to a project we use daily. And to add my 2cents, I also support at least one disinterested party preferably 2 in the signoff/qa. I also heavily support making it easier for French speakers to sign off. Im happy if they comment in French too, I know enough French speakers to have it translated when I push to 3.8.x. Maybe a task for hackfest. Chris
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 _______________________________________________ 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/
On 29 May 2012 07:58, Chris Cormack <chris@bigballofwax.co.nz> wrote:
On May 29, 2012 4:30 AM, "Paul Poulain" <paul.poulain@biblibre.com> wrote:
Le 28/05/2012 18:14, Chris Nighswonger a écrit :
Have them use *french* then... or whatever language they are comfortable in. There are enough resources to handle translation around here I think. Does BZ have a multi-lingual interface?
Yes it does. although the quality was quite average last time I've checked (many years ago). That would be a good + to have bugzilla in french, for sure !
Lucky bugzilla is also free software, we can fix translation issues. Be nice to give back to a project we use daily.
And to add my 2cents, I also support at least one disinterested party preferably 2 in the signoff/qa. I also heavily support making it easier for French speakers to sign off. Im happy if they comment in French too, I know enough French speakers to have it translated when I push to 3.8.x.
Maybe a task for hackfest.
Well it was was easier than I thought. http://bugs.koha-community.org/bugzilla3/ Top right should have a language chooser, only in 3 languages now, EN, DE, and FR .. but if people want I can install any of the ones here http://www.bugzilla.org/download/#localizations (that are for 4.2/4.2.1) Just let me know Chris
Just to add in my opinion here. As someone who has been in Paul's situation, where a library (that has paid us to write them code) has been testing (and sometimes using the code in production) and has confirmed that things work I agree that putting a sign off in their name should be an okay practice. I also agree though that someone not from my company should QA the patch - that extra set of outside eyes is essential. What I don't think should happen (and I don't think anyone is suggesting this) is that a patch that is written by our company and signed off by our partner should have to wait for another sign off before hitting the QA queue. Thanks (and see many of you soon!), Nicole C. Engard
Le 29/05/2012 09:50, Nicole Engard a écrit :
Just to add in my opinion here.
As someone who has been in Paul's situation, where a library (that has paid us to write them code) has been testing (and sometimes using the code in production) and has confirmed that things work I agree that putting a sign off in their name should be an okay practice. I also agree though that someone not from my company should QA the patch - that extra set of outside eyes is essential. Thanks Nicole, I'm "happy" to see BibLibre is not the only one facing this kind of problem.
What I don't think should happen (and I don't think anyone is suggesting this) is that a patch that is written by our company and signed off by our partner should have to wait for another sign off before hitting the QA queue. Agreed.
Side comment: in some cases, as RM, I switch back a QAed patch to "need sign-off" for some patches that are large and/or require a very careful testing. That's quite uncommon, and not related to who made/signed-off the patch. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Tue, May 29, 2012 at 10:00:12AM +0200, Paul Poulain wrote:
Le 29/05/2012 09:50, Nicole Engard a écrit :
Just to add in my opinion here.
As someone who has been in Paul's situation, where a library (that has paid us to write them code) has been testing (and sometimes using the code in production) and has confirmed that things work I agree that putting a sign off in their name should be an okay practice. I also agree though that someone not from my company should QA the patch - that extra set of outside eyes is essential. Thanks Nicole, I'm "happy" to see BibLibre is not the only one facing this kind of problem.
I would just like to add that we are in same situation with EAN-13 barcode support[1]. They have running it in production, signing off patches is somewhat of high bar for them. 1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6448 -- Dobrica Pavlinusic 2share!2flame dpavlin@rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin
On 29 May 2012 21:24, Dobrica Pavlinusic <dpavlin@rot13.org> wrote:
On Tue, May 29, 2012 at 10:00:12AM +0200, Paul Poulain wrote:
Le 29/05/2012 09:50, Nicole Engard a écrit :
Just to add in my opinion here.
As someone who has been in Paul's situation, where a library (that has paid us to write them code) has been testing (and sometimes using the code in production) and has confirmed that things work I agree that putting a sign off in their name should be an okay practice. I also agree though that someone not from my company should QA the patch - that extra set of outside eyes is essential. Thanks Nicole, I'm "happy" to see BibLibre is not the only one facing this kind of problem.
I would just like to add that we are in same situation with EAN-13 barcode support[1]. They have running it in production, signing off patches is somewhat of high bar for them.
1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6448
Is logging into bugzilla and commenting on the bug too much of a high bar also? Or, how about using gerrit, to sign off, eg http://gerrit.workbuffer.org:8080/#/c/7/ If they were logged in, they could mark that verified. Or use the Biblibre sandboxes to do something similar? I think making it easier for people to do the first sign off is a good thing, of course I'd still like to see ideally 2 other disinterested parties checking it before it was pushed too. Chris
I am also of the mind the sign-off should be allowed by another employee of the same organization as the developer, provided they signer has no history of signing off on patches without testing. I do strongly also believe that QA must then be done by a disinterested party. Kyle On Tue, May 29, 2012 at 5:24 AM, Dobrica Pavlinusic <dpavlin@rot13.org> wrote:
On Tue, May 29, 2012 at 10:00:12AM +0200, Paul Poulain wrote:
Le 29/05/2012 09:50, Nicole Engard a écrit :
Just to add in my opinion here.
As someone who has been in Paul's situation, where a library (that has paid us to write them code) has been testing (and sometimes using the code in production) and has confirmed that things work I agree that putting a sign off in their name should be an okay practice. I also agree though that someone not from my company should QA the patch - that extra set of outside eyes is essential. Thanks Nicole, I'm "happy" to see BibLibre is not the only one facing this kind of problem.
I would just like to add that we are in same situation with EAN-13 barcode support[1]. They have running it in production, signing off patches is somewhat of high bar for them.
1: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6448
-- Dobrica Pavlinusic 2share!2flame dpavlin@rot13.org Unix addict. Internet consultant. http://www.rot13.org/~dpavlin _______________________________________________ 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/
I agree with most responses in this thread: If a company makes a patch, a customer of that company signs off, it should not be QAed by that company, but by a "neutral" party. The QAer should even be allowed to ask for a second outside signoff if he feels the patch needs that additional proof. As Paul mentioned earlier (he does QA but does not set the status): In order to prevent the appearance of pushing the process, you could even ask if it would be wiser to refrain from such QA comments. (Or just mail them to the author.) Marcel ________________________________________ Van: koha-devel-bounces@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] namens Kyle Hall [kyle.m.hall@gmail.com] Verzonden: dinsdag 29 mei 2012 12:30 To: Dobrica Pavlinusic Cc: koha-devel@lists.koha-community.org Onderwerp: Re: [Koha-devel] Signing-off a patch for a customer I am also of the mind the sign-off should be allowed by another employee of the same organization as the developer, provided they signer has no history of signing off on patches without testing. I do strongly also believe that QA must then be done by a disinterested party. Kyle
Le 29/05/2012 13:50, Marcel de Rooy a écrit :
I agree with most responses in this thread: If a company makes a patch, a customer of that company signs off, it should not be QAed by that company, but by a "neutral" party. The QAer should even be allowed to ask for a second outside signoff if he feels the patch needs that additional proof.
What's the QA done for ? it's looking at the quality of the code. So, a QAer can request a 2nd signoff, but only if he feel that the code is missing a case (like "I feel this code will work for UNIMARC, could someone check for MARC21" ? or "work for sysprefX = OFF, must be checked for sysprefX = ON as well". I feel that should be an uncommon case. The RM has a more global responsibility to ensure the global consistency of the soft.
As Paul mentioned earlier (he does QA but does not set the status): In order to prevent the appearance of pushing the process, you could even ask if it would be wiser to refrain from such QA comments. (Or just mail them to the author.) I'm not sure I understand ? Do you mean I should not QA if I can't set the status ? Sound a very bad idea : if I see something wrong, like an unconditionnal warn, a missing use Modern::Perl, it must be said publicly, to avoid having another QAer requesting this problem to be fixed
Reminder (or information in case you don't know) = I usually QA & push patches ordered by last modification date, ASC (So the oldest 1st). If I see something wrong while I'm reviewing, I don't understand why I should stay silent ! HTH -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
To me, the role of QA is to be highly conservative. The QA team needs to look at a piece of incoming code, and not only judge it on how well it does it's intended purpose, but how it affects all the other code and workflows that surround it. The folks creating and signing off on code are often looking to answer the question "does it work?". I approach the QA process asking the question "what does it break?". Often times, the answer is "nothing", and we get a great new feature in our codebase. But sometimes the patch changes a core function or variable declaration in a way that isn't spotted, and only applicable on certain use cases. Or a new dependency is added that conflicts with something existing. Or a security hole is introduced under some conditions. A person asking "does this work?" isn't necessarily going to spot these things in their testing; our code is very complex. I'm sure we can all recall cases where piece of code was committed to do one thing, and then required a followup because it broke something else under specific circumstances. I strongly believe that having a 'neutral party' to do the QA work is essential to keeping our codebase strong and healthy. We need the fresh set of eyes, the different perspective, the alternate use case. We need someone asking "what does it break?", and I don't think the folks who've been asking the question "does it work?" are the best suited to that task. That said, if ANYONE sees a problem with a patch, I would encourage them to note it on the bug report. If s/he is confident this is a serious problem, or a violation of well-documented coding practices, then please feel free to set "Failed QA". That status is open to everyone to set, because, as stated earlier, QA is a highly conservative process, and I'd prefer a patch have to wait a little longer to be re-evaluated than to have a new bug introduced that could have been prevented with a word. That's my perspective on the matter. I'd also very much like to see it made easier for libraries to provide their sign-off on code, as they're often some of the best to evaluate "does it work?". -Ian On Tue, May 29, 2012 at 8:05 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
Le 29/05/2012 13:50, Marcel de Rooy a écrit :
I agree with most responses in this thread: If a company makes a patch, a customer of that company signs off, it should not be QAed by that company, but by a "neutral" party. The QAer should even be allowed to ask for a second outside signoff if he feels the patch needs that additional proof.
What's the QA done for ? it's looking at the quality of the code. So, a QAer can request a 2nd signoff, but only if he feel that the code is missing a case (like "I feel this code will work for UNIMARC, could someone check for MARC21" ? or "work for sysprefX = OFF, must be checked for sysprefX = ON as well". I feel that should be an uncommon case. The RM has a more global responsibility to ensure the global consistency of the soft.
As Paul mentioned earlier (he does QA but does not set the status): In order to prevent the appearance of pushing the process, you could even ask if it would be wiser to refrain from such QA comments. (Or just mail them to the author.) I'm not sure I understand ? Do you mean I should not QA if I can't set the status ? Sound a very bad idea : if I see something wrong, like an unconditionnal warn, a missing use Modern::Perl, it must be said publicly, to avoid having another QAer requesting this problem to be fixed
Reminder (or information in case you don't know) = I usually QA & push patches ordered by last modification date, ASC (So the oldest 1st). If I see something wrong while I'm reviewing, I don't understand why I should stay silent !
HTH -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 _______________________________________________ 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/
On Tue, May 29, 2012 at 11:12 AM, Ian Walls <koha.sekjal@gmail.com> wrote:
To me, the role of QA is to be highly conservative. The QA team needs to look at a piece of incoming code, and not only judge it on how well it does it's intended purpose, but how it affects all the other code and workflows that surround it. The folks creating and signing off on code are often looking to answer the question "does it work?". I approach the QA process asking the question "what does it break?".
Often times, the answer is "nothing", and we get a great new feature in our codebase. But sometimes the patch changes a core function or variable declaration in a way that isn't spotted, and only applicable on certain use cases. Or a new dependency is added that conflicts with something existing. Or a security hole is introduced under some conditions. A person asking "does this work?" isn't necessarily going to spot these things in their testing; our code is very complex. I'm sure we can all recall cases where piece of code was committed to do one thing, and then required a followup because it broke something else under specific circumstances.
I strongly believe that having a 'neutral party' to do the QA work is essential to keeping our codebase strong and healthy. We need the fresh set of eyes, the different perspective, the alternate use case. We need someone asking "what does it break?", and I don't think the folks who've been asking the question "does it work?" are the best suited to that task.
+1 Kind Regards, Chris
On 30 May 2012 12:30, Chris Nighswonger <cnighswonger@foundations.edu> wrote:
On Tue, May 29, 2012 at 11:12 AM, Ian Walls <koha.sekjal@gmail.com> wrote:
To me, the role of QA is to be highly conservative. The QA team needs to look at a piece of incoming code, and not only judge it on how well it does it's intended purpose, but how it affects all the other code and workflows that surround it. The folks creating and signing off on code are often looking to answer the question "does it work?". I approach the QA process asking the question "what does it break?".
Often times, the answer is "nothing", and we get a great new feature in our codebase. But sometimes the patch changes a core function or variable declaration in a way that isn't spotted, and only applicable on certain use cases. Or a new dependency is added that conflicts with something existing. Or a security hole is introduced under some conditions. A person asking "does this work?" isn't necessarily going to spot these things in their testing; our code is very complex. I'm sure we can all recall cases where piece of code was committed to do one thing, and then required a followup because it broke something else under specific circumstances.
I strongly believe that having a 'neutral party' to do the QA work is essential to keeping our codebase strong and healthy. We need the fresh set of eyes, the different perspective, the alternate use case. We need someone asking "what does it break?", and I don't think the folks who've been asking the question "does it work?" are the best suited to that task.
+1
+1 from me also Chris
On 30 May 2012 02:38, Chris Cormack <chris@bigballofwax.co.nz> wrote:
On 30 May 2012 12:30, Chris Nighswonger <cnighswonger@foundations.edu> wrote:
On Tue, May 29, 2012 at 11:12 AM, Ian Walls <koha.sekjal@gmail.com> wrote:
To me, the role of QA is to be highly conservative. The QA team needs to look at a piece of incoming code, and not only judge it on how well it does it's intended purpose, but how it affects all the other code and workflows that surround it. The folks creating and signing off on code are often looking to answer the question "does it work?". I approach the QA process asking the question "what does it break?".
Often times, the answer is "nothing", and we get a great new feature in our codebase. But sometimes the patch changes a core function or variable declaration in a way that isn't spotted, and only applicable on certain use cases. Or a new dependency is added that conflicts with something existing. Or a security hole is introduced under some conditions. A person asking "does this work?" isn't necessarily going to spot these things in their testing; our code is very complex. I'm sure we can all recall cases where piece of code was committed to do one thing, and then required a followup because it broke something else under specific circumstances.
I strongly believe that having a 'neutral party' to do the QA work is essential to keeping our codebase strong and healthy. We need the fresh set of eyes, the different perspective, the alternate use case. We need someone asking "what does it break?", and I don't think the folks who've been asking the question "does it work?" are the best suited to that task.
+1
+1 from me also
+1 Magnus Enger libriotech.no
Le 29/05/2012 17:12, Ian Walls a écrit :
I strongly believe that having a 'neutral party' to do the QA work is essential to keeping our codebase strong and healthy. We need the fresh set of eyes, the different perspective, the alternate use case. We need someone asking "what does it break?", and I don't think the folks who've been asking the question "does it work?" are the best suited to that task. Reviving this thread...
I think this thread became 2: - signing-of a patch in the name of a customer => this proposition seems to be globally accepted (yes = marc_b, nicole, dobrica, kyle, Marcel. jared also said yes I think (From - Mon May 28 17:50:13 2012) no = I can't find anyone saying 'no': chris_n and katrin expressed some concerns, but they were related to having a company writing & signing-off a patch, which is not what I requested). Is there anyone wanting to say a "no", and argue why ? - QAing a patch => I think this topic need more discussion= who could/should QA a patch, how should it be done ? I think it's not a matter of 'neutral party', but more a matter of 'experienced and trust-able party'. Seeing if it can break something requires a lot of experience with Koha code source. When I QA code from BibLibre, I'm not biaised because it comes from BibLibre. Because if it introduces silently something that could break another thing even if it works under certain circumstances, passing QA would be a short-term vision. My goal (and all QA team goal) is to manage Koha improvement(s) on the long term. Should we, then, give a grant to some specific, experienced & trustable ppl to QA ? this has my preference, I throw it now. That it's how some Open-Source communities are working. For example, the eclipse foundation has "contributors" and "committers". I see committers as a rough equivalent or our QA team (http://www.eclipse.org/projects/dev_process/development_process_2011.php#4_7...) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Hi Paul, all
Seeing if it can break something requires a lot of experience with Koha code source. When I QA code from BibLibre, I'm not biaised because it comes from BibLibre. Are you sure? Just looking at your statement from outside BibLibre, I would say that there could be conflicting interests here.. (With all due respect !)
Should we, then, give a grant to some specific, experienced & trustable ppl to QA ? Isn't that already the case? Or do you feel that we should extend the QA team? If we dissolve it on the other hand and grant a new QA privilege to say 15 developers, it may just be a little too optional/non-committal. Would that really be more productive?
For example, the eclipse foundation has "contributors" and "committers". From first glance, I suspect that we compare two non-similar workflows.
Marcel
On Jul 5, 2012 12:25 AM, "Marcel de Rooy" <M.de.Rooy@rijksmuseum.nl> wrote:
Hi Paul, all
Seeing if it can break something requires a lot of experience with Koha
code source. When I QA code from BibLibre, I'm not biaised because it comes from BibLibre.
Are you sure? Just looking at your statement from outside BibLibre, I would say that there could be conflicting interests here.. (With all due respect !)
Should we, then, give a grant to some specific, experienced & trustable
Neutral is always to be preferred imho. ppl to QA ?
Isn't that already the case? Or do you feel that we should extend the QA team? If we dissolve it on the other hand and grant a new QA privilege to say 15 developers, it may just be a little too optional/non-committal. Would that really be more productive?
I thought it was already the case too, and that's what we had nominations and elections for. I'd hate to replace that system with a cartel like appointed system. Chris
For example, the eclipse foundation has "contributors" and "committers". From first glance, I suspect that we compare two non-similar workflows.
Marcel _______________________________________________ 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/
Points: 1. Yes, I believe it's okay for someone to do the action of sign off for someone who is not technically inclined or does not have access to Git, provided the person doing the signoff has verifiable permission from the person who's name it is they are using. It would primarily be on the person who's name is being used to raise an alarm if their rights are being infringed, but if anyone in the community feels this is the case, they are welcome to question the proxy-signoffer (hopefully in a tactful, respectful manner). 2. Checking code to see if it breaks anything requires a keen eye and plenty of experience with Koha, as the codebase is very complex, having grown organically over time. The longer you've been involved with the code, the better the chance you have encountered some of the various idiosyncrasies before. There are a number of folks who fit this bill, and we're very luck to having them writing, testing and signing off. I think, however, we need to keep the QA team as elected. The election of folks to QAM and QAA is the community's way of showing faith and trust in those people. Appointing people, or opening the position to take all comers, will erode some of the distinct value that QA provides, reducing it in many ways to a second signoff. I believe (and I think the statistics would back me up, if they could be generated) that having had QA for the two previous releases, and this current one, has reduced the number of regressions and bugs slipping in from release to release. I would be very interested in seeing hard numbers on that, though. Cheers, -Ian On Wed, Jul 4, 2012 at 8:32 AM, Chris Cormack <chris@bigballofwax.co.nz>wrote:
On Jul 5, 2012 12:25 AM, "Marcel de Rooy" <M.de.Rooy@rijksmuseum.nl> wrote:
Hi Paul, all
Seeing if it can break something requires a lot of experience with
Koha code source. When I QA code from BibLibre, I'm not biaised because it comes from BibLibre.
Are you sure? Just looking at your statement from outside BibLibre, I would say that there could be conflicting interests here.. (With all due respect !)
Neutral is always to be preferred imho.
Should we, then, give a grant to some specific, experienced & trustable ppl to QA ? Isn't that already the case? Or do you feel that we should extend the QA team? If we dissolve it on the other hand and grant a new QA privilege to say 15 developers, it may just be a little too optional/non-committal. Would that really be more productive?
I thought it was already the case too, and that's what we had nominations and elections for. I'd hate to replace that system with a cartel like appointed system.
Chris
For example, the eclipse foundation has "contributors" and "committers". From first glance, I suspect that we compare two non-similar workflows.
Marcel _______________________________________________ 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/
_______________________________________________ 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/
Le 04/07/2012 14:25, Marcel de Rooy a écrit :
Hi Paul, all
Seeing if it can break something requires a lot of experience with Koha code source. When I QA code from BibLibre, I'm not biaised because it comes from BibLibre. Are you sure? Just looking at your statement from outside BibLibre, I would say that there could be conflicting interests here.. (With all due respect !) mmm... maybe I'm using a wrong word here. What I wanted to say is I QA BibLibre patch exactly the same way as a non-BibLibre patch : if I think it should not be pushed, I won't push it, BibLibre or not BibLibre. The question "does it break something" is related to my long-standing experience on Koha, that let me find/know caveats. Not that I'm always right, I made mistakes, but I think there's no difference between BibLibre and non BibLibre patches.
Should we, then, give a grant to some specific, experienced & trustable ppl to QA ? Isn't that already the case? Or do you feel that we should extend the QA team? Well, my feeling is that we could officially add Katrin to the QA team, because she make a lot of very good QA comments. But that's another topic ;-)
What I wanted to say here is that the community could recognize the fact that I'm trustable/wise/experienced enough to QA any patch. I wouldn't object if chris_c had the same possibility for catalyst patches -and wanted to join QA team-. (Maybe the problem here is that, atm, I'm the only one who is in a position where this specific permission is applicable/useful/needed)
For example, the eclipse foundation has "contributors" and "committers". From first glance, I suspect that we compare two non-similar workflows. agreed. It was not to use the same workflow, just an example. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Hi all, I would like to add some thoughts to the discussion. For me 'neutral' or 'different company' has another dimension. As we all have learned (sometimes painfully) - libraries don't work the same everywhere. We have different workflows and sometimes different ideas about how things are supposed to work. And for me that's another reason why I think a different set of eyes on each patch or feature is good and really needed. It helps us to not concentrate on the view of one library or a group of libraries, but see the bigger picture. So my request for having someone else looking at patches from outside the scope of sponsoring library and developing company is not about trust - it's about getting another perspective. Katrin
-----Original Message----- From: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel- bounces@lists.koha-community.org] On Behalf Of Paul Poulain Sent: Wednesday, July 04, 2012 3:50 PM To: koha-devel@lists.koha-community.org Subject: Re: [Koha-devel] QAing patches
Le 04/07/2012 14:25, Marcel de Rooy a écrit :
Hi Paul, all
Seeing if it can break something requires a lot of experience with Koha code source. When I QA code from BibLibre, I'm not biaised because it comes from BibLibre. Are you sure? Just looking at your statement from outside BibLibre, I would say that there could be conflicting interests here.. (With all due respect !) mmm... maybe I'm using a wrong word here. What I wanted to say is I QA BibLibre patch exactly the same way as a non-BibLibre patch : if I think it should not be pushed, I won't push it, BibLibre or not BibLibre. The question "does it break something" is related to my long-standing experience on Koha, that let me find/know caveats. Not that I'm always right, I made mistakes, but I think there's no difference between BibLibre and non BibLibre patches.
Should we, then, give a grant to some specific, experienced & trustable ppl to QA ? Isn't that already the case? Or do you feel that we should extend the QA team? Well, my feeling is that we could officially add Katrin to the QA team, because she make a lot of very good QA comments. But that's another topic ;-)
What I wanted to say here is that the community could recognize the fact that I'm trustable/wise/experienced enough to QA any patch. I wouldn't object if chris_c had the same possibility for catalyst patches -and wanted to join QA team-. (Maybe the problem here is that, atm, I'm the only one who is in a position where this specific permission is applicable/useful/needed)
For example, the eclipse foundation has "contributors" and "committers". From first glance, I suspect that we compare two non-similar workflows. agreed. It was not to use the same workflow, just an example. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
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/
On Mon, May 28, 2012 at 11:46 AM, Jared Camins-Esakov < jcamins@cpbibliography.com> wrote:
I don't want to break the rule. I just request that 3 identified ppl
from BibLibre can sign-off in the name of the customer (I like the Proxy term).
In case this wasn't clear, I have absolutely no objection to this, provided the customer sticks a note on the bug so the history is clear. Actually, if I have time, I'd like to extend your sandbox code to allow libraries to sign off directly from the sandbox. I'd also like to add features to allow the sandbox system to handle testing indexing. Better to have your project managers test other patches than spend time inserting "Signed-off-by" lines for libraries that are using the sandbox but don't understand git. :)
+1,000 Having things scripted so that anyone on a sandbox can sign-off both in BZ and git would be spectacular. Perhaps authentication could be coordinated between BZ and the sandbox to ensure some level of integrity. Kind Regards, Chris
On Mon, May 28, 2012 at 11:46 AM, Jared Camins-Esakov <jcamins@cpbibliography.com <mailto:jcamins@cpbibliography.com>> wrote: Having things scripted so that anyone on a sandbox can sign-off both in BZ and git would be spectacular. Perhaps authentication could be coordinated between BZ and the sandbox to ensure some level of integrity.
Le 28/05/2012 18:16, Chris Nighswonger a écrit : there is already an authentication, but it's a "static" one. on biblibre sandboxes, it's my login that is used. That's different from the author of the signoff, that an easy git config ... can change on the fly. What would be pretty easy to do would be: * have a signoff.pl page (like sandbox.pl) * the user enter his mail, name, bug number * the script does "git config $name / $mail" + git bz attach $bugnumber * the user goes to bugzilla, obsolete manually the bug and change the status to "signed-off" (we even could easily redirect to the bugzilla page). The requirement would be to have the user having a bugzilla account. That would also mean the signed-off patch would look as if uploaded by me (for BibLibre sandboxes), but that's not a problem. We even could create a "fake sandbox" account if we want. HTH -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
participants (13)
-
Chris Cormack -
Chris Nighswonger -
Dobrica Pavlinusic -
Fischer, Katrin -
Ian Walls -
Jared Camins-Esakov -
Kyle Hall -
Magnus Enger -
Marc Balmer -
Marcel de Rooy -
Mirko -
Nicole Engard -
Paul Poulain