On Mon, 19 May 2008, Stefano Zacchiroli wrote: > How I'm reading the latter paragraph is that patch messages are > *alternative* as some non-patch summary message, am I wrong? I think > the two should be orthogonal: you can have or not a summary message, > you can have or not a patch.
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 completely decided how this should be implemented, though. > 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 > patches? (e.g. forcing an attachment if one wants to add +patch or > something similar). This + the forthcoming ability above to identify > *the* latest patch will give us the ability to automatically extract > patches from bug reports. 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. Don Armstrong -- <Clint> why the hell does kernel-source-2.6.3 depend on xfree86-common? <infinity> It... Doesn't? <Clint> good point http://www.donarmstrong.com http://rzlab.ucr.edu -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
