[PATCH] Add a source_tree field to Project.

[Dirk Wallenstein]

On Fri, Apr 01, 2011 at 10:34:23AM +0200, Dirk Wallenstein wrote:
> On Thu, Mar 31, 2011 at 06:32:33PM -0300, Guilherme Salgado wrote:
> > On Wed, 2011-03-30 at 18:25 -0300, Guilherme Salgado wrote:
> > > On Wed, 2011-03-30 at 12:10 +0800, Jeremy Kerr wrote:
> > > > Hi Guilherme,
> > > > 
> > > > >  apps/patchwork/models.py                      |    1 +
> > > > >  lib/sql/migration/008-project-source-tree.sql |    3 +++
> > > > >  2 files changed, 4 insertions(+), 0 deletions(-)
> > > > >  create mode 100644 lib/sql/migration/008-project-source-tree.sql
> > > > 
> > > > Looks good. I'd like to wait until there is a user of this field before 
> > > > merging the change though - or are you using this for linaro-internal things?
> > > 
> > > I'm using it on a script I'm writing to fetch the git history of every
> > > project and scan that looking for patches that have been committed. Just
> > > like the existing patchwork-update-commits script does but this one is
> > > fully automated, and to make it more easily testable I'm experimenting
> > > with python-dulwich to scan the git history. 
> > 
> > So, although I could do most things using python-dulwich it was failing
> > in some cases and I just don't have the time to chase down these
> > failures and fix them, so I resorted to running git on a subprocess. I'm
> > still writing the script in python as that allows me to have at least
> > some test coverage, which is something very valuable to me.
> > 
> > This new version of the script works similarly to the previous version.
> > There are a few things that need to be changed but it has some tests and
> > is able to scan the qemu tree and update the status of a couple patches.
> > Also note that it updates the commit_ref of a patch, which will allow us
> > to generate a link to the project's gitweb once we have the commit_url
> > field.
> > 
> > I'd appreciate some feedback on this; specially whether or not this is
> > something that's going to be useful upstream and, if so, if the current
> > approach is reasonable.
> 
> I think something like that would be really really useful.
> 
> I was wondering about a way to include patches that were slightly
> modified when they were applied.  The author, author date, and subject
> do not change in most cases (ok, maybe the subject is extended at the
> start to add a section, and maybe space and case changes). 
> 
> I think if author and author date match, and if a case insensitive
> space-less version of the mail-subject is contained in the
> commit-subject it is the corresponding commit.

Too bad that the author-date does not match when authors set up a branch
to be pulled.  But at least this could work for the occasional
contributor who might not have a patchwork account.

Theoretically, it might be possible to solely base that determination on
author and subject if the chain of superseding patches is recorded.
That could also rely on author and subject triggered by the common
(AFAIK) v1,v2,...,vn tokens in the patch sign.  Such chains could link
mail threads together and form topics.  Maybe assemble lists for cases
in which these computations failed and optionally send an email back.  I
think, that for a lot of cases relying on the uniqueness and
monotonicity of subjects could work.  Maybe add support for an X-Header
"X-Patchwork-Previous-Subject" for the cases when it changes.

Linking threads into topics would be really nice, I think.  It would be
possible to bookmark topics and see if there have been changes to a
topic -- something that is not immediately visible in a mail client.

Just musings and I would love to hear about cases where this would not
work most of the time (given there is a "v#" token policy).

-- 
Cheers,
  Dirk