[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Using the BTS instead of a different system? (Was: RFC: Introducing Debian Enhancement Proposals (DEPs))

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

Reply to: