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/