sending patches to koha-patches mailing list ?
Hello everybody, The workflow we have atm is to send all patches to the koha-patches mailing-list. New ones, as well as signed-off. I think it's a good idea for new patches, that's a good source to see what has been submitted, even if we also have other sources. But for signed-off patches, I think it's useless time-consuming: - the signoff is also in the bug itself, having it in the mailing list add nothing. (we also have KohaGBSD that automatically tweets all status changes, plus "signed-off" query on bugzilla) - with git bz, we have a very fast and handy way to retrieve & send patches to the bug, so who still uses patches from the mailing list ? (note: if you don't use git bz, you should ! see http://wiki.koha-community.org/wiki/Git_bz_configuration) So I suggest to update our rule to request sending only new patches to the mailing list. Your opinion ? -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Paul Poulain <paul.poulain@biblibre.com> [...]
So I suggest to update our rule to request sending only new patches to the mailing list. Your opinion ?
Unless anyone's actually using the signed-off patches on the list, I think that's a fine update, until we get a smarter list archiver. I admit, I don't use the patches list much any more apart from posting links into bugs.k-c each month. Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha
Op vrijdag 07-10-2011 om 19:17 uur [tijdzone +0100], schreef MJ Ray:
Unless anyone's actually using the signed-off patches on the list, I think that's a fine update, until we get a smarter list archiver.
I tend to agree.
I admit, I don't use the patches list much any more apart from posting links into bugs.k-c each month.
I use it to see what's going by that's of interest, that's about it. But I'm no release manager, so maybe it's of more use to them. (also: seconding Paul's mention of git bz, it's a huge time-and-hassle-saver.) -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
Le 10/10/2011 00:48, Robin Sheat a écrit :
(also: seconding Paul's mention of git bz, it's a huge time-and-hassle-saver.)
What would be absolutly WONDERFUL would be to add a parameter to update the patch status. Something like : "git bz attach -status signed-off 4321 HEAD " Plus fixing the bug that makes attaching more than one patch at a time impossible. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
* Paul Poulain (paul.poulain@biblibre.com) wrote:
Le 10/10/2011 00:48, Robin Sheat a écrit :
(also: seconding Paul's mention of git bz, it's a huge time-and-hassle-saver.)
What would be absolutly WONDERFUL would be to add a parameter to update the patch status. Something like : "git bz attach -status signed-off 4321 HEAD " Plus fixing the bug that makes attaching more than one patch at a time impossible.
First i'd like to add a -3 switch so that the apply will use a 3way merge. At the moment if it fails you have to try that manually. Chris -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
* Paul Poulain (paul.poulain@biblibre.com) wrote:
What would be absolutly WONDERFUL would be to add a parameter to update the patch status. Something like : "git bz attach -status signed-off 4321 HEAD " Plus fixing the bug that makes attaching more than one patch at a time impossible.
The right way to do that is probably to let git bz attach take arbitrary form input names and values from the bugzilla update form, so the above example would be: git bz attach -cf_patch_status 'Signed Off' 4321 HEAD Chris Cormack <chrisc@catalyst.net.nz>
First i'd like to add a -3 switch so that the apply will use a 3way merge. At the moment if it fails you have to try that manually.
That sounds like a good but simple improvement, if only we had more time! Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/
I find that my workflow for pretty much all development and QA work centers around Bugzilla now. Even when git-bz fails to work as intended, I can still wget the patches and test them. What about looking into a means of auto-generating patches to the patches list when new "Patch" type attachments are added to Bugzilla? This would save everyone a step, and keep the incoming patches synced with the patches on bugs.koha-community.org. For course, as MJ points out, we'd need time to implement such a thing. -Ian On Mon, Oct 10, 2011 at 11:05 AM, MJ Ray <mjr@phonecoop.coop> wrote:
* Paul Poulain (paul.poulain@biblibre.com) wrote:
What would be absolutly WONDERFUL would be to add a parameter to update the patch status. Something like : "git bz attach -status signed-off 4321 HEAD " Plus fixing the bug that makes attaching more than one patch at a time impossible.
The right way to do that is probably to let git bz attach take arbitrary form input names and values from the bugzilla update form, so the above example would be: git bz attach -cf_patch_status 'Signed Off' 4321 HEAD
Chris Cormack <chrisc@catalyst.net.nz>
First i'd like to add a -3 switch so that the apply will use a 3way merge. At the moment if it fails you have to try that manually.
That sounds like a good but simple improvement, if only we had more time!
Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ _______________________________________________ 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/
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
Le 11/10/2011 15:54, Ian Walls a écrit :
I find that my workflow for pretty much all development and QA work centers around Bugzilla now. Even when git-bz fails to work as intended, I can still wget the patches and test them.
What about looking into a means of auto-generating patches to the patches list when new "Patch" type attachments are added to Bugzilla? This would save everyone a step, and keep the incoming patches synced with the patches on bugs.koha-community.org. +1
(I'm so happy with those tools that I could volunteer to do it, but I don't have the skills, sorry...) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Op dinsdag 11-10-2011 om 09:54 uur [tijdzone -0400], schreef Ian Walls:
What about looking into a means of auto-generating patches to the patches list when new "Patch" type attachments are added to Bugzilla? This would save everyone a step, and keep the incoming patches synced with the patches on bugs.koha-community.org.
Keep in mind that sending to the list is very easy, maybe people are doing it the hard way. What I do is: git bz attach HEAD git send-email --to=kpatches HEAD^ press enter and 'y' a few times, and it's done. You could probably wrap this up in a script if you wanted. (note the slightly different commit reference, and 'kpatches' is an alias I set up for the patches list.) This said, auto-sending from bugzilla would be great, I'm just hoping to make it easier until someone finds the time to do that :) -- Robin Sheat Catalyst IT Ltd. ✆ +64 4 803 2204 GPG: 5957 6D23 8B16 EFAB FEF8 7175 14D3 6485 A99C EB6D
Robin Sheat <robin@catalyst.net.nz>
Keep in mind that sending to the list is very easy, maybe people are doing it the hard way.
What I do is:
git bz attach HEAD git send-email --to=kpatches HEAD^ # [...]
That's doesn't work for me. For various reasons, I want my email sent from one of three email hosts, not from git on a development server. So I need to format-patch on the server, then copy it across and send it from elsewhere. Not as easy as git bz. I'm guessing that people who use SPF or DKIM might have similar needs, but I don't often use them.
This said, auto-sending from bugzilla would be great, I'm just hoping to make it easier until someone finds the time to do that :)
Sounds good. I don't see a problem with it. Anyone? Regards, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha
Le 10/10/2011 09:58, Chris Cormack a écrit :
* Paul Poulain (paul.poulain@biblibre.com) wrote:
Le 10/10/2011 00:48, Robin Sheat a écrit :
(also: seconding Paul's mention of git bz, it's a huge time-and-hassle-saver.)
What would be absolutly WONDERFUL would be to add a parameter to update the patch status. Something like : "git bz attach -status signed-off 4321 HEAD " Plus fixing the bug that makes attaching more than one patch at a time impossible.
First i'd like to add a -3 switch so that the apply will use a 3way merge. At the moment if it fails you have to try that manually. If someone has the Python skill: edit git-bz, at line 1497, you'll see : process = git.am(filename, _interactive=True ) Changing it to : process = git.am(filename, _interactive=True, 3=True ) should do the trick (i've tested with i=true, and you get the git am -i (interactive) as expected)
EXCEPT that python don't like the 3 (or any arg starting with a number), returning a nasty
File "/home/paul/bin/git-bz", line 1497 process = git.am(filename, _interactive=True, 3=True ) SyntaxError: keyword can't be an expression
I've tried with "3", no success:
File "/home/paul/bin/git-bz", line 1497 process = git.am(filename, _interactive=True, "3"=True ) SyntaxError: keyword can't be an expression
I've tried with _3, no success either, no python error but git says error: unknown option `-3' I've tried with 3way, "3way", _3way, with 2 starting __ (__3way...) couldn't find the correct syntax. If someone has a suggestion... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Paul Poulain <paul.poulain@biblibre.com>
Le 10/10/2011 09:58, Chris Cormack a écrit :
First i'd like to add a -3 switch so that the apply will use a 3way merge. At the moment if it fails you have to try that manually. If someone has the Python skill: edit git-bz, at line 1497, you'll see : process = git.am(filename, _interactive=True ) Changing it to : process = git.am(filename, _interactive=True, 3=True ) should do the trick (i've tested with i=true, and you get the git am -i (interactive) as expected)
Well, that will always run with -3, which isn't optional like I think Chris was suggesting. Is there a drawback with it? Or it would, except for what you found:
EXCEPT that python don't like the 3 (or any arg starting with a number), returning a nasty
File "/home/paul/bin/git-bz", line 1497 process = git.am(filename, _interactive=True, 3=True ) SyntaxError: keyword can't be an expression [...] couldn't find the correct syntax. If someone has a suggestion...
If I've understood it right, the co-op's python guru suggests it might be process = git.am(filename, kwargs=**{'_interactive': True, '3': True}) but we suspect we should hack git_run to handle leading-number args nicer. Hope that helps, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha
Le 18/10/2011 18:18, MJ Ray a écrit :
Paul Poulain <paul.poulain@biblibre.com>
process = git.am(filename, _interactive=True, 3=True ) should do the trick (i've tested with i=true, and you get the git am -i (interactive) as expected)
Well, that will always run with -3, which isn't optional like I think Chris was suggesting. Is there a drawback with it?
yes, that would. But anyway, git tries to apply the patch without 3way before testing 3way. At least that's how I understand git.
If I've understood it right, the co-op's python guru suggests it might be process = git.am(filename, kwargs=**{'_interactive': True, '3': True})
will try and let you know !
but we suspect we should hack git_run to handle leading-number args nicer.
thanks though -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Le 18/10/2011 18:18, MJ Ray a écrit :
process = git.am(filename, kwargs=**{'_interactive': True, '3': True}) Just tried this on bug 6963, that does not apply without the -3 argument, and got a nasty :
10:20 ~/koha.dev/koha-community (new/bug_6963 $%)$ git bz apply 6963 File "/home/paul/bin/git-bz", line 1497 process = git.am(filename, kwargs=**{'_interactive': True, '3': True}) ^ SyntaxError: invalid syntax (It's probably easy to fix, but not for me... ) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Le 04/11/2011 10:21, Paul Poulain a écrit :
process = git.am(filename, kwargs=**{'_interactive': True, '3': True})
Thanks robin, the correct syntax is without kwargs= Here is the patch I made (yes, git-bz uses git ;-) ) Slef, feel free to attach to your repo -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 10/10/2011 00:48, Robin Sheat a écrit :
Op vrijdag 07-10-2011 om 19:17 uur [tijdzone +0100], schreef MJ Ray:
Unless anyone's actually using the signed-off patches on the list, I think that's a fine update, until we get a smarter list archiver.
I tend to agree. As no-one has objected and 3 are explicitly for (including me), I've updated the wiki : http://wiki.koha-community.org/w/index.php?title=Sign_off_on_patches&diff=prev&oldid=6223
- -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOpnzyAAoJEK81SonuhyGovg0IAIhWIjV+VsFfzlJ/VPYxJRlX YcDSdIJcWu26NKoRAoQdNx9DK2QC6BVdahg9OuS7oXmrdsd7GzxXKQBh/h6Bm0Br /7/O5aPECabOk8MQICOBaeGhy3zBs5yuIIwf936fwZsQD3+d77Nxvfkou/Xa7zGJ kH2byd0tC8EfZmLUWXDDwSQsv6Fo8eK1w9N/BKaTIXU94zWoy4/XOatRxMYXSsA7 Ideyj8iIvfpZRzqIy3bS7FnsVpyMBASm9k4VDaLrNUse+REWg4A4ITgwv1eHrxcn pMgxHB58FaTZQnmMv3ieqWZRylQT8BOroD+5usjv5xfh/k0ukKmJZkoGxrQ8VfA= =GnYK -----END PGP SIGNATURE-----
participants (5)
-
Chris Cormack -
Ian Walls -
MJ Ray -
Paul Poulain -
Robin Sheat