Le 09/03/2012 12:44, Jonathan Druart a écrit :

This patch breaks the feature introduced by Bug 5347. In this patch, I have already make a refactoring of C4::Letters::SendAlerts

Could you give some details about what is broken ? I see the following changes: * sending mails, the utf8 encoding is removed: - Subject => Encode::encode( "utf8", "" . $innerletter->{title} ), - Message => Encode::encode( "utf8", "" . $innerletter->{content} ), * the order_infos stuff: + my @fields = map { + $sthorders->{mysql_table}[$_] . "." . $sthorders->{NAME}[$_] } + (0 .. $#{$sthorders->{NAME}} ) ; + + my @orders_infos; + while ( my $row = $sthorders->fetchrow_arrayref() ) { + my %rec = (); + @rec{@fields} = @$row; + push @orders_infos, \%rec; + } Is there more things ?

Commit id is b8e9829be5a59c84ba699fc015820cd4eb3fbc0a and is already pushed in Master.

-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08

You will need to provide much more info than that for it to be actually useful. Like what was broken and how. Chris On Mar 10, 2012 4:41 AM, "Paul Poulain" <paul.poulain@biblibre.com> wrote:

Le 09/03/2012 13:33, Paul Poulain a écrit :

...

Le 09/03/2012 12:44, Jonathan Druart a écrit :

...

This patch breaks the feature introduced by Bug 5347. In this patch, I have already make a refactoring of C4::Letters::SendAlerts

Could you give some details about what is broken ?

OK, I just spoke with Jonathan, and, definetly, the 7001 patch badly break something that has been commited on january, 20th. I'll revert it immediatly, srdjan, you'll have to work a little bit more on it, sorry for that

-- 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/

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 10/03/12 02:26, Paul Poulain wrote:

PS: for future reference = this patch was too large. It was making too many things at once. I think it could have been validated more easily and faster with smaller chunks. Like one for introducing html, one for introducing branch letter, one for ...

I agree with this and like to discuss it but not on the bug of course. How do you usually discuss things here that are of general nature? Srdjan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk9dLboACgkQX6p/D9UE7dwRkQCgiDBDYu9LvMwDbw708xm21bKd 02MAnjQYc7AQbnO05fcw4atEDaYGCeGs =3SeT -----END PGP SIGNATURE-----

I'd like to discuss the mechanics of it. Let's say we split our change into 4 smaller changes, and have a following situation: 2 depends on 1 3 and 4 depend on 2 * how do we make sure they are applied in right order * after a while 1 and 3 had to be reworked; again we need to make sure they are applied in order * let's say we are lucky and 1 gets pushed to master, 2 and 3 are signed-off and 4 is being worked on; how do we manage status etc? Waiting for sign-off in the order does not help, issues may arise after sign-off Srdjan On 12/03/12 21:38, Paul Poulain wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Le 11/03/2012 23:56, Srdjan a écrit :

...

I agree with this and like to discuss it but not on the bug of course. How do you usually discuss things here that are of general nature?

I'm not sure there's something to discuss. We (BibLibre) made this mistake for 3.4 = we submitted a lot of new features in very large bunches, that were very hard/impossible to test. Most of them have been splitted in smaller chunks, and in smallest chunks. Almost everything is now included, except the changes to issuing rules - -that was a great feature, that is live for many of our customers- : it mixed changes in issuing rules, smart-rules entering, hold rules, and conflicted with hard due date. At the end, we (BibLibre) have abandonned rebases for this, because it was too hard. And the feature is now lost, our customers are warned that, when migrating to 3.6 they'll loose some features.

If you look at our new submissions for acquisitions& serials, you can see that we've learnt, and now submit only atomic features as much as possible.

(If you have an idea of a discussion, feel free to start it here) - -- 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/

iQEcBAEBAgAGBQJPXbX9AAoJEK81SonuhyGoUoYIALI1eK5CNif97LCB87l3VbBB RZuijIkAUVw3PjOPg3T6O7KTXJRcXa2CYpMsoglqYEvM7Ye2Iwp/4JTrEpBGXtxn x8e2HHXsxkKWD+jlaLDiAS8JT4eI0RIeuztOw56sEvfEnc0P2HxHWoA6RHl/yDWO yRAHtRCDuIxof7L/Yvi2ajBbR1EVrvtU5htkSbVFgauhMepLiY9tmMLF3rfE8iMC psGsDVdzIGjpzwLRmIJ6RJh+pTjip2POxzEv4sxh6qy59E74jCz9Gfh5P9aDASQc HET0ns0hRJ/yrbL6rhircf5u8lUtsBki1NrU9EA+Cgc9s7xtWHvobo4eerCFg5o= =EfFy -----END PGP SIGNATURE-----

We've run up against this problem a few times in recent history. Small patches are easier to test, but harder to keep track of. Large patches make our paperwork simpler, but are much harder to test, and one broken aspect can delay many functional ones. I think the first part of the solution is to design your larger projects so that their dependencies or steps are atomic enough to be broken out into their own bug reports. The reports can be linked with dependencies, and each can be taken in turn. For bug reports that are a single issue, but contain multiple patches, I recommend prefixing the first line of the commit message with [STEP 1] or [STEP 2] or the like. This could be our internal heuristic for figuring out in what order patches must be applied. If two patches don't depend on each other, either squish them into one, or break them out into separate bug reports. Many of us are using Git BZ now for signoff and QA, so it becomes increasingly important for patches to remain in their proper order. If you have to rebase STEP 2, it'd be helpful to folks if you also rebased STEP 3 and beyond, so the patches stay in the right order. But, when testing, if this is not the case, it's only a little more work to type "n" in the patch application dialog until the right first patch comes up. Another mechanism for improving turn-around time on patches is to build or update automated test suites. These kinds of tests can be built into git aliases by testers, and run as part of the process. The more advanced the tests, the more nuances we can pick up on. As a wise man once said, there's no silver bullet, but I think with improved planning, a few community practices and some more test suites, we'll be able strike the right balance of stability and innovation. -Ian On Tue, Mar 13, 2012 at 05:54, Paul Poulain <paul.poulain@biblibre.com>wrote:

Le 12/03/2012 23:12, Srdjan a écrit :

...

I'd like to discuss the mechanics of it. Let's say we split our change into 4 smaller changes, and have a following situation: 2 depends on 1 3 and 4 depend on 2

My 2cts: * you must use dependencies on bugzilla so clearly state that one block/depend on another * we (BibLibre) face this problem for acquisition and serials improvements we are rebasing/submitting now. There are some things that we don't submit until other things have made their way into Koha.

If the patch workflow goes smoothly, then I think it's a mechanics that can work. However, we don't have, yet, a priority on signing-off a patch. It means that a patch that is trivial to test is usually tested faster than a patch that introduces a feature and requires a large testing.

Should we adopt a rule for the order of sign-off ? I'm not sure at all. But I think we should find a way to encourage people to test/sign-off things.

All in one, it's a tricky problem. I agree it adds some overhead on the work required to submit an enhancement. Everybody must be aware of that.

If you look at this mailing list history (or speak with Chris_c, as we had some strong discussions about that), you'll see I made some suggestions to change the current workflow, to have things pushed faster, to reduce the overhead. Others where afraid of introducing instability, so my ideas where rejected. I still think the overhead is something we should try to reduce, but still haven't be successful in proposing a technical way that is acceptable for our community.

If you can find a technical solution to reduce overhead without reducing stability, I'll be the happiest man here probably ;-)

-- 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-14, at 7:24 PM, Mason James wrote:

hi People

i believe there are 2 duplicated commits in the kc.org repo currently, that need to be corrected (by deleting 1 commit?)

specifically, these 2 commits.... http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=50585c34292b7aab... http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=da920b1da9f2f289...

these two commits... (a bit more info) :) commit 50585c34292b7aabfaabeba0db3f83612f55837e Author: Jonathan Druart <jonathan.druart@biblibre.com> Date: Thu Mar 8 10:09:23 2012 +0100 Bug 5341: Moves the "save" button to the top of the serial receiving Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com> Signed-off-by: Paul Poulain <paul.poulain@biblibre.com> commit da920b1da9f2f2895730758659d099245c2e64ba Author: Jonathan Druart <jonathan.druart@biblibre.com> Date: Thu Mar 8 10:09:23 2012 +0100 Bug 5341: Moves the "save" button to the top of the serial receiving Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com> Signed-off-by: Paul Poulain <paul.poulain@biblibre.com>

