Lucas Nussbaum wrote: > Let's take bug #209008 (debian-policy: [PROPOSAL] common interface for > parallel building in DEB_BUILD_OPTIONS) as an example. There are already > 50 mails in that bug report, split in 5 threads. If you want to know the > status of this pseudo-DEP, you basically have to read them all. So FWIW, this is a limitation of the BTS, that it would be valuable to fix in the BTS. I sometimes find myself retitling a bug report to summarize the outcome of a particularly long discussion in it. Such summaries tend to make poor titles though, since they're often many lines long. I sometimes see a bug report that starts out being about many issues, and ends up being only about one simple change (such as #452640), but if you're not careful, you'll have to read the whole bug log to figure that out. In these sort of cases, and the case of storing something like a DEP in the BTS, you want a field that's like the title in that it can be changed and appears near the top of the bug page, and that's like the body of a message sent to the bts, in that it can contain arbitrary freeform text, links, etc. If we called this field a summary, one interface to use it could be to mail nnnn-summary@bugs.debian.org to set a new summary. This would add the message to the detailed bug log, so that old historical summaries would be available, and the newest summary would be displayed at the top of the bug report. It would probably also be useful to have a way to get a bug report's newest summary out of the bts and into $EDITOR so minor modifications can easily be made and sent back to the bts. FWIW, while I of course like that the DEP system is using ikiwiki, I've so far found aj's arguments about using the BTS instead more convincing. -- see shy jo
Attachment:
signature.asc
Description: Digital signature