[PATCH 1/5] Add log_msg field

[Don Zickus]

On Fri, Mar 20, 2009 at 10:39:55AM -0500, Nate Case wrote:
> 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).

Hi Nate,

Actually I would disagree.  I just thought if you were going to track
patches you have to track discussions and replies too, so in the end you
wind up being a mail archiver.

Now you are right, people could go find a mailing list archive to dig up
replies, but that's not very efficient. Wouldn't it be cooler if you could
have all the info you need to make a decision at your fingertips :-)

> 
> 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.

Sorry I jumped the gun on my original comment.  I should have stuck in
there that yes I agree 100% that a log_msg type structure should go into
the patch object.  I just didn't want to lose comment 0 in the process.

In my head, I just envisioned all the emails coming into the database as
comment objects.  Any comment object that has a patch (or is starting a
new thread) would also copy its data and start a new Patch object.  The
patch object could be then be modified to a maintainers content while the
comment objects would record the history and comments of that patch, sort
of like a version control I guess.

Some maintainers just grab the patch, make the modifications and commit to
git.  Some maintainers like to soak a patch for awhile and save the
modifications to patchworks.  The workflow I described above would handle
both scenarios.

> 
> > 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)?

Like Aris said and as described above.

> 
> > 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.

Or in my scenario above: archive the patch and point the comment patch_id
to the appropriate patch, done.  simple!  :-)

> 
> 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.

I agree. 

> 
> 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.

I agree.

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

I agree.

> 
> 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.

I think its valuable.  But that is just me.  Besides we store the info in
a database.  Databases are designed to store useless redundant data that
noone will ever need again. :-)

Cheers,
Don