gnuastro-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gnuastro-devel] [task #14289] Adding bug/task fixed/completed when merg


From: Boud Roukema
Subject: [gnuastro-devel] [task #14289] Adding bug/task fixed/completed when merging with master
Date: Mon, 26 Dec 2016 16:26:08 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Firefox/45.0

Follow-up Comment #1, task #14289 (project gnuastro):

I think that for v0.3, the current commit guideline should be
retained, but possibly reworded and augmented with an exception made
for minor bugs whose fixes really seem trivial, and in that case the
master maintainer on savannah can add the bug number using _git commit
--amend_ prior to pushing up to savannah. I admit that I violated
(unintentionally :) this guideline, but I think that separating the
bug report from a proposed fix (and doing the bug report first) is
justified by what is described in a well-known essay by Simon Tatham:

http://www.chiark.greenend.org.uk/~sgtatham/bugs.html

> Some of the worst bug reports I've ever seen come from programmers,
> and even from good programmers. ...

> Providing your own diagnosis might be helpful sometimes, but always
> state the symptoms. The diagnosis is an optional extra, and not an
> alternative to giving the symptoms. Equally, sending a modification
> to the code to fix the problem is a useful addition to a bug report
> but not an adequate substitute for one.

Given that commits are to be made on side branches, (so far) not on
savannah, it seems to me that the idea is that a bug or task number is
needed _every_ time a commit is considered ready, i.e. a _pull
request_ is carried out by either a task or bug report. So the text
corresponding to

https://www.gnu.org/software/gnuastro/manual/html_node/Commit-guidelines.html

should probably be restructured to say this right from the beginning.
I think a link to Tatham's essay above could be used to point out
the usefulness of separating bug reports from their proposed fixes,
even when we we're sure we've solved the bug. The reality is that
someone else will see things somewhat differently from the person
proposing the bug+fix.






    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/task/?14289>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]