[PATCH 1/5] Add log_msg field

[Don Zickus]

On Mon, Mar 23, 2009 at 10:09:03AM +1100, Jeremy Kerr wrote:
> Hi Nate,
> 
> > Create a new patch field named 'log_msg' which contains the patch
> > commit log message.  Previously this was stored as the first comment
> > of the patch.  Storing it explicitly gets rid of the special case
> > handling for comment 0 and eliminates the redundant metadata between
> > comment 0 and the patch object.  It also has the nice side effect of
> > making the number of comments accurately reflect how many replies
> > were made to the patch.
> 
> Since this change involves a *lot* of changes to existing patchwork 
> installations, I'm reluctant to accept it without a really good reason 
> for the change. Between ozlabs.org and kernel.org, we have around 50,000 
> patch objects that would need to be updated due to this schema change.
> 
> As you say, on one hand we don't need the special case for generating 
> the mbox data, but now we do need special case for the log_msg field in 
> the patch template (in which case we need to fake it up as a comment).
> 
> However, if there *is* a compelling reason to do so, I'm happy to merge 
> this, you just need to convince me first :)

I guess it depends on where you want this project to go.  How did you want
the Comment and Patch objects treated?  Is a Patch object a unique comment
such that Comment objects really are only replies to the patch?  Or is
Comment objects the main object with a Patch object just wrapping around a
Comment object?

>From my selfish POV :-), I would like to see all emails to a mailing list
encapsulated in a Comment object and then anything that fits the criteria
of a 'patch', be copied of to a Patch object.  But that would entail not
only adding a 'log_msg' field to the Patch object, but also a
'patch_content' field to the Comment object.

This would allow me to use the Patch object as a workspace for soaking any
patches I have to deal with because unlike a lot of the upstream
maintainers, I can not just stream line patches into my git tree.  As a
result, I might update the subject line, or clean up the body or refresh
the patch (to integrate better with other patches), or add other little
meta-tags (besides Acked-by, Tested-by, etc).  All this would be done in
parallel while I soak the patch and wait for developer feedback.

Now I can probably do most of this today without adding new fields, but I
also wanted to handle cases like 'reposts', where I can link the comments
of the original patch to the new patch just by changing where the patch_id
points to.  But by doing this I lose the original patch (hence the need
for the 'patch_msg' in the Comment object).  On the flip side, if I wanted
to clean up the body of the patch description, I would have to do that in
the Comment object and thus lose what the original patch description was
(hence the need for a 'log_msg' in the Patch object).

Of course, both of the examples above rely on the fact that I like to
download a patch and review all the developers feedback on it.  Because I
have to soak patches, my queue grows to a couple hundred patches and I
easily forget where I stand on all the patches, which is why I like to
review the developers feedback.

But then again, this is how my workflow is done and the changes descibed
above are the little tweaks that would let me use patchworks right out the
box.

I think the changes allow greater flexibility to handle all the various
maintainers style and workflow and allows others to push patchworks in fun
and interesting directions.  At the same time the changes don't really
impact the way it works today (the changes just create more duplicate
data).

However, this is your project and it is really up to you about what your
philosophy about the project is and where you want to steer it.  :-)

Cheers,
Don