[Gramps-devel] Change to committing policy

[Nick Hall]

Devs,

I have now got the Mantis bug tracker GitHub source integration working.

To use this we need to make a slight change to our commit messages.

The first line should contain a short summary of the change (70
characters or less), but it should no longer contain a reference to a
bug report.

This should be separated by a blank line from a longer description, if
required.

Finally, also separated by a blank line, you need to put special
keywords which either link to, or resolve, bug reports.

To resolve a bug or bugs use:

Fixes #12345
Fixed #12345
Resolves #12345
Resolved #12345
Fixes #12345, #67890
Fixed #12345, #67890
Resolves #12345, #67890
Resolved #12345, #67890

To link to a bug or bugs use:

Bug #12345
Issue #12345
Report #12345
Bugs #12345, #67890
Issues #12345, #67890
Reports #12345, #67890

You will also need Mantis to recognise your git commit. To do this either:

1. Set your Mantis real name to your git name.
2. Set your Mantis email to your git email.

If your Mantis user name is the same as your git name, I think you may
also be recognised.

Let me know if you have any problems.

Regards,


Nick.

[Paul Franklin]

I somewhat dislike 8128 being closed, just because yet
another transient parent problem was fixed.

I had thought the purpose of that bug was to mention each
such problem which was noticed, so it could be fixed, even
if not instantly.

(And while I haven't reread the long list of comments, I
wouldn't be surprised to see ones mentioned there which
haven't yet been fixed.)

Does this new system allow for partial fixes, or ongoing
patches, or something similar?

Or is it maybe just as simple as altering your new rules
slightly, to allow something more general ("this fixes part
of 8128, a blanket tracker bug" or something, for the second
line)?

[Josip]

Post by Paul Franklin
I somewhat dislike 8128 being closed, just because yet
another transient parent problem was fixed.
I had thought the purpose of that bug was to mention each
such problem which was noticed, so it could be fixed, even
if not instantly.
(And while I haven't reread the long list of comments, I
wouldn't be surprised to see ones mentioned there which
haven't yet been fixed.)
Does this new system allow for partial fixes, or ongoing
patches, or something similar?
Or is it maybe just as simple as altering your new rules
slightly, to allow something more general ("this fixes part
of 8128, a blanket tracker bug" or something, for the second
line)?

For that we should use "Issue #12345" instead off "Fixes #12345" and
change-set will be appended to issue-ticket which will still remain open.

[Nick Hall]

Post by Paul Franklin
Does this new system allow for partial fixes, or ongoing
patches, or something similar?

Yes. For partial fixes, just use "Bug #12345" instead of "Fixes #12345".

PR 417 clearly stated it was a fix in the title:

https://github.com/gramps-project/gramps/pull/417


Nick.

[Paul Culley]

The PR 417 title was inherited from the commit, which was trying to follow
your prior rules.

Next time I'll use the "Bug #8128" after a blank line.

We should probably reopen 8128, or at least be willing to if another
'transient parent' shows up.


Paul C.

Post by Nick Hall

Post by Paul Franklin
Does this new system allow for partial fixes, or ongoing
patches, or something similar?

Yes. For partial fixes, just use "Bug #12345" instead of "Fixes #12345".
https://github.com/gramps-project/gramps/pull/417
Nick.
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Gramps-devel mailing list
https://lists.sourceforge.net/lists/listinfo/gramps-devel

[Paul Franklin]

Post by Paul Culley
We should probably reopen 8128

I agree so I tried to reopen it.

After I'd clicked the "reopen" button it gave me the page
to assign it to somebody and then send them a comment.

When I tried that, both with no assignee and with me as
assignee, I then got an error message (application error
1103 IIRC) saying that 8128 was "read-only" -- so I suspect
that there's another teething problem which needs fixing.

[Josip]

Post by Paul Franklin

Post by Paul Culley
We should probably reopen 8128

I agree so I tried to reopen it.
After I'd clicked the "reopen" button it gave me the page
to assign it to somebody and then send them a comment.
When I tried that, both with no assignee and with me as
assignee, I then got an error message (application error
1103 IIRC) saying that 8128 was "read-only" -- so I suspect
that there's another teething problem which needs fixing.

I changed keyword in changeset and reopen ticket!

[Josip]

Post by Nick Hall
Devs,
I have now got the Mantis bug tracker GitHub source integration working.
To use this we need to make a slight change to our commit messages.
The first line should contain a short summary of the change (70
characters or less), but it should no longer contain a reference to a
bug report.
This should be separated by a blank line from a longer description, if
required.
Finally, also separated by a blank line, you need to put special
keywords which either link to, or resolve, bug reports.
Fixes #12345
Fixed #12345
Resolves #12345
Resolved #12345
Fixes #12345, #67890
Fixed #12345, #67890
Resolves #12345, #67890
Resolved #12345, #67890
Bug #12345
Issue #12345
Report #12345
Bugs #12345, #67890
Issues #12345, #67890
Reports #12345, #67890
1. Set your Mantis real name to your git name.
2. Set your Mantis email to your git email.
If your Mantis user name is the same as your git name, I think you may
also be recognised.
Let me know if you have any problems.

There are no dot "." at the end of keyword anymore?
Is that correct?
I like it more that way without dots.

What about dates?
Git usually works with committer date (GIT_COMMITTER_DATE) but displays
author date (GIT_AUTHOR_DATE), Mantis unfortunately seems to work with
author date and sorts Changesets by them.
Can Mantis be configured to sort changes by commiter date or we should
override author date on PR commit.