[PATCH 0/2] Atomicity & parsemail.sh

With the series support in production, I realized that postfix did not serialize the spawing of parsemail.sh. I couldn't find clear documentation about that specific case: serializing mail delivery to a mailbox is possible, not sure when postfix is piping the mail to a another process. Instead of

[PATCH 1/2] lock: Import file lock class from mercurial

With series now in production, I realized I needed the mail parsing to be atomic. Because of the race can happen between mutiple process a file lock seems like it could work. Signed-off-by: Damien Lespiau --- patchwork/lock.py| 301

[PATCH 13/14] series: New series with similar titles as previous ones are new revisions

There's another way than the one already implemented to update a series: resend another full thread with some of the patches changed. Because those two mail threads are separate, the only way is to try and match the subject of their cover letters. v2: Rebase on top of single patch update changes

[PATCH 12/14] series: Add a signal to notify when a revision is complete

To decouple some high level and rather complex parsing code from the models, let's add a signal when a SeriesRevision is complete. One can use that signal to hook some logic there, for instance from the mail parsing code. Signed-off-by: Damien Lespiau Acked-by: Stephen

[PATCH 02/14] parsemail: Make find_content() return a MailContent object

Returning tuples is not super scalable. I now want to return a Series object along with a patch or a comment. So let's put the return values into a class, used as a typed dictionary really. Signed-off-by: Damien Lespiau Acked-by: Stephen Finucane

[PATCH 01/14] parsemail: Return the list of prefixes when cleaning up the subject

The patch is a preparation step towards understanding series. It will be handy to parse those prefixes, looking for 'x/n' to retrieve the order of a patch in a series. Signed-off-by: Damien Lespiau Acked-by: Stephen Finucane ---

[PATCH 03/14] parsemail: Add a function to parse series markers eg. "1/12"

This can be used to identify cover letters, patches part of series, length of series, ... Signed-off-by: Damien Lespiau Acked-by: Stephen Finucane --- patchwork/bin/parsemail.py | 12

[PATCH 04/14] parsemail: Extract building the list of mail references

We'll need to figure out whether the mail we are parsing is the root of the thread to automatically build series, and we'll need the list of references for that. Signed-off-by: Damien Lespiau Acked-by: Stephen Finucane ---

[PATCH 4/7] api: Add a basic REST API to access Series/Revisions and Patches

v2: Merge commits introducing basic objects v3: Introduce the SeriesListMixin class v4: Add the expand get parameter v5: Introduce /api/1.0/ metadata entry point Signed-off-by: Damien Lespiau --- docs/api.rst | 363

[PATCH 5/7] models: Add Event and EventLog models

I'd like to be able to track the history of manipulations done on series (and probably its patches as well). To start with, I'm only interested in when series are created so I can export a RSS feed containing the new series. For the curious mind, a full event table for just one field seems a bit

[PATCH 2/7] models: Monkey patch User to have a name() method

The name is really a poperty of the User. Not always having to retrieve the profile for that makes things simpler. Signed-off-by: Damien Lespiau --- patchwork/models.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/patchwork/models.py b/patchwork/models.py

[PATCH 7/7] api: Expose events

One interesting thing to be doing is polling for new events on a project. Right now, the only event is series-new-revision, so listening to events is really just listening to series creation and update. This is quite useful for testing infrastructures, knowing when a series is ready to be tested

[PATCH 6/7] series: Add a 'new-series-revision' event

We create a new log entry when a new series revision appears. The series_revision_complete event only fires when the series/revision is fully complete, eg., the git send-email series has been fully processed. That behaviour is tested, making sure an incomplete series doesn't appear in the

Re: [PATCH 00/15] Series models & parsing (v2)

ing comments)? Hilariously, the patches containing mbox files don't seem to go through. The branch containing this submission will be available for a while: https://github.com/dlespiau/patchwork/tree/test/20151020-series.submit -- Damien ___ Patchwork

[PATCH 10/14] tests: Add a utility class to create Series

So far we've been using real emails stored on-disk. While it's interesting to have real data as input for unit tests, it's not as flexible as having generated data. With generated data we can easily create corner cases to improve the test coverage of the parsing code. This is just a start, adding

[PATCH 07/14] series: Create Series objects when parsing mails

This commit only adds basic support for the initial series submission. Series with or without cover letters are supported. When sent without a cover letter, the series is named "Untitled series". It's planned to let the user chose a more appropriate series title through the web UI at a later

[PATCH 09/14] tests: Save the test project if we're going to use it

create_email() can use the default project for its mail. If that is the case, chances are we are going to use that email later in a test where we'll want that project to exist. Signed-off-by: Damien Lespiau Acked-by: Stephen Finucane ---

[PATCH 3/7] models: Don't return the email along with the name in Person's __unicode__

If we have a person name, that's enough to identify her/him. We don't need to add ones email address there. Signed-off-by: Damien Lespiau --- patchwork/models.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patchwork/models.py

[PATCH 1/7] models: Split a user_name() helper out of UserProfile

Signed-off-by: Damien Lespiau --- patchwork/models.py | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/patchwork/models.py b/patchwork/models.py index 6660cad..a1d6840 100644 --- a/patchwork/models.py +++ b/patchwork/models.py @@ -80,6

RE: [PATCH 00/14] Series models & parsing (v3)

> A few changes from v2: > > - Use 'Series without cover letter' as default name (Belen Pena) > - Merge the series migration into the model commit (Stephen Finucane) > - Add untested SQL statements for manual migrations (Stephen Finucane) > > It's totally unmaintenable to have those

RE: [PATCH 14/14] docs: Add a user-oriented explanation of series parsing

> It's really necessary to start documenting what Patchwork knows about > when parsing emails. You didn't address all of my comments, so I've re-raised them below (along with some other...niggles). > This time, it's about series and new revision of series. > > v2: Add back --annotate to the

RE: [PATCH 1/2] doc: Add CHANGELOG and UPGRADING docs

> Hi Stephen, > > You asked for review, and there are a few pieces I'm qualified to > comment on :) Thanks Brian - appreciate it :) > On Fri, Oct 16, 2015 at 11:00:22PM +0100, Stephen Finucane wrote: > > The CHANGELOG document should describe the high level changes of the > > project. This will

Re: [PATCH 1/2] doc: Add CHANGELOG and UPGRADING docs

On Tue, Oct 20, 2015 at 11:39:02PM +, Finucane, Stephen wrote: > > On Fri, Oct 16, 2015 at 11:00:22PM +0100, Stephen Finucane wrote: [...] > > > +[Unreleased]: > > https://github.com/getpatchwork/patchwork/compare/v1.0.0...HEAD > > > +[1.0.0]: > >

Re: [PATCH 1/2] doc: Add CHANGELOG and UPGRADING docs

Hi Stephen, You asked for review, and there are a few pieces I'm qualified to comment on :) On Fri, Oct 16, 2015 at 11:00:22PM +0100, Stephen Finucane wrote: > The CHANGELOG document should describe the high level changes of the > project. This will provide a human-readable way for people to

RE: [PATCH 0/7] REST API (v2)

> I did a full pass on the REST API I had and extracted a documented subset > that > should be easy to extend in the future. > > http://patchwork-freedesktop.readthedocs.org/en/latest/api.html > > A list of entry points is available, that's the basic documentation needed. > More will be added

Re: pwclient handling of argparse options

On Mon, Oct 19, 2015 at 01:56:35PM -0400, Mike Frysinger wrote: > On 19 Oct 2015 09:57, Bernhard Reutner-Fischer wrote: > > On October 17, 2015 4:25:54 AM GMT+02:00, Mike Frysinger wrote: > > >On 16 Oct 2015 16:39, Brian Norris wrote: > > >> commit_str = args.get('c') > > > > > >if you