GNU Astronomy Utilities - Tasks: task #14289, Adding bug/task fixed/completed...
You are not allowed to post comments on this tracker with your current authentication level.
task #14289: Adding bug/task fixed/completed when merging with master
Submitter: | Mohammad Akhlaghi <makhlaghi> | ||
Submitted: | Mon 26 Dec 2016 03:09:27 PM UTC | ||
Should Start On: | Sun 25 Dec 2016 03:00:00 PM UTC | Should be Finished on: | Sun 25 Dec 2016 03:00:00 PM UTC |
Category: | Development | Priority: | 5 - Normal |
Item Group: | Enhancement | Status: | Need Info |
Privacy: | Public | Assigned to: | makhlaghi |
Percent Complete: | 0% | Open/Closed: | Open |
Effort: | 0.00 |
Tue 27 Dec 2016 12:01:03 AM UTC, comment #2: |
Mohammad Akhlaghi <makhlaghi> |
Mon 26 Dec 2016 04:26:08 PM UTC, comment #1: I think that for v0.3, the current commit guideline should be
|
Boud Roukema <boud> |
Mon 26 Dec 2016 03:09:27 PM UTC, original submission:
In the current Commit guidelines, we have asked for commiters to include a statement at the the end of the commit message saying ‘This fixes bug #ID.’, or ‘This finishes task #ID.’.
|
Mohammad Akhlaghi <makhlaghi> |
No files currently attached
Depends on the following items: None found
Items that depend on this one: None found
There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.
Powered by Savane 3.13-f8d8.
Corresponding source code
Thanks, I completely agree with your argument. I just wanted to add that I am not proposing to force bug/task reports to have a solution. When we have just seen the bug and don't know the solution or don't have time to dig into it, we will indeed report any symptom we see and won't provide a solution.
What happens in practice for people who are familiar with the code is that they cannot be sure it is a bug unless they look into the code first and confirm it (it might be due to their inputs). During this code check, it sometimes happens that they find the solution during this confirmation. So they have to go through this double reporting phase (one report to define the bug before their commit, and another for the link after they push), which is inconvenient for the reporter and also, everyone on the mailing list (who recieves two mails).
Infact I came up with this suggestion after your commits that didn't include these statements. I noticed that I had also forgot to add these statements for you as an ammendment before pushing. It then occurred to me that a `git commit --amend' by the person who does the final merge to master is much more easier to manage (one less thing for the maintainer to worry about!). It also had the practical benefit to the submitter, that if they have a solution, they can also share their branch link with the same initial report.
Having the person in charge or merging with master add the `This finishes task #XXXX.' or `This fixes bug #XXX' can also act as a kind of stamp for double check on the final commit that gets merged. Infact I hope that in the future, even when the main maintainer has a branch to merge with master, they don't do it themselves, and other developers would have to check the work, sign it off with this statement, and then merge with master.
The cases of your last two commits are interesting examples: please compare the `author' and `committer' in the typo commit and the genauthors commit. It would be great if all commits that get merged into master have different names in these fields (even those by the main maintainer).