[On a process note, we're off-topic for the current bug, but I generally prefer to keep messages archived rather than not. Please let me know if I should take this interesting discussion somewhere else.]
On Wed, 2009-08-05 at 11:41 -0700, Don Armstrong wrote:
> control is a superset of request which has operations which modify
> bugs.
Yes, I understand that. But that's an implementation issue, and I think
it's generally a mistake to force users to think about the
implementation in order to be able to use the interface correctly.
> submit is for sending mail to a bug.
And yes, I understand that that's the distinction there. But perhaps I
didn't explain my point very well. Let me try again.
When I submit a new bug (by mailing submit@), I can add a tag to it with
a pseudo-header that looks like this:
Tags: patch
Then, if I have new information to add to the bug I can mail <bug-id>@,
(and here it's obvious enough why a different email address is used).
But now I can't use that same "Tags: patch" pseudo-header like I could
when sending to sub...@. That's what I'd like to be able to do. Instead,
I have to send mail to an additional address (control@) and use an
entirely different syntax:
tags bugid patch
thanks
> That's really all that there is to it. The main reason that they're
> separate is historical reasons, and because you have to have some
> method of disambiguating between "a mail to a bug" and "a message
> which alters a bug" (or the parts of a message that do that.)
I imagine that most of this is historical reasons, yes. But all of the
interfaces, (submit@, <bugid>@, control@) are ways of frobbing the bug
database. And the fact that request@ does read-only things with the bug
database, isn't (in my opinion), a good reason for a separate interface.
Anyway, I've now convinced myself what I want, (which is pseudo-header
support in <bugid>@ in the same syntax that submit@ accepts). I'll open
a new bug report for that, and perhaps look into what the implementation
would actually consist of.
> See my most recent Debconf talk (when it becomes available, or the
> slides for it right now) for some more information about why this is
> the case.
Thanks for the reference. I'll go poke around.
-Carl
signature.asc
Description: This is a digitally signed message part
