Geert Janssens <janssens-ge...@telenet.be> writes: > 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.
It seems silly to me to have an extra "waiting for backport" branch. > 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 ? I use the -patches email list to notice when the -commits email fails, so I can look into it. Generally this happens when there is a very large commit (like a translation update). I also use -patches it to decide if I need to look at the changesets immediately or if I think it can wait a bit. But I'm willing to change how I work if people want to change. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/ PP-ASEL-IA N1NWH warl...@mit.edu PGP key available _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel