Re: Notification mails for git repos - resend
On 07-02-13 02:37, John Ralls wrote: You could use short commit numbers both for the subject line and the URLs e.g., https://github.com/Gnucash/gnucash-docs/commit/8686314 works just fine, which will make it a bit more readable. The preamble is way too long. The subject line says what the mail is about: Repo, branch, short changeset hash. The preamble can just be the changeset URL, again with the short hash. No need for the parent, there's a link to it on the Github change page. Then the log entry, and for patch-mail, the patch. Regards, John Ralls Thanks for the feedback. I have updated the mail script is several ways as a result: - use short commit hash in the subject line (and put it up front, just like the svn revision number was) - use short commit hashes in all urls - dropped the preamble text and some intermediary text - there are situations where a more complex push exists (non-fast-forwardable pushes which obscure some commits). In that case some additional explanation is added to the mail on what happened. I did not remove that. - I also haven't removed the parent. It may be helpful in some situations and in my personal opinion doesn't add that much clutter. Attached is a new example. Only one this time, because the only difference between the two mails is the amount of detail in the log section, which I haven't changed. Of note still is that the mail is sent by GIT SVN Migration user (git-svn). This is because the mail generation is triggered by the the svn-git push, which is currently always performed by the user account git-svn. With the scripts as they are now, the sending user will be set to the one actually pushing once svn is out of the loop. So if I push directly to a repo in gitolite, the mail will appear to come from me. I can't work around this in the current situation. Geert ---BeginMessage--- The branch, trunk has been updated via https://github.com/Gnucash/gnucash-docs/commit/7a387e0e (commit) from https://github.com/Gnucash/gnucash-docs/commit/fb47cf9b (commit) - Log - commit 7a387e0e63c73779c50102acd86a0948a08728fb Author: Geert Janssens janssens-ge...@telenet.be Date: Thu Feb 7 10:48:55 2013 + Dummy change to test gitolite commit hook git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash-docs/trunk@22762 57a11ea4-9604-0410-9ed3-97b8803252fd --- Summary of changes: README |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- gnucash-docs ---End Message--- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Notification mails for git repos - resend
On Feb 7, 2013, at 3:19 AM, Geert Janssens janssens-ge...@telenet.be wrote: On 07-02-13 02:37, John Ralls wrote: You could use short commit numbers both for the subject line and the URLs e.g., https://github.com/Gnucash/gnucash-docs/commit/8686314 works just fine, which will make it a bit more readable. The preamble is way too long. The subject line says what the mail is about: Repo, branch, short changeset hash. The preamble can just be the changeset URL, again with the short hash. No need for the parent, there's a link to it on the Github change page. Then the log entry, and for patch-mail, the patch. Regards, John Ralls Thanks for the feedback. I have updated the mail script is several ways as a result: - use short commit hash in the subject line (and put it up front, just like the svn revision number was) - use short commit hashes in all urls - dropped the preamble text and some intermediary text - there are situations where a more complex push exists (non-fast-forwardable pushes which obscure some commits). In that case some additional explanation is added to the mail on what happened. I did not remove that. - I also haven't removed the parent. It may be helpful in some situations and in my personal opinion doesn't add that much clutter. Attached is a new example. Only one this time, because the only difference between the two mails is the amount of detail in the log section, which I haven't changed. Of note still is that the mail is sent by GIT SVN Migration user (git-svn). This is because the mail generation is triggered by the the svn-git push, which is currently always performed by the user account git-svn. With the scripts as they are now, the sending user will be set to the one actually pushing once svn is out of the loop. So if I push directly to a repo in gitolite, the mail will appear to come from me. I can't work around this in the current situation. One more niggling comment: The branch, trunk has been updated is poor English. Single commas are for separating dependent clauses. You could write The branch, trunk, has been updated, but that puts the emphasis on branch and makes trunk a parenthetical. Better would be no comma: The branch trunk has been updated, but I like The trunk branch has been updated. I don't have a problem with the email being from the committer. All of our mailing lists work that way. As for non-fast-forward commits, those need to be discussed here before being pushed. It should be an extremely rare occurrence. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Proposed change to development Process was Fw: [Bug 650598] Cannot Enter Nth Day of Month Scheduled Transactions
As I requested in this closed bug, which is not in the current program release and may not be in the current release for many more months, how about adding a status Awaiting next Program Release so the bug can be found in a search for unresolved bugs? This should reduce duplicate bug reports. --- On Thu, 2/7/13, GnuCash bugzi...@gnome.org wrote: From: GnuCash bugzi...@gnome.org Subject: [Bug 650598] Cannot Enter Nth Day of Month Scheduled Transactions To: carlson...@sbcglobal.net Date: Thursday, February 7, 2013, 8:42 AM https://bugzilla.gnome.org/show_bug.cgi?id=650598 GnuCash | Engine | 2.4.5 --- Comment #12 from Geert Janssens i...@kobaltwit.be 2013-02-07 14:42:24 UTC --- A valid point, which crossed my mind on occasion as well. However, as a comment on a closed bug this is not very useful (even though the bug is an example to illustrate your point). You propose a change in the development process. That could at least be considered a general enhancement request, but better even be discussed openly on the gnucash-devel mailing list. -- Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Notification mails for git repos - resend
On 07-02-13 16:00, John Ralls wrote: On Feb 7, 2013, at 3:19 AM, Geert Janssens janssens-ge...@telenet.be wrote: On 07-02-13 02:37, John Ralls wrote: You could use short commit numbers both for the subject line and the URLs e.g., https://github.com/Gnucash/gnucash-docs/commit/8686314 works just fine, which will make it a bit more readable. The preamble is way too long. The subject line says what the mail is about: Repo, branch, short changeset hash. The preamble can just be the changeset URL, again with the short hash. No need for the parent, there's a link to it on the Github change page. Then the log entry, and for patch-mail, the patch. Regards, John Ralls Thanks for the feedback. I have updated the mail script is several ways as a result: - use short commit hash in the subject line (and put it up front, just like the svn revision number was) - use short commit hashes in all urls - dropped the preamble text and some intermediary text - there are situations where a more complex push exists (non-fast-forwardable pushes which obscure some commits). In that case some additional explanation is added to the mail on what happened. I did not remove that. - I also haven't removed the parent. It may be helpful in some situations and in my personal opinion doesn't add that much clutter. Attached is a new example. Only one this time, because the only difference between the two mails is the amount of detail in the log section, which I haven't changed. Of note still is that the mail is sent by GIT SVN Migration user (git-svn). This is because the mail generation is triggered by the the svn-git push, which is currently always performed by the user account git-svn. With the scripts as they are now, the sending user will be set to the one actually pushing once svn is out of the loop. So if I push directly to a repo in gitolite, the mail will appear to come from me. I can't work around this in the current situation. One more niggling comment: The branch, trunk has been updated is poor English. Single commas are for separating dependent clauses. You could write The branch, trunk, has been updated, but that puts the emphasis on branch and makes trunk a parenthetical. Better would be no comma: The branch trunk has been updated, but I like The trunk branch has been updated. I have used your last proposal (the trunk branch has...). See new attachment. I don't have a problem with the email being from the committer. All of our mailing lists work that way. I have no problem with that either. My note was not really clear on the issue I had: the svn based mails are sent from the real committer's id (if you commit the mail will be from jralls, if I commit it will be from gjanssens and so on). My intention was/is to copy this behaviour for the mails sent from git. This however doesn't work out currently because all commits to git are done by the git-svn user (on behalf of the real committer). So all git mails will appear to come from git-svn. I mentioned this because it is different from the svn behaviour. Either way, this is only a transient issue: once svn is out of the loop the real committers will be seen in the mail's From field. So I don't intend to change anything in that area anymore. As for non-fast-forward commits, those need to be discussed here before being pushed. It should be an extremely rare occurrence. Agreed on all aspects. Since these types of commits are supposed to be extremely rare, I don't mind either that the mails generated for such a push is more verbose. So I don't think this requires more tweaking of the notification mail. Regards, John Ralls Geert ---BeginMessage--- The trunk branch has been updated via https://github.com/Gnucash/gnucash-docs/commit/f76dafd0 (commit) from https://github.com/Gnucash/gnucash-docs/commit/12e91e77 (commit) - Log - commit f76dafd0589c0952570d78ec50adcd19552345be Author: Geert Janssens janssens-ge...@telenet.be Date: Thu Feb 7 15:13:25 2013 + Use spaces instead of tabs in a comment This makes sure the two lines are properly aligned regardless of the tab indent setting git-svn-id: svn+ssh://svn.gnucash.org/repo/gnucash-docs/trunk@22765 57a11ea4-9604-0410-9ed3-97b8803252fd --- Summary of changes: README |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) hooks/post-receive -- gnucash-docs ---End Message--- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Proposed change to development Process was Fw: [Bug 650598] Cannot Enter Nth Day of Month Scheduled Transactions
On Feb 7, 2013, at 7:21 AM, David Carlson carlson...@sbcglobal.net wrote: As I requested in this closed bug, which is not in the current program release and may not be in the current release for many more months, how about adding a status Awaiting next Program Release so the bug can be found in a search for unresolved bugs? This should reduce duplicate bug reports. It might, but we don't control bugzilla, gnome.org's Bug Squad [1] does. We don't have the privs to modify the workflow. Regards, John Ralls [1] https://live.gnome.org/Bugsquad/ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Fw: Re: Proposed change to development Process was Fw: [Bug 650598] Cannot Enter Nth Day of Month Scheduled Transactions
Then is there some other way to show the bug unresolved (because it has not been released) but the code is in the queue? David C --- On Thu, 2/7/13, John Ralls jra...@ceridwen.us wrote: From: John Ralls jra...@ceridwen.us Subject: Re: Proposed change to development Process was Fw: [Bug 650598] Cannot Enter Nth Day of Month Scheduled Transactions To: David Carlson carlson...@sbcglobal.net Cc: gnucash-devel gnucash-devel@gnucash.org, david.carlson@gmail.com Date: Thursday, February 7, 2013, 9:35 AM On Feb 7, 2013, at 7:21 AM, David Carlson carlson...@sbcglobal.net wrote: As I requested in this closed bug, which is not in the current program release and may not be in the current release for many more months, how about adding a status Awaiting next Program Release so the bug can be found in a search for unresolved bugs? This should reduce duplicate bug reports. It might, but we don't control bugzilla, gnome.org's Bug Squad [1] does. We don't have the privs to modify the workflow. Regards, John Ralls [1] https://live.gnome.org/Bugsquad/ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Notification mails for git repos - resend
On Feb 7, 2013, at 7:25 AM, Geert Janssens janssens-ge...@telenet.be wrote: On 07-02-13 16:00, John Ralls wrote: On Feb 7, 2013, at 3:19 AM, Geert Janssens janssens-ge...@telenet.be wrote: On 07-02-13 02:37, John Ralls wrote: You could use short commit numbers both for the subject line and the URLs e.g., https://github.com/Gnucash/gnucash-docs/commit/8686314 works just fine, which will make it a bit more readable. The preamble is way too long. The subject line says what the mail is about: Repo, branch, short changeset hash. The preamble can just be the changeset URL, again with the short hash. No need for the parent, there's a link to it on the Github change page. Then the log entry, and for patch-mail, the patch. Regards, John Ralls Thanks for the feedback. I have updated the mail script is several ways as a result: - use short commit hash in the subject line (and put it up front, just like the svn revision number was) - use short commit hashes in all urls - dropped the preamble text and some intermediary text - there are situations where a more complex push exists (non-fast-forwardable pushes which obscure some commits). In that case some additional explanation is added to the mail on what happened. I did not remove that. - I also haven't removed the parent. It may be helpful in some situations and in my personal opinion doesn't add that much clutter. Attached is a new example. Only one this time, because the only difference between the two mails is the amount of detail in the log section, which I haven't changed. Of note still is that the mail is sent by GIT SVN Migration user (git-svn). This is because the mail generation is triggered by the the svn-git push, which is currently always performed by the user account git-svn. With the scripts as they are now, the sending user will be set to the one actually pushing once svn is out of the loop. So if I push directly to a repo in gitolite, the mail will appear to come from me. I can't work around this in the current situation. One more niggling comment: The branch, trunk has been updated is poor English. Single commas are for separating dependent clauses. You could write The branch, trunk, has been updated, but that puts the emphasis on branch and makes trunk a parenthetical. Better would be no comma: The branch trunk has been updated, but I like The trunk branch has been updated. I have used your last proposal (the trunk branch has...). See new attachment. Looks fine to me. I don't have a problem with the email being from the committer. All of our mailing lists work that way. I have no problem with that either. My note was not really clear on the issue I had: the svn based mails are sent from the real committer's id (if you commit the mail will be from jralls, if I commit it will be from gjanssens and so on). My intention was/is to copy this behaviour for the mails sent from git. This however doesn't work out currently because all commits to git are done by the git-svn user (on behalf of the real committer). So all git mails will appear to come from git-svn. I mentioned this because it is different from the svn behaviour. 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Fw: Re: Proposed change to development Process was Fw: [Bug 650598] Cannot Enter Nth Day of Month Scheduled Transactions
After looking at the status choices, how about creating a bogus person named something like BugReleaseAgent to assign the bug report to when the code is written, then leaving it in his hands until it reaches the actual program release? Just a suggestion. --- On Thu, 2/7/13, David Carlson carlson...@sbcglobal.net wrote: From: David Carlson carlson...@sbcglobal.net Subject: Fw: Re: Proposed change to development Process was Fw: [Bug 650598] Cannot Enter Nth Day of Month Scheduled Transactions To: gnucash-devel gnucash-devel@gnucash.org Date: Thursday, February 7, 2013, 9:41 AM Then is there some other way to show the bug unresolved (because it has not been released) but the code is in the queue? David C --- On Thu, 2/7/13, John Ralls jra...@ceridwen.us wrote: From: John Ralls jra...@ceridwen.us Subject: Re: Proposed change to development Process was Fw: [Bug 650598] Cannot Enter Nth Day of Month Scheduled Transactions To: David Carlson carlson...@sbcglobal.net Cc: gnucash-devel gnucash-devel@gnucash.org, david.carlson@gmail.com Date: Thursday, February 7, 2013, 9:35 AM On Feb 7, 2013, at 7:21 AM, David Carlson carlson...@sbcglobal.net wrote: As I requested in this closed bug, which is not in the current program release and may not be in the current release for many more months, how about adding a status Awaiting next Program Release so the bug can be found in a search for unresolved bugs? This should reduce duplicate bug reports. It might, but we don't control bugzilla, gnome.org's Bug Squad [1] does. We don't have the privs to modify the workflow. Regards, John Ralls [1] https://live.gnome.org/Bugsquad/ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Fw: Re: Proposed change to development Process was Fw: [Bug 650598] Cannot Enter Nth Day of Month Scheduled Transactions
On 7 February 2013 15:41, David Carlson carlson...@sbcglobal.net wrote: Then is there some other way to show the bug unresolved (because it has not been released) but the code is in the queue? Could one use a Status of Resolved to mean that the fix has been committed but not yet released, and then close the bug when it is released? Colin David C --- On Thu, 2/7/13, John Ralls jra...@ceridwen.us wrote: From: John Ralls jra...@ceridwen.us Subject: Re: Proposed change to development Process was Fw: [Bug 650598] Cannot Enter Nth Day of Month Scheduled Transactions To: David Carlson carlson...@sbcglobal.net Cc: gnucash-devel gnucash-devel@gnucash.org, david.carlson@gmail.com Date: Thursday, February 7, 2013, 9:35 AM On Feb 7, 2013, at 7:21 AM, David Carlson carlson...@sbcglobal.net wrote: As I requested in this closed bug, which is not in the current program release and may not be in the current release for many more months, how about adding a status Awaiting next Program Release so the bug can be found in a search for unresolved bugs? This should reduce duplicate bug reports. It might, but we don't control bugzilla, gnome.org's Bug Squad [1] does. We don't have the privs to modify the workflow. Regards, John Ralls [1] https://live.gnome.org/Bugsquad/ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Fw: Re: Fw: Re: Proposed change to development Process was Fw: [Bug 650598] Cannot Enter Nth Day of Month Scheduled Transactions
One would think so, but the search for open bugs does not show resolved bugs that are not closed. David C --- On Thu, 2/7/13, Colin Law clan...@googlemail.com wrote: From: Colin Law clan...@googlemail.com Subject: Re: Fw: Re: Proposed change to development Process was Fw: [Bug 650598] Cannot Enter Nth Day of Month Scheduled Transactions To: David Carlson carlson...@sbcglobal.net Cc: gnucash-devel gnucash-devel@gnucash.org Date: Thursday, February 7, 2013, 10:12 AM On 7 February 2013 15:41, David Carlson carlson...@sbcglobal.net wrote: Then is there some other way to show the bug unresolved (because it has not been released) but the code is in the queue? Could one use a Status of Resolved to mean that the fix has been committed but not yet released, and then close the bug when it is released? Colin David C --- On Thu, 2/7/13, John Ralls jra...@ceridwen.us wrote: From: John Ralls jra...@ceridwen.us Subject: Re: Proposed change to development Process was Fw: [Bug 650598] Cannot Enter Nth Day of Month Scheduled Transactions To: David Carlson carlson...@sbcglobal.net Cc: gnucash-devel gnucash-devel@gnucash.org, david.carlson@gmail.com Date: Thursday, February 7, 2013, 9:35 AM On Feb 7, 2013, at 7:21 AM, David Carlson carlson...@sbcglobal.net wrote: As I requested in this closed bug, which is not in the current program release and may not be in the current release for many more months, how about adding a status Awaiting next Program Release so the bug can be found in a search for unresolved bugs? This should reduce duplicate bug reports. It might, but we don't control bugzilla, gnome.org's Bug Squad [1] does. We don't have the privs to modify the workflow. Regards, John Ralls [1] https://live.gnome.org/Bugsquad/ ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Notification mails for git repos - resend
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. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Notification mails for git repos - resend
Geert Janssens janssens-ge...@telenet.be writes: Of note still is that the mail is sent by GIT SVN Migration user (git-svn). This is because the mail generation is triggered by the the svn-git push, which is currently always performed by the user account git-svn. With the scripts as they are now, the sending user will be set to the one actually pushing once svn is out of the loop. So if I push directly to a repo in gitolite, the mail will appear to come from me. I can't work around this in the current situation. [snip] I don't have a problem with the email being from the committer. All of our mailing lists work that way. I have no problem with that either. My note was not really clear on the issue I had: the svn based mails are sent from the real committer's id (if you commit the mail will be from jralls, if I commit it will be from gjanssens and so on). My intention was/is to copy this behaviour for the mails sent from git. This however doesn't work out currently because all commits to git are done by the git-svn user (on behalf of the real committer). So all git mails will appear to come from git-svn. I mentioned this because it is different from the svn behaviour. Either way, this is only a transient issue: once svn is out of the loop the real committers will be seen in the mail's From field. So I don't intend to change anything in that area anymore. The way I see it, there's no need to turn on git mail handling for a particular repository until we turn off svn for that repository. So in the end the lists will never receive email from git-svn, because I feel gitolite shouldn't send it out until we're doing commits directly. I like that mail is sent using the correct from address. Did you test that that works correctly? -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.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Notification mails for git repos - resend
Geert Janssens janssens-ge...@telenet.be writes: 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 :) I'd rather the emails still come from svn so it has the correct from address. Flipping the switch on gitolite when we flip the switch on SVN shouldn't be a big deal. -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.eduPGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Notification mails for git repos - resend
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. 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. 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. I was thinking that it's probably time to start the release process for 2.6, but I'll raise that as a separate thread. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Gnucash 2.5/6
Geert mentioned in the Notification Emails thread that he'd like to get 2.6 released in less than a year, and Christian was pushing to do so this time *last* year. On the principle that Release is a misnomer. Software is never released, it escapes. [1], it's probably time to release 2.5.0 so that we can at least start down that road. Shall we say feature freeze now, string freeze in July, 2.6 release 1 November? Or is anyone actively working on features that should go in? What became of the rewrite of the register to GtkTreeView? Failing that, has anyone taken a shot at rewriting it with Cairo instead of libgnome? Note that I'm not proposing a Gtk3 migration for 2.6: We're doing that at Gramps, and MSWin is proving to be troublesome. In fact, it appears that no one is supporting Gtk3-MSWin at the moment. Regards, John Ralls [1] I don't know where that originated. My wife brought it with her from DEC, where it was apparently a truism. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
