Notification mails for git repos - resend

[John Ralls]

On Feb 8, 2013, at 1:49 AM, Geert Janssens <janssens-geert at telenet.be> wrote:

> On 07-02-13 19:21, John Ralls wrote:
>> On Feb 7, 2013, at 8:42 AM, Geert Janssens <janssens-geert at telenet.be> wrote:
>> 
>>> On 07-02-13 16:42, John Ralls wrote:
>>>> Do we want to be sending commit-mail from gitolite while we're still committing to svn? ISTM that's something to turn on after we drop svn. Not that you shouldn't have done the work, of course. It's good to have everything ready, even if it's another year before we release 2.6 and switch to git for everything... just like last week's discussion about branching strategies.
>>>> 
>>>> Regards,
>>>> John Ralls
>>>> 
>>> There are many aspects in your question, so I have several answers...
>>> 
>>> 1. I would hope to see a 2.6 release sooner than that. I am aware that may not be realistic though.
>>> 
>>> 2. Regardless, I don't want to wait that long to fully switch to git. So I'm steadily fixing each issue to prevents us to switch. The mail script was one of them. Others that are still pending are:
>>> - the website live update from git. I'm currently working with Derek and Linas to get this set up
>>> - the AUDIT prefix. I still have to investigate if I can approximate it in the git mail script (probably I can)
>>> - building 2.4 and tags from git on Windows, still to investigate also
>>> 
>>> That's also roughly the order in which I will try to fix things.
>>> 
>>> The website will not be a big obstacle. My intention is to switch all website updates to git only as soon as Linas has configured the updates on his server and I have run some tests. That would require the mail notification from to be functional, because svn for the website will then be disabled and hence won't send notifications anymore.
>>> 
>>> The website repo doesn't make use of the BP/AUDIT tagging, so it doesn't have to wait for the mail notification fix in that area. The gnucash and gnucash-docs repo do use it, so BP/AUDIT taggins is one requirement for switching those repos.
>>> 
>>> The other requirement is a stable build from git for 2.4 and tags. If I can manage to get those working reliably I think we can switch completely switch sooner than 2.6
>>> 
>>> 3. Even though it may take some time before we're fully in git, we can already start sending mails from git and disable sending mails from svn earlier. It's one less dependency on svn that way. As said, I will first need to find a solution for the AUDIT feature before that can happen. Working on that :)
>>> 
>>> 4. The branching strategies discussion is the only really long-term item. I don't think it would be useful to change our strategy for 2.4 still.
>>> 
>> Do we really need the BP/AUDIT mechanism? I don't think we're really using it the way it's intended anyway. We can't, really, because there aren't enough active devs to make it work.
> I agree that it doesn't add much currently except for a clearly visible reminder in the mail subject. If the mail script can't regenerate this, a slightly less visible marker still remains in the mail body, the "BP" marker.
> 
> I have been looking a bit deeper into adding an AUDIT prefix in the git mails, but that will cause a lot of extra code complexity (effectively doing some work twice in different scripts), so I'd rather not implement it.
> 
> On the other hand I think for now we should keep the habits of
> - adding BP in commits to backport and
> - adding the svn revision number of the original commit in the backported commit.
> At least that gives us two markers we can use to (manually and cumbersomely) trace if we missed any backports. We can drop this when we have a better tracking process in place using a backports branch.
>> Maybe if we think a code review would be a good idea we should make a patch and attach it to the bug, then ask here for a review. That's what we do for GLib/Gtk.
> Does GLib/Gtk require review for each patch, or only for more complicated ones ?

No requirement at all, it's always up to the developer. I should say that feature branches are another avenue for review, for changes which are *really* big, and there are quite a few of those.

We should certainly maintain our current practice for backporting as long as we're still using svn. 

Regards,
John Ralls