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 ?
Add AUDIT as soon as one commit in the push asks for backporting ?
Alternatively I played with the idea to just drop the whole BP trickery.
Instead we could use a backport branch in git. Each dev that commits
something to trunk/master that should also be backported, could
cherry-pick this commit to the backport branch. Since this would trigger
a mail notification that the backport branch was updated, this also
serves as a heads-up, just like the AUDIT tag would have. This
alternative may not be possible as long as we are bound to svn. Svn is
pretty poor in merging, while git's cherry-pick is very easy. Then
again, as the backporting is currently mostly done by devs that already
work from git anyway, it may work now already.
Yet another option would be to send mails per commit. That would mean
though we'd have to start from scratch for our mail script and I'm not
sure I know enough of git internals to be able to deal with all commit
types properly. I prefer not to go this route if possible.
Any thoughts, bright ideas, suggestions ?
Geert
P.S. Now is perhaps also a good time to re-evaluate our mail sending
habits. Do we really still need two different mails ? I know one is only
a summary while the other hold the complete diff, but do we want to
generate both types or is one sufficient ? What are the use cases and
are they still valid ?
On 30-01-13 15:25, Geert Janssens wrote:
Hi,
I have been working on a script that would allow the git repos to send
notification mails whenever changes are pushed. This is the equivalent
of the automated notification mails that get sent to gnucash-patches
and gnucash-changes whenever a change is committed to svn.
Since git's behaviour doesn't map 1 on 1 to svn's, I have started from
an example script that is distributed together with git. Attached you
will find two example mails generated by the new script
These were generated in a repo called "testing", on branch "master"
after I had pushed two commits to the git repo. It's worth noting
already that the script will only send one mail even though it
processes two commits. The script sends one mail per push and per
branch. So if one push affects 3 branches, it will send 3 mails. Well,
actually 3 sets of 2 mails.
The first mail contains a summary of the commit logs (similar to what
is currently sent to gnucash-changes), the second one also contains
the commit diffs (similar to what is currently sent to gnucash-patches).
Personally I think the introduction in the mails is way to verbose.
I'm open to suggestions to improve this.
Please give your feedback, thanks.
Geert
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
_______________________________________________
gnucash-devel mailing list
[email protected]
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
