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? [EMAIL PROTECTED],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
signature.asc
Description: Digital signature
