On Feb 8, 2013, at 1:49 AM, Geert Janssens <janssens-ge...@telenet.be> wrote:
> On 07-02-13 19:21, John Ralls wrote: >> On Feb 7, 2013, at 8:42 AM, Geert Janssens <janssens-ge...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
