Re: Why Is There No Bug Tracker And Why Are Patches Sent Instead Of Pull Requests

[Neal Kreitzinger <nkreitzinger@gmail.com>]

On 3/1/2012 10:19 PM, Jonathan Nieder wrote:
>
> That said, a good distributed bugtracker (which implies solving hard
> social problems like "what to do if different contributors disagree on
> severity"
How do you solve that now?  You can have a field in the bug-report.txt 
for "severity" or a severity-file in the commit.  If people keep 
changing it and don't listen to the appointed tie-breaker then those 
people's patches probably aren't going to get applied anyway.

>   and simple technical problems like "how to present a
> coherent conversation based on threads by people who might not have
> been aware of each other") would be a very nice thing to see,
> regardless of the choice of storage and network protocol used to back
> it.
You can have a field in bug-report.txt called "discussion thread" or a 
file called discussion-thread.txt that contains the link to the mailing 
list for that thread (even terminal emulators automatically bring up 
links when you click on them).  People would have discussions there like 
they do now.  Real progress updates would be recorded in git.  
Discussions would remain on the mailing list.  Thread posts could also 
be recorded as git-notes.

Please let me know what else is a "hard social problem".  I'm not a 
bug-tracker expert but I've used a few bug-tracking systems and worked 
plenty of bugs though never on an opensource project so maybe I'm not 
aware of the "hard social problems".

That being said, I was in a position where I fixed on average over one 
bug per day (reported, fixed, tested, moved to production) for a total 
of 2,000+ bugfixes over about 6 years.  The most in one day was about 
eight (1 per hour).  It was a home-grown bugtracking system based on 
lotus-notes (ie, email integration).  Git has send-mail and the mailing 
list.  The workflow was:

(1) User submits bug-report (or enhancement-request).  Status = 
Unassigned,  Severity = whatever.
(2) Manager reviews bug-report and assigns to developer or rejects it.  
Status = Development or Rejected, Severity = whatever (manager might 
change it).
(3) Developer makes fix and marks ready for QA.  Status = QA.
(3.1)  during development Developer makes comments that are sent as 
emails and User reciprocates.
(4) User/tester tests fix and gives signoff.  Status = Move-to-Prod.
(4.1)  during testing the user/tester and developer make comments that 
are sent as emails.
(5) Developer promotes fix to production.  Status = Completed.
(6) Manager receives notice and acknowledges.  Status = Closed.

Here's how that might work with git:

(1) User (john.doe@nowhere.com) submits bug-report (or request).  Status 
= Unassigned,  Severity = whatever.
[BUG]  (starts the thread)

(2) Manager (git-maintainer) reviews bug-report and assigns to developer 
(or lieutenant) or rejects it.  Status = Development or Rejected, 
Severity = whatever.
[DEV] | [REJ]  (assigned to developer/lieutentant or rejected)

(3) Developer makes fix and marks ready for QA.  Status = QA.
(3.1)  during development Developer makes comments that are sent as 
emails and User reciprocates. (makes posts to thread on mailing list)
[QA]  (fix is in next)

(4) User/tester tests fix and gives signoff.  Status = Move-to-Prod.
(4.1)  during testing the user/tester and developer make comments that 
are sent as emails. (makes posts to thread on mailing list)
[PAS]  (fix passed testing)

(5) Developer promotes fix to production.  Status = Completed.
[CMP]  (fix is in rc)

(6) Manager (git-maintainer) receives notice.  Status = Closed.
[CLS]  (fix is in release)

I realize this is not an exact match of the git-workflow, but you get 
the idea.  I'm also new to mailinglists so I'm not sure if you can 
change part of the subject line.  If not, a header in the body could 
possibly be used.

Thank you for your time and consideration.

v/r,
neal