Notification mails for git repos

[John Ralls]

On Jan 31, 2013, at 9:06 AM, Geert Janssens <janssens-geert at telenet.be> wrote:

> On 31-01-13 17:15, John Ralls wrote:
>> On Jan 31, 2013, at 7:04 AM, Derek Atkins <warlord at MIT.EDU> 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.
>>> 
>> I think that you guys have a misunderstanding about how merging works.
> Perhaps I do. That's why I'm discussing this topic here :)
>>  Try merging 2.4 back into trunk.
>> When I did just now, 4 files merged successfully, the rest have conflicts. One might be able to do better by playing with the merge options. I'm not going to spend the time.
> I believe this is in large part  because the common ancestor between 2.4 and trunk is already too far down history. I explicitly said regularly merging into the development branch.

No, you're looking at it backwards. The conflicts arise from changes to trunk, not stable.

We don't develop *anything* in the stable branch -- at least, we're not supposed to. Trunk changes, 2.4 mostly doesn't, and all of the changes in 2.4 are supposed to have been made in trunk first, so if trunk hasn't diverged much from stable, then a merge from stable into trunk should be a no-op.

The problem of course is that trunk *does* diverge. That's the whole point of having a stable branch. As trunk diverges, the code required to implement a bug fix becomes different between the two branches. The merge conflicts arise from those differences.

Now we *could* reduce that divergence by adopting a scheduled release process like Gnome has done. Then trunk would never be more than 6 months different from the current stable branch. We could go even further and adopt "continuous integration", though that's always seemed to me to be an anti-user approach (Gnome's users have been noisily unhappy), and both seen risky  given our poor test coverage. 

> Isn't it so that git's merge starts to compare differences from the most recent common ancestor ? That would mean that if the bugfixes were merged into development frequently (in the extreme case for each bugfix commit) the merge conflicts would be no more complicated than you would encounter with cherry-picking.
>> 
>> Merging a commit doesn't just look at the files touched by that particular commit, it looks at every difference between the trees of the source commit and the target (i.e., the current branch).
>> 
>> Cherry-pick exists for a reason.
> Sure, but I'm not convinced yet that that reason is our use case here. Suppose we depend on cherry picking for back- or forward-porting. How can it help us not to forget any back- or forward ports without having to go through all the commits manually to compare them between branches ?
> 
> Our current process (using the BP and AUDIT markers) has the same weaknesses IMO. There is no clear indication in the commit history of which commits were backported. We have BP/AUDIT as a visual reminder that backports should happen, but no easy way to check in retrospect if they actually happened.

Go reread the Wiki article on BP/AUDIT [1]:
"Developers should request changesets get audited and approved before they are pulled into the release branch."

The intent was that backports should get a code review from another developer before being committed to stable. Since we don't actually do that, perhaps the automated email is superfluous anyway. We could instead require a bug for backports and include the bug number in both commits, and both commits could be referenced in the bug before closing it. The commit note in stable could also note the source commit from trunk. When one finds a bug on one's own it's pretty easy to write a bug to satisfy that requirement, and ISTR someone mentioning a git-Bugzilla utility of some sort in the last couple of weeks.

>> 
>>>> 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?
>> The generally accepted best practice for that is to require 100% test coverage and to require that all tests (including a new one that covers the current change) pass. It doesn't seem likely that we would adopt that practice.
> No, we're not set up for that. But I believe it should be one of our goals to get better test coverage. I know you have this on your agenda and I'm quite happy about it.

> A couple of times I started looking into writing tests myself, but never managed to actually produce some due to lack of time and experience. Perhaps this is a good time to ask:
> a. do you know of a good introduction to unit testing ?
> b. is there some documentation on the unit testing framework used in gnucash ? How should a test be constructed ? Are there particular functions that should be used ? Things like that.
> 

We have a wiki page [2] on the subject, but it's a bit light. I'll work on that a bit. Perhaps you (and others) could look it over and suggest more topics that it needs to cover.

Regards,
John Ralls

[1] http://wiki.gnucash.org/wiki/Development_Process#Changeset_Auditing_Process
[2] http://wiki.gnucash.org/wiki/Testing