Notification mails for git repos
Geert Janssens
janssens-geert at telenet.be
Thu Jan 31 12:19:31 EST 2013
On 31-01-13 16:04, Derek Atkins wrote:
> Geert Janssens <janssens-geert at telenet.be> 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
More information about the gnucash-devel
mailing list