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 ?
That part aside, I rather like the bug fix branch idea from the other thread.
It's somewhat apropos to David Carlson's workflow concerns about bugs falling
off the Bugzilla default searches as soon as they're marked resolved, but
that's another thread.
Glad you like it.
Geert
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