On 2012-03-15, at 12:54 AM, Chris Nighswonger wrote:

2012/3/14 Mason James <mtj@kohaaloha.com>

On 2012-03-14, at 7:24 PM, Mason James wrote:

...

hi People

i believe there are 2 duplicated commits in the kc.org repo currently, that need to be corrected (by deleting 1 commit?)

This has happened from time to time in the past in master. I seem to recall it causing a problem with my local branch once, but I deleted and recreated the branch and the problem disappeared.

Kind Regards, Chris

aaah, some good news... one (or three?) 'git reset --hard origin/master' later, my merge worked just fine... :) so the duped commits are no longer a problem for me :) paul.p, will you fix these commits in the kc.org repo?

2012/3/15 Mason James <mtj@kohaaloha.com>

actually, i take that back i seem to be having more rebase problems with my local repo, that are resolved after deleting one of those duped commits...

so... its still a general problem, i think?

paul.p , please fix?

A fetch and rebase work fine here. As I mentioned previously, there are any number of duplicate commits in the main repo at present. I think they occur during merges. I'm not sure that Paul can "fix" it. I am sure that if it was causing wide spread pain, we'd have heard quite a cry by now. :-) Kind Regards, Chris

On 2012-03-16, at 3:57 AM, Colin Campbell wrote:

On Thu, Mar 15, 2012 at 08:53:46AM -0400, Chris Nighswonger wrote:

...

A fetch and rebase work fine here. As I mentioned previously, there are any number of duplicate commits in the main repo at present. I think they occur during merges. I'm not sure that Paul can "fix" it. I am sure that if it was causing wide spread pain, we'd have heard quite a cry by now. :-) "Fixing" it will however cause pain for anyone trying to track that branch. Rewriting history in published branches is always a cause for grief. The duplicates occur when two branches with the same commit but different histories are merged. Part of the commit is not just the changes but what the parent commit is.

yep, and its right there that i'm confused :) both of these duplicated sequential commits have the *same* parent commit (aed0d8a63d5005e1c343def9a8ccbd9403ccd4aa) thats a little bit odd? http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=50585c34292b7aab... http://git.koha-community.org/gitweb/?p=koha.git;a=commit;h=da920b1da9f2f289... anyhoo, if the dupe commits aren't causing anyone else git-merge problems... i'm happy to let it go ;)