Notification mails for git repos

[Geert Janssens]

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