[PATCH 1/5] Add log_msg field
dzickus at redhat.com
Sat Mar 21 04:55:08 EST 2009
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).
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
> > 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.
> 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.
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. :-)
More information about the Patchwork