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@xxxxxxxxxxx) 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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html