Re: divergence from upstream as a bug
On Tue, 20 May 2008, Stefano Zacchiroli wrote:
> 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?
There may just be one current patch, but having access to the previous
patches and/or attachments which describe the problem easily is
useful. Whether debbugs display just one or displays many is a trivial
decision once debbugs tracks them all.
> > 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?
Yes.
> 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 ...
I don't want to add in a set of restriction mechanisms to when a tag
can and cannot be placed. Making the automatic extraction work with
extractable patches and attachments and documenting this fact should
be enough to encourage their use without unecessarily restricting
flexibility and making the tagging fragile because of it.
Don Armstrong
--
Democracy is more dangerous than fire. Fire can't vote itself immune
to water.
-- Michael Z. Williamson
http://www.donarmstrong.com http://rzlab.ucr.edu
Reply to: