https://github.com/jmtd/debgtd

applying "Getting Things Done" principles to Debian bug triaging
https://github.com/jmtd/debgtd

Last synced: 23 days ago
JSON representation

applying "Getting Things Done" principles to Debian bug triaging

• Host: GitHub
• URL: https://github.com/jmtd/debgtd
• Owner: jmtd
• License: gpl-2.0
• Created: 2009-04-26T15:10:57.000Z (over 15 years ago)
• Default Branch: main
• Last Pushed: 2021-01-26T12:01:20.000Z (almost 4 years ago)
• Last Synced: 2023-04-15T22:07:01.559Z (over 1 year ago)
• Language: Python
• Homepage: http://jmtd.net/computing/software/debgtd/
• Size: 223 KB
• Stars: 4
• Watchers: 3
• Forks: 0
• Open Issues: 1
• Metadata Files:
  • Readme: README
  • License: LICENSE

Awesome Lists containing this project

README

        
debgtd

'debgtd' is a program that is design to help a user manage bugs that they are

working on.

Rationale: I try and track bugs in packages in Debian. I used to do this

purely by which I have submitted. This was not ideal, because

 * sometimes I am interested in a bug I did not submit

   * bugs against packages I maintain

   * bugs that I am suffering but didn't file first

   * bugs against packages I am otherwise interested in

 * I am not interested in all bugs that I have submitted

   * Some programs I no longer use

Once my list of open bugs hit about 100, I could no longer reliably track

which needed my attention and which did not. I therefore wrote debgtd.

The intention is to let you track an arbitrary set of bugs. At the moment, it

only imports those reported by you or against packages you are listed as a

maintainer for.

The intention is to let you selectively mark some of those bugs as to be

ignored. It does this.

You can also "sleep" a bug. We do this if a bug does not need our attention

right now, but will do in the future. This behaves the same as ignoring, for

now.

When should a bug wake up?

Either after some activity has taken place, or a given timeout.

What activities should count?

At the moment, nothing is woken up.

Other workflow

--------------

I want the tool to capture bug workflows and make it easier to track where

you are with them, e.g. the NMU workflow:

NMU procedural information:

http://www.debian.org/doc/developers-reference/ch-pkgs.en.html#s-nmu

    * file the bug

    * wait "a few days" for a response

    * submit a patch

    * wait "a few more days"

    * announce nmu intention

    * prepare nmu

    * upload to delayed queue

    * send final patch to bts, explain 7 day reaction

annotations

-----------

looking at my bug pile right now, I see some bugs that could use some

attention, perhaps to see if they still apply, etc.: I cant' do the actual

work now, but I could do with making a note of the identified "next action"

reporting bugs against debgtd

-----------------------------

To report a bug against a version of debgtd packaged as part of Debian,

please submit a bug to the Debian bug tracking system (BTS). See

http://www.debian.org/Bugs for more information, or use reportbug(1).

Bugs against non-packaged versions of Debian are kept as separate files

within the "bugs" directory of the source. Either submit a patch adding a

file describing your bug, or simply write an email describing it, both to

[email protected].