On 31-01-13 16:04, Derek Atkins wrote:
Geert Janssens <[email protected]> writes:
[snip]
Daggy fixing is probably not the only useful scheme though. I could
also imagine something like this to work:
- all bugfixes and only bugfixes happen on the 2.4 branch
- the 2.4 branch regularly gets merged into the development branch, so
all bugfixes also will end up in future releases
This concept is no longer back-porting, but
forward-porting. Advantage: all bugfixes eventually end up in the
active trees and git branches show the history, no need for BP->AUDIT
Note that neither daggy fixing nor forward porting are possible as
long as we're tied to svn. So this discussion is on future process,
not practical next steps yet.
Techncally we could do the "all bugfixes go into release; frequently
merge release back into trunk" method. The downside is that larger
"fixes" dont get tested as much before going into the release.
You have point there, but here are some counter points:
- I think our bugfixing policy would still remain: only bugfixes that
don't risk the stability of the release branch should go there. Larger
fixes should only be done on the development branch. They wouldn't have
been backported in our current process either
- Also, git best practices really encourage to do larger development on
separate branches. That would then also happen for larger fixes. If the
developer doubts wether his larger change is ok for stable, he could
request a review of his particular branch before merging it into stable.
If it turns out the fix is too large or not appropriate for stable, the
branch can be rebased on development and only merged there. Or variants
thereof. I have even seen policy in other projects that ALL development
happens on separate branches, and that no branch can be merged into the
main development branch until at least one other dev has positively
reviewed it. Our team is too small for such a strict policy IMO though.
- Thirdly, if it is common habit that bugfixing happens on the stable
branch, that automatically means the stable branch will have more
testing, because several devs will be using it more frequently (for
their bugfixes). It might even give us more testing, because the devs
would be spending more time on that branch in general than they do in
our current process.
How can we in the future improve our process to something in which the
history clearly reflects what actually happened, in which no work is
lost (by forgetting to backport) and without too much overhead.
And also test/review changes before they go into the release branch?
John's suggestion of test coverage is one way. Requiring all development
to happen on separate branches and only merge after at least x reviews
is another. Both are not very practical though currently.
Geert
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
