This is my attempt at a debgtd roadmap.
debgtd development takes place in the git repository, with the master branch being the "main" code. Particularly iffy developments take place in branches with the intention of merging them when they are stable enough.
Periodically I tagged the state of the master branch and called that a release.
1.x
Initial development (and all development so far) has taken place with version numbers 1.x, with an incrementing x.
1.2 branch
1.2 was the latest version at the time that Debian began the "freeze" process for the release of Lenny. I needed to make some last-minute package changes prior to the freeze, but mainline development was significantly different to the 1.2 version that I didn't want to upload that; so instead, I created the 1.2 branch (and version 1.2.1 as the first tag from this branch).
Any major patches that are needed against 1.2.1 in Debian will be on this branch.
2.0
This will be the version number when the first round of plans for debgtd are complete.
milestones for 2.0. are:
- The triage window being "complete"
- need to define what "complete" means
- sleeping bugs wake up after a certain timeout
- sleeping bugs wake up after certain activity
- define what activity
- users can define more advanced criteria for what
future developments
These need to take place on the 2.0 branch but are not prerequisites for 2.0.:
- basic workflow (e.g. proposed next action: upstream or not? architecture dependent or not (or can't tell)?)
- more intelligent "next action" handling (not just a dumb string)
- NMU workflow (including the agreed timeout periods for contacting the maintainer, etc.)
- look at python-debbts to clean up SOAP code http://packages.qa.debian.org/p/python-debianbts.html