Koha 3.8 release schedule & perltidy process
Hello koha-devel, I just updated the 3.8 release process with the schedule/planning of the release: http://wiki.koha-community.org/wiki/Roadmap_to_3.8 Here it is: March, 23th (1 month before the release) = feature freeze. April, 6th = strong feature freeze, string freeze April 20th = starting release process, everything frozen April 23th = release of Koha 3.8.0 IMPORTANT = perltidy process In january IRC meeting we spoke of perltidy thing. We have a coding guideline rule that says code must be perltidied. However, all the existing code is not perltidied, and it's hard to mix perltidied and non perltidied code. Thus, we have investigated the idea of doing a "perltidy big-bang" just when releasing 3.8.0, for all the code. Pro: * the code will be perltidied, the coding guideline will be applicable * all perltidy being made at the same time, it will be easier to read the git log. (One of the argument against perltidying is that it's a problem for reading git history) * doing that for a release is better for future bugfixes means that patches will apply on 3.8 as well as on master. Cons: * patches that are waiting may become "does not apply" because of the perltidy thing * patches submitted to fix bugs in 3.8 may not apply on 3.6 easily, that will add more work for 3.6 releases. All in one, our conclusion was that the best solution is to do that during a release process. So I plan do it during 3.8 release. (I have a (small ?) question about that : do you think I should make only one huge commit with perltidy ? one for each directory ? one for each file ?) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Hi Paul, What is the exact procedure? All patches submitted before March 23 or signed-off before March 23 are candidates for the 3.8 release? If so, how do we separate them easily from the patches submitted later? What is strong feature freeze exactly here? About the commits: I would suggest to put multiple files in a perltidy commit, not per file. Marcel -----Oorspronkelijk bericht----- Van: koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] Namens Paul Poulain Verzonden: donderdag 8 maart 2012 13:59 Aan: koha-devel@lists.koha-community.org Onderwerp: [Koha-devel] Koha 3.8 release schedule & perltidy process Hello koha-devel, I just updated the 3.8 release process with the schedule/planning of the release: http://wiki.koha-community.org/wiki/Roadmap_to_3.8 Here it is: March, 23th (1 month before the release) = feature freeze. April, 6th = strong feature freeze, string freeze April 20th = starting release process, everything frozen April 23th = release of Koha 3.8.0 IMPORTANT = perltidy process In january IRC meeting we spoke of perltidy thing. We have a coding guideline rule that says code must be perltidied. However, all the existing code is not perltidied, and it's hard to mix perltidied and non perltidied code. Thus, we have investigated the idea of doing a "perltidy big-bang" just when releasing 3.8.0, for all the code. Pro: * the code will be perltidied, the coding guideline will be applicable * all perltidy being made at the same time, it will be easier to read the git log. (One of the argument against perltidying is that it's a problem for reading git history) * doing that for a release is better for future bugfixes means that patches will apply on 3.8 as well as on master. Cons: * patches that are waiting may become "does not apply" because of the perltidy thing * patches submitted to fix bugs in 3.8 may not apply on 3.6 easily, that will add more work for 3.6 releases. All in one, our conclusion was that the best solution is to do that during a release process. So I plan do it during 3.8 release. (I have a (small ?) question about that : do you think I should make only one huge commit with perltidy ? one for each directory ? one for each file ?) -- 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/
Le 08/03/2012 14:36, Marcel de Rooy a écrit :
Hi Paul, Hi Marcel,
What is the exact procedure? All patches submitted before March 23 or signed-off before March 23 are candidates for the 3.8 release? If so, how do we separate them easily from the patches submitted later? What is strong feature freeze exactly here? By "included" I mean "pushed to master". I don't mean "submitted" or "signed-off". A major feature that is submitted on march 22nd, signed-off on march 24 won't be in 3.8, it will be delayed to the next release.
[well, if something really cool is QAed on march 24 I may decide to delay the feature freeze by a day. I'll check bugzilla in the days before the string freeze and encourage ppl to sign-off/QA. Fortunatly, the european hackfest take place this week, so we will have many ppl available to test anything cool ;-) ] After the 1st "feature freeze" I will still accept small enhancements. that's why we can call it "soft FF". After the "strong feature freeze" NO enhancements at all will be added, to let translator and testers enough time to do their work. -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Mar 9, 2012 1:59 AM, "Paul Poulain" <paul.poulain@biblibre.com> wrote:
Hello koha-devel,
I just updated the 3.8 release process with the schedule/planning of the release: http://wiki.koha-community.org/wiki/Roadmap_to_3.8
Here it is: March, 23th (1 month before the release) = feature freeze. April, 6th = strong feature freeze, string freeze April 20th = starting release process, everything frozen April 23th = release of Koha 3.8.0
IMPORTANT = perltidy process
In january IRC meeting we spoke of perltidy thing. We have a coding guideline rule that says code must be perltidied. However, all the existing code is not perltidied, and it's hard to mix perltidied and non perltidied code. Thus, we have investigated the idea of doing a "perltidy big-bang" just when releasing 3.8.0, for all the code.
Pro: * the code will be perltidied, the coding guideline will be applicable * all perltidy being made at the same time, it will be easier to read the git log. (One of the argument against perltidying is that it's a problem for reading git history)
Doing it in one hit only makes this better if it is possible to have git blame ignore this commit. I just want to go on record as disagreeing with this plan. But happy to abide by community decision I just reserve the right to complain :-) Chris
* doing that for a release is better for future bugfixes means that patches will apply on 3.8 as well as on master.
Cons: * patches that are waiting may become "does not apply" because of the perltidy thing * patches submitted to fix bugs in 3.8 may not apply on 3.6 easily, that will add more work for 3.6 releases.
All in one, our conclusion was that the best solution is to do that during a release process. So I plan do it during 3.8 release.
(I have a (small ?) question about that : do you think I should make only one huge commit with perltidy ? one for each directory ? one for each file ?)
-- 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/
Le 08/03/2012 18:30, Chris Cormack a écrit :
Doing it in one hit only makes this better if it is possible to have git blame ignore this commit.
I don't think it's possible.
I just want to go on record as disagreeing with this plan. But happy to abide by community decision I just reserve the right to complain :-)
Well, speaking with Katrin, it seems the decision was not that clear: http://stats.workbuffer.org/irclog/koha/2012-01-04#i_857956 I'm OK to discuss of it again, but I'd like to have counter proposals. And if we can't find an option that please everyone, then maybe do nothing, and remove the rule from the coding guidelines and never complain again or start a discussion about that (not speaking of new files here, just existing ones) I made a list of pro and cons of the "big bang" option, feel free (everybody) to add another suggestion or complete my pro/cons list (note: this encouragement is not for chris C. only, but for everybody) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Mar 9, 2012 6:41 AM, "Paul Poulain" <paul.poulain@biblibre.com> wrote:
Le 08/03/2012 18:30, Chris Cormack a écrit :
Doing it in one hit only makes this better if it is possible to have git blame ignore this commit.
I don't think it's possible.
I just want to go on record as disagreeing with this plan. But happy to abide by community decision I just reserve the right to complain :-)
Well, speaking with Katrin, it seems the decision was not that clear: http://stats.workbuffer.org/irclog/koha/2012-01-04#i_857956
I'm OK to discuss of it again, but I'd like to have counter proposals. And if we can't find an option that please everyone, then maybe do nothing, and remove the rule from the coding guidelines and never complain again or start a discussion about that (not speaking of new files here, just existing ones)
My counter proposal is tidy as you go. Fix code as you touch it. With vim (and other editors) you can easily tidy a block, doing that as code is changed would be my preference. Chris
I made a list of pro and cons of the "big bang" option, feel free (everybody) to add another suggestion or complete my pro/cons list
(note: this encouragement is not for chris C. only, but for everybody) -- 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/
2012/3/8 Chris Cormack <chris@bigballofwax.co.nz>
My counter proposal is tidy as you go. Fix code as you touch it.
With vim (and other editors) you can easily tidy a block, doing that as code is changed would be my preference.
I'd prefer a "pay-as-you-go" approach as well. We could simply require all work to be tidied before submitting. Slow? Yes, but not nearly as messy and preserves the history. Kind Regards, Chris
I agree with Chris C. and Chris N. - I think what we would win does not outweigh the loss of history. Katrin -----Ursprüngliche Nachricht----- Von: koha-devel-bounces@lists.koha-community.org im Auftrag von Chris Nighswonger Gesendet: Do 08.03.2012 19:26 An: Chris Cormack Cc: koha-devel@lists.koha-community.org Betreff: Re: [Koha-devel] Koha 3.8 release schedule & perltidy process 2012/3/8 Chris Cormack <chris@bigballofwax.co.nz>
My counter proposal is tidy as you go. Fix code as you touch it.
With vim (and other editors) you can easily tidy a block, doing that as code is changed would be my preference.
I'd prefer a "pay-as-you-go" approach as well. We could simply require all work to be tidied before submitting. Slow? Yes, but not nearly as messy and preserves the history. Kind Regards, Chris
+1 to a gradual perltidy 2012/3/8 Fischer, Katrin <Katrin.Fischer@bsz-bw.de>
**
I agree with Chris C. and Chris N. - I think what we would win does not outweigh the loss of history.
Katrin
-----Ursprüngliche Nachricht----- Von: koha-devel-bounces@lists.koha-community.org im Auftrag von Chris Nighswonger Gesendet: Do 08.03.2012 19:26 An: Chris Cormack Cc: koha-devel@lists.koha-community.org Betreff: Re: [Koha-devel] Koha 3.8 release schedule & perltidy process
2012/3/8 Chris Cormack <chris@bigballofwax.co.nz>
My counter proposal is tidy as you go. Fix code as you touch it.
With vim (and other editors) you can easily tidy a block, doing that as code is changed would be my preference.
I'd prefer a "pay-as-you-go" approach as well. We could simply require all work to be tidied before submitting.
Slow? Yes, but not nearly as messy and preserves the history.
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/
-- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
Doing a large updating commit does not cost us any history. It just counts as an "update" to the code, even though none of the logic has changed. This change would alter SLOC counts and such, messing with our statistics, since we only want to measure intellectually significant contributions (tidying someone else's work doesn't make it yours). There is no way for Git to know if a change to a line of text is a logical change or just a formatting change (aside from whitespace), because Git doesn't understand Perl. There isn't too much we can do about this. So, best to keep cleaning up incrementally, I think. As we move from C4 to Koha, that'll be an opportunity to clean up all the modules -Ian 2012/3/8 Jared Camins-Esakov <jcamins@cpbibliography.com>
+1 to a gradual perltidy
2012/3/8 Fischer, Katrin <Katrin.Fischer@bsz-bw.de>
**
I agree with Chris C. and Chris N. - I think what we would win does not outweigh the loss of history.
Katrin
-----Ursprüngliche Nachricht----- Von: koha-devel-bounces@lists.koha-community.org im Auftrag von Chris Nighswonger Gesendet: Do 08.03.2012 19:26 An: Chris Cormack Cc: koha-devel@lists.koha-community.org Betreff: Re: [Koha-devel] Koha 3.8 release schedule & perltidy process
2012/3/8 Chris Cormack <chris@bigballofwax.co.nz>
My counter proposal is tidy as you go. Fix code as you touch it.
With vim (and other editors) you can easily tidy a block, doing that as code is changed would be my preference.
I'd prefer a "pay-as-you-go" approach as well. We could simply require all work to be tidied before submitting.
Slow? Yes, but not nearly as messy and preserves the history.
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/
-- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/
_______________________________________________ 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 (koha.sekjal@gmail.com) wrote:
Doing a large updating commit does not cost us any history.A It just counts as an "update" to the code, even though none of the logic has changed.A A This change would alter SLOC counts and such, messing with our statistics, since we only want to measure intellectually significant contributions (tidying someone else's work doesn't make it yours).A There is no way for Git to know if a change to a line of text is a logical change or just a formatting change (aside from whitespace), because Git doesn't understand Perl.A There isn't too much we can do about this.
It's not so much statistics I care about, although I do. But also that it makes it hard to to do a git blame to find which commit actually changed the line. Since now every line is changed by the same commit. Chris
So, best to keep cleaning up incrementally, I think.A As we move from C4 to Koha, that'll be an opportunity to clean up all the modules
-Ian
2012/3/8 Jared Camins-Esakov <jcamins@cpbibliography.com>
+1 to a gradual perltidy
2012/3/8 Fischer, Katrin <Katrin.Fischer@bsz-bw.de>
I agree with Chris C. and Chris N. - I think what we would win does not outweigh the loss of history.
Katrin
-----UrsprA 1/4ngliche Nachricht----- Von: koha-devel-bounces@lists.koha-community.org im Auftrag von Chris Nighswonger Gesendet: Do 08.03.2012 19:26 An: Chris Cormack Cc: koha-devel@lists.koha-community.org Betreff: Re: [Koha-devel] Koha 3.8 release schedule & perltidy process
2012/3/8 Chris Cormack <chris@bigballofwax.co.nz>
> My counter proposal is tidy as you go. Fix code as you touch it. > > With vim (and other editors) you can easily tidy a block, doing that as > code is changed would be my preference. >
I'd prefer a "pay-as-you-go" approach as well. We could simply require all work to be tidied before submitting.
Slow? Yes, but not nearly as messy and preserves the history.
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/
-- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/ _______________________________________________ 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/
-- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
Chris, Right, with the colossal commit option, one could have to 1. Know the commit id of the change 2. git blame something 3. if that id comes up, then git checkout -b temporary <<the_id_of_the_change>>^ 4. git blame again The more history we pile on top of that, the longer it'll take git to update the index, and then restore back to master when you're done. If you're tracing out lots of blames, then this can be a serious crimp in workflow. -Ian On Thu, Mar 8, 2012 at 13:50, Chris Cormack <chrisc@catalyst.net.nz> wrote:
* Ian Walls (koha.sekjal@gmail.com) wrote:
Doing a large updating commit does not cost us any history.A It just counts as an "update" to the code, even though none of the logic has changed.A A This change would alter SLOC counts and such, messing with our statistics, since we only want to measure intellectually significant contributions (tidying someone else's work doesn't make it yours).A There is no way for Git to know if a change to a line of text is a logical change or just a formatting change (aside from whitespace), because Git doesn't understand Perl.A There isn't too much we can do about this.
It's not so much statistics I care about, although I do. But also that it makes it hard to to do a git blame to find which commit actually changed the line. Since now every line is changed by the same commit.
Chris
So, best to keep cleaning up incrementally, I think.A As we move
to Koha, that'll be an opportunity to clean up all the modules
-Ian
2012/3/8 Jared Camins-Esakov <jcamins@cpbibliography.com>
+1 to a gradual perltidy
2012/3/8 Fischer, Katrin <Katrin.Fischer@bsz-bw.de>
I agree with Chris C. and Chris N. - I think what we would win does not outweigh the loss of history.
Katrin
-----UrsprA 1/4ngliche Nachricht----- Von: koha-devel-bounces@lists.koha-community.org im Auftrag von Chris Nighswonger Gesendet: Do 08.03.2012 19:26 An: Chris Cormack Cc: koha-devel@lists.koha-community.org Betreff: Re: [Koha-devel] Koha 3.8 release schedule & perltidy
from C4 process
2012/3/8 Chris Cormack <chris@bigballofwax.co.nz>
> My counter proposal is tidy as you go. Fix code as you touch it. > > With vim (and other editors) you can easily tidy a block, doing
that
as > code is changed would be my preference. >
I'd prefer a "pay-as-you-go" approach as well. We could simply
require
all work to be tidied before submitting.
Slow? Yes, but not nearly as messy and preserves the history.
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/
-- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445 (e-mail) jcamins@cpbibliography.com (web) http://www.cpbibliography.com/ _______________________________________________ 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/
-- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
+1 for a gradual perl tidy too Even then, still don't like the idea of blocking a patch for tabs and spaces .. ________________________________ Van: koha-devel-bounces@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] namens Ian Walls [koha.sekjal@gmail.com] Verzonden: donderdag 8 maart 2012 20:21 To: Chris Cormack Cc: Fischer, Katrin; koha-devel@lists.koha-community.org Onderwerp: Re: [Koha-devel] Koha 3.8 release schedule & perltidy process Chris, Right, with the colossal commit option, one could have to 1. Know the commit id of the change 2. git blame something 3. if that id comes up, then git checkout -b temporary <<the_id_of_the_change>>^ 4. git blame again The more history we pile on top of that, the longer it'll take git to update the index, and then restore back to master when you're done. If you're tracing out lots of blames, then this can be a serious crimp in workflow. -Ian On Thu, Mar 8, 2012 at 13:50, Chris Cormack <chrisc@catalyst.net.nz<mailto:chrisc@catalyst.net.nz>> wrote: * Ian Walls (koha.sekjal@gmail.com<mailto:koha.sekjal@gmail.com>) wrote:
Doing a large updating commit does not cost us any history.A It just counts as an "update" to the code, even though none of the logic has changed.A A This change would alter SLOC counts and such, messing with our statistics, since we only want to measure intellectually significant contributions (tidying someone else's work doesn't make it yours).A There is no way for Git to know if a change to a line of text is a logical change or just a formatting change (aside from whitespace), because Git doesn't understand Perl.A There isn't too much we can do about this.
It's not so much statistics I care about, although I do. But also that it makes it hard to to do a git blame to find which commit actually changed the line. Since now every line is changed by the same commit. Chris
So, best to keep cleaning up incrementally, I think.A As we move from C4 to Koha, that'll be an opportunity to clean up all the modules
-Ian
2012/3/8 Jared Camins-Esakov <jcamins@cpbibliography.com<mailto:jcamins@cpbibliography.com>>
+1 to a gradual perltidy
2012/3/8 Fischer, Katrin <Katrin.Fischer@bsz-bw.de<mailto:Katrin.Fischer@bsz-bw.de>>
I agree with Chris C. and Chris N. - I think what we would win does not outweigh the loss of history.
Katrin
-----UrsprA 1/4ngliche Nachricht----- Von: koha-devel-bounces@lists.koha-community.org<mailto:koha-devel-bounces@lists.koha-community.org> im Auftrag von Chris Nighswonger Gesendet: Do 08.03.2012 19:26 An: Chris Cormack Cc: koha-devel@lists.koha-community.org<mailto:koha-devel@lists.koha-community.org> Betreff: Re: [Koha-devel] Koha 3.8 release schedule & perltidy process
2012/3/8 Chris Cormack <chris@bigballofwax.co.nz<mailto:chris@bigballofwax.co.nz>>
> My counter proposal is tidy as you go. Fix code as you touch it. > > With vim (and other editors) you can easily tidy a block, doing that as > code is changed would be my preference. >
I'd prefer a "pay-as-you-go" approach as well. We could simply require all work to be tidied before submitting.
Slow? Yes, but not nearly as messy and preserves the history.
Kind Regards, Chris
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org<mailto: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/
-- Jared Camins-Esakov Bibliographer, C & P Bibliography Services, LLC (phone) +1 (917) 727-3445<tel:%2B1%20%28917%29%20727-3445> (e-mail) jcamins@cpbibliography.com<mailto:jcamins@cpbibliography.com> (web) http://www.cpbibliography.com/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org<mailto: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<mailto: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/
-- Chris Cormack Catalyst IT Ltd. +64 4 803 2238<tel:%2B64%204%20803%202238> PO Box 11-053, Manners St, Wellington 6142, New Zealand
Hello all, Have we considered using git's hooks for tidifying the code before checking it in, or even on the server, this would ensure that whoever does the checkin, it will be tidified. Also, if we consider going with a global tidifying, a good timing could be when creating a new branch. My 2 cents ! Eric Bégin www.inLibro.com On 2012-03-09 04:16, Marcel de Rooy wrote:
+1 for a gradual perl tidy too
Even then, still don't like the idea of blocking a patch for tabs and spaces ..
------------------------------------------------------------------------ *Van:* koha-devel-bounces@lists.koha-community.org [koha-devel-bounces@lists.koha-community.org] namens Ian Walls [koha.sekjal@gmail.com] *Verzonden:* donderdag 8 maart 2012 20:21 *To:* Chris Cormack *Cc:* Fischer, Katrin; koha-devel@lists.koha-community.org *Onderwerp:* Re: [Koha-devel] Koha 3.8 release schedule & perltidy process
Chris,
Right, with the colossal commit option, one could have to
1. Know the commit id of the change 2. git blame something 3. if that id comes up, then git checkout -b temporary <<the_id_of_the_change>>^ 4. git blame again
The more history we pile on top of that, the longer it'll take git to update the index, and then restore back to master when you're done. If you're tracing out lots of blames, then this can be a serious crimp in workflow.
-Ian
On Thu, Mar 8, 2012 at 13:50, Chris Cormack <chrisc@catalyst.net.nz <mailto:chrisc@catalyst.net.nz>> wrote:
* Ian Walls (koha.sekjal@gmail.com <mailto:koha.sekjal@gmail.com>) wrote: > Doing a large updating commit does not cost us any history.A It just > counts as an "update" to the code, even though none of the logic has > changed.A A This change would alter SLOC counts and such, messing with > our statistics, since we only want to measure intellectually significant > contributions (tidying someone else's work doesn't make it yours).A There > is no way for Git to know if a change to a line of text is a logical > change or just a formatting change (aside from whitespace), because Git > doesn't understand Perl.A There isn't too much we can do about this.
It's not so much statistics I care about, although I do. But also that it makes it hard to to do a git blame to find which commit actually changed the line. Since now every line is changed by the same commit.
Chris > > So, best to keep cleaning up incrementally, I think.A As we move from C4 > to Koha, that'll be an opportunity to clean up all the modules > > -Ian > > 2012/3/8 Jared Camins-Esakov <jcamins@cpbibliography.com <mailto:jcamins@cpbibliography.com>> > > +1 to a gradual perltidy > > 2012/3/8 Fischer, Katrin <Katrin.Fischer@bsz-bw.de <mailto:Katrin.Fischer@bsz-bw.de>> > > I agree with Chris C. and Chris N. - I think what we would win does > not outweigh the loss of history. > > Katrin > > -----UrsprA 1/4ngliche Nachricht----- > Von: koha-devel-bounces@lists.koha-community.org <mailto:koha-devel-bounces@lists.koha-community.org> im Auftrag von Chris > Nighswonger > Gesendet: Do 08.03.2012 19:26 > An: Chris Cormack > Cc: koha-devel@lists.koha-community.org <mailto:koha-devel@lists.koha-community.org> > Betreff: Re: [Koha-devel] Koha 3.8 release schedule & perltidy process > > 2012/3/8 Chris Cormack <chris@bigballofwax.co.nz <mailto:chris@bigballofwax.co.nz>> > > > My counter proposal is tidy as you go. Fix code as you touch it. > > > > With vim (and other editors) you can easily tidy a block, doing that > as > > code is changed would be my preference. > > > > I'd prefer a "pay-as-you-go" approach as well. We could simply require > all > work to be tidied before submitting. > > Slow? Yes, but not nearly as messy and preserves the history. > > Kind Regards, > Chris > > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha-community.org <mailto: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/ > > -- > Jared Camins-Esakov > Bibliographer, C & P Bibliography Services, LLC > (phone) +1 (917) 727-3445 <tel:%2B1%20%28917%29%20727-3445> > (e-mail) jcamins@cpbibliography.com <mailto:jcamins@cpbibliography.com> > (web) http://www.cpbibliography.com/ > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha-community.org <mailto: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 <mailto: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/
-- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 <tel:%2B64%204%20803%202238> PO Box 11-053, Manners St, Wellington 6142, New Zealand
_______________________________________________ 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 09/03/2012 13:36, Eric Bégin a écrit :
Hello all,
Have we considered using git's hooks for tidifying the code before checking it in, or even on the server, this would ensure that whoever does the checkin, it will be tidified.
Also, if we consider going with a global tidifying, a good timing could be when creating a new branch.
(this message is not for Eric specifically) => do you all have read the IRC discussion ? http://stats.workbuffer.org/irclog/koha/2012-01-04#i_857956 Most of the points raised on this thread have been discussed, side-effect, pro and cons explained. For the "do it on the fly" path, I could be OK to go with it if I understood how it can be done: * perltidying only the lines you submit will result in unreadable code * perltridying a whole file when you submit a patch will result in an unreadable git blame, like the "big bang" perltidy option * not everybody uses vim so, how to achieve the "on the fly" path is still a mystery for me -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Hi Paul, all, We had to do exactly the same kind of process on another project couple of years ago ( in java ) We had decided, at that time, to go gradually and the way we did it was always by "function that you touch". At the end our, QA team ask us to still be able to understand what is the change even if look of the code can be really different. Anthony -----Message d'origine----- De : koha-devel-bounces@lists.koha-community.org [mailto:koha-devel-bounces@lists.koha-community.org] De la part de Paul Poulain Envoyé : 9 mars 2012 07:46 À : koha-devel@lists.koha-community.org Objet : Re: [Koha-devel] Koha 3.8 release schedule & perltidy process Le 09/03/2012 13:36, Eric Bégin a écrit :
Hello all,
Have we considered using git's hooks for tidifying the code before checking it in, or even on the server, this would ensure that whoever does the checkin, it will be tidified.
Also, if we consider going with a global tidifying, a good timing could be when creating a new branch.
(this message is not for Eric specifically) => do you all have read the IRC discussion ? http://stats.workbuffer.org/irclog/koha/2012-01-04#i_857956 Most of the points raised on this thread have been discussed, side-effect, pro and cons explained. For the "do it on the fly" path, I could be OK to go with it if I understood how it can be done: * perltidying only the lines you submit will result in unreadable code * perltridying a whole file when you submit a patch will result in an unreadable git blame, like the "big bang" perltidy option * not everybody uses vim so, how to achieve the "on the fly" path is still a mystery for me -- 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 2012-03-9, at 10:16 PM, Marcel de Rooy wrote:
+1 for a gradual perl tidy too
+1 to a gradual perltidy from me too
So, best to keep cleaning up incrementally, I think.A As we move from C4 to Koha, that'll be an opportunity to clean up all the modules
-Ian
2012/3/8 Jared Camins-Esakov <jcamins@cpbibliography.com>
+1 to a gradual perltidy
2012/3/8 Fischer, Katrin <Katrin.Fischer@bsz-bw.de>
I agree with Chris C. and Chris N. - I think what we would win does not outweigh the loss of history.
Katrin
2012/3/8 Chris Cormack <chris@bigballofwax.co.nz>
> My counter proposal is tidy as you go. Fix code as you touch it. > > With vim (and other editors) you can easily tidy a block, doing that as > code is changed would be my preference. >
I'd prefer a "pay-as-you-go" approach as well. We could simply require all work to be tidied before submitting.
Slow? Yes, but not nearly as messy and preserves the history.
Kind Regards, Chris
+1 to a gradual perltidy. In this case, we should add a comment on processed files like : "#format by perltidy" ie -- Fridolyn SOMERS fridolyn.somers@gmail.com Marsillargues - France <fridolyn.somers@gmail.com> 2012/3/10 Mason James <mtj@kohaaloha.com>
On 2012-03-9, at 10:16 PM, Marcel de Rooy wrote:
+1 for a gradual perl tidy too
+1 to a gradual perltidy from me too
So, best to keep cleaning up incrementally, I think.A As we move from C4 to Koha, that'll be an opportunity to clean up all the modules
-Ian
2012/3/8 Jared Camins-Esakov <jcamins@cpbibliography.com>
+1 to a gradual perltidy
2012/3/8 Fischer, Katrin <Katrin.Fischer@bsz-bw.de>
I agree with Chris C. and Chris N. - I think what we would win does not outweigh the loss of history.
Katrin
2012/3/8 Chris Cormack <chris@bigballofwax.co.nz>
> My counter proposal is tidy as you go. Fix code as you touch it. > > With vim (and other editors) you can easily tidy a block, doing that as > code is changed would be my preference. >
I'd prefer a "pay-as-you-go" approach as well. We could simply
require
all work to be tidied before submitting.
Slow? Yes, but not nearly as messy and preserves the history.
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/
<fridolyn.somers@gmail.com>
2012/3/8 Chris Cormack <chris@bigballofwax.co.nz>
Doing it in one hit only makes this better if it is possible to have git blame ignore this commit.
Interestingly enough there seems to have been a patch submitted to GIT to do just this sort of thing, but it got dropped along the way: http://git.661346.n2.nabble.com/PATCH-blame-can-specify-shas-of-commits-to-i... Kind Regards, Chris
Hi to all, ----- Messaggio originale -----
Da: "Paul Poulain" <paul.poulain@biblibre.com> A: koha-devel@lists.koha-community.org Inviato: Giovedì, 8 marzo 2012 13:59:16 Oggetto: [Koha-devel] Koha 3.8 release schedule & perltidy process
Hello koha-devel,
IMPORTANT = perltidy process
In january IRC meeting we spoke of perltidy thing. We have a coding guideline rule that says code must be perltidied. However, all the existing code is not perltidied, and it's hard to mix perltidied and non perltidied code. Thus, we have investigated the idea of doing a "perltidy big-bang" just when releasing 3.8.0, for all the code.
personaly speaking I'm for a "perltidy big-bang" during release. If not, I think that to apply a perltidy we need to work on WHOLE file. I suggest to start from C4 libraries, with a specific commit that do only a perltidy chage. I we don't start we never do it. Bye Zeno Tajoli
participants (13)
-
Chris Cormack -
Chris Cormack -
Chris Nighswonger -
Eric Bégin -
Fischer, Katrin -
Fridolyn SOMERS -
Ian Walls -
Jared Camins-Esakov -
Laquerre, Anthony -
Marcel de Rooy -
Mason James -
Paul Poulain -
tajoli＠cilea.it