[PATCH 1/5] Add log_msg field

[Nate Case]

On Thu, 2009-03-19 at 16:22 -0400, Don Zickus wrote:
> Eww. yuck.  I personally believed that patchworks should not only keep
> all the comments posted to a mailing list but keep them as read only.
> And then use the Patch class as a workspace (using one of the Comments
> as a template).  This would allow maintainers to muck around with the
> patch as they see fit for their workflow, but still have the original
> thread if they need it.

Hi Don,

I don't see much value in keeping a separate read-only copy of the
original patch submission.  If maintainers really wanted to "muck
around" with the patch object, then I doubt they would care about the
original patch not being stored in a comment object.  It's not
patchwork's job to function as a pristine backup for the mailing list
(we have mailing list archives for that).

You mention that you want the ability for maintainers to muck around
with the patch as they see fit.  However, without a log_msg field in the
Patch class there is no way to modify the log message of the original
patch submission in the database without violating your "read-only
comment 0" argument.  We should still have log_msg in the patch object.

> Destroying Comment 0 now creates two types of data in patchworks,
> replies and patches.

I'm not sure what you mean here.  Don't we have three types of data
involved as it stands?  Patches, replies, and copies of the patch
submission message (comment 0)?

> What happens when patchwork accidentally labels a reply with
> a patch snippet as a Patch?  How do you take that Patch turn it into a
> Comment and link it to the appropriate Patch?  It gets kinda messy.

True, but if this turns out to be a common occurrence then we should 1)
Improve patchwork's detection, and 2) Implement a real merge/re-attach
feature to handle such a case automatically.  It's not hard in Python to
copy the handful of fields to create a new comment object based on the
patch object.

My main gripes with the current method are:

1) It's inconsistent to have fields in the Patch class for msgid, name,
date, mail headers, and patch content, but NOT the log message.

2) If you want to get the log message for a patch, you have to lookup
and parse the content field of a comment object.  While this isn't too
difficult, it shouldn't have to be this way.

3) The log message / patch description is inherently part of the patch
object as much as the patch author is.

As for destroying comment 0: I could live with keeping it around if
people really thought it were valuable.  I just don't see the point in
doing so when it has the same data as the patch 99% of the time.

--
Nate Case <ncase at xes-inc.com>