On 31-01-13 04:45, John Ralls wrote:
On Jan 30, 2013, at 8:13 AM, Geert Janssens <[email protected]> wrote:
Here is a first practical limitation of the new script: the old scripts had some logic
built in that would add an AUDIT tag in front of the mail subject if the commit message
had a line containing solely "BP".
This gets more complicated with the new scripts. One mail can hold the commit
messages of multiple commits. What to do if only some of these commits are
supposed to be backported and have BP in their commit message ?
What design decision drove you away from one mail per commit?
Regards,
John Ralls
The simple fact that the example script was written for one mail per
push, to be used in the post-receive hook. Github's mail hook also works
that way, so I was under the impression that in git setups this is the
preferred way to send notifications.
Changing to a one mail per commit configuration means either finding a
trigger that fires for each commit, or writing a mail script that sends
individual mails for each commit in the push.
I have first looked for a trigger that fires on each commit, but didn't
find one we could use. In theory there is the update hook, but this one
is reserved by gitolite. And according to my experiments the post-commit
hook is not triggered in the receiving repo of a push operation.
So post-receive is the only hook we can use by my knowledge.
Which leaves us with finding or writing another mail script. My search
on the web always turns up the same script we currently use (already
slightly adapted). I haven't come across a script that sends seperate
mails per commit.
I personally don't feel like writing another script from scratch, as I
wonder how much we'd gain from it.
Granted, our BP->AUDIT feature wouldn't work anymore, but I like to
discuss if it is really worth keeping around or not.
To put it differently: I'm interested in learning about new best
practices and solutions offered by git, which claims to have much better
branch and merge facilities. That's partly why I started this mail thread.
In that sense I more or less like Yawar's daggy bugfixing suggestion:
using merge instead of cherry-pick nicely preserves history in the repo.
The drawback of needing manual intervention from time to time is valid
for both merging and cherry-picking.
It also eliminates the need for a BP->AUDIT scheme. By the name of the
branch, we know which commits are meant for backporting and the git
history could easily show which commits weren't backported yet.
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.
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.
Geert
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
