On Tue, May 20, 2008 at 09:02:21AM +0100, Don Armstrong wrote:
> The idea was that a patch, since it would actually contain the
> resolution of the original problem, would be the correct place to
> summarize the problem. However, on thinking about it more, I think
> that having a single summary, with a set of patches and possibly
> attachments located near the summary is the way to go. I haven't
Fair enough, but why are you referring to a _set_ of patches? For the
sake of simplicity assuming that a bug has a single patch sounds like a
fair assumption to me. Of course the patch can patch multiple files and
of course and can be obtained only after a round of repeated
submissions, but in the end: one bug, one patch. If you agree on this I
think the BTS interface should exploit the principle: at most one
"current" patch, as it will have at most one "current" summary.
> > But still this does not solve another problem we have with patch
> > management in the BTS: they are sometimes inlined, while sometimes
> > the are attached. Can't we fix attachment as the required format for
> This is an unecessary restriction, as not all patches need necessarily
> be diff files. Making it easy to extract extractable patches should be
> good enough; those that can't will just have to refer to a message.
What other kind of patches, beside diffs, are you referring to? Stuff
like prose explanation on how to fix a problem, binary blobs, or what
else? I tend to believe that diffs are the only things we are usually
interested in pushing upstream, but not knowing the other kind of
patches you have in mind I can't be sure.
Anyhow, even if you make the distinction between extractable and
non-extractable patches, I think diff should be extractable, and
allowing them to be inlined is a PITA. Maybe this can be overcomed at
an API implementation level, with some logics to recognize inlined diffs
in messages tagged +patch which are missing attachments? It starts
looking complicate though ...
Cheers.
--
Stefano Zacchiroli -*- PhD in Computer Science ............... now what?
zack@{upsilon.cc,cs.unibo.it,debian.org} -<%>- http://upsilon.cc/zack/
(15:56:48) Zack: e la demo dema ? /\ All one has to do is hit the
(15:57:15) Bac: no, la demo scema \/ right keys at the right time
Attachment:
signature.asc
Description: Digital signature