- Original Message -
> From: "Stephen Finucane"
> To: "Veronika Kabatova"
> Cc: patchwork@lists.ozlabs.org
> Sent: Wednesday, September 19, 2018 11:38:32 PM
> Subject: Re: [PATCH RESEND 1/2] Rework tagging infrastructure
>
> On Wed, 2018-09-12 at 04:57 -0400, Veronika Kabatova wrote:
On Sat, Sep 22, 2018 at 12:53:46AM +1000, Daniel Axtens wrote:
> Don Zickus writes:
>
> > On Tue, Sep 11, 2018 at 12:21:26PM -0600, Stephen Finucane wrote:
> >> > Personally I would *really* like labels to land. They unlock a lot of
> >> > potential improvements to workflow for maintainers, eg.
The 'SeriesPatch' object was recently removed, but the
'create_series_patch' was retained in order to minimize the changes
necessary. This can now be removed and the logic moved to the
'create_patch' and 'create_cover' functions instead.
Signed-off-by: Stephen Finucane
---
Previously, we allowed users to download patch mboxes with dependencies
included using a 'series' parameter. This accepted either a numeric ID,
corresponding to the ID of the patch series that dependencies should be
included from, or a wildcard value ('*').
/patch/{patchID}/mbox/?series=123
Compare against known values to ensure bugs introduced in the function
are caught.
Signed-off-by: Stephen Finucane
Reviewed-by: Daniel Axtens
---
patchwork/tests/test_series.py | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/patchwork/tests/test_series.py
This is mostly a tech debt reduction exercise. As noted in the main
patch, the M:N relationship between series and patches was, in
hindsight, a design decision made for the wrong reasons. It's one of the
things holding us back on the improved tagging series and it makes a lot
of things more
Cover some testing gaps identified during the migration from a M:N to a
1:N series-patch relationship, namely:
- Downloading a patch's mbox with dependencies using a numerical series
ID
- Downloading a series' mbox
Signed-off-by: Stephen Finucane
Reviewed-by: Daniel Axtens
---
On Sat, 2018-09-22 at 01:18 +1000, Daniel Axtens wrote:
> Stephen Finucane writes:
>
> > On Sat, 2018-09-22 at 00:22 +1000, Daniel Axtens wrote:
> > > Hi Stephen,
> > >
> > > > I've rebased a couple of things onto these two patches and am starting
> > > > to rely on it locally, so I'm just
A recent change added additional ERROR level logs to the 'parsearchive'
tool. This highlighted an issue, whereby we had configured all modules
in 'patchwork.management.command' to email administrators on ERROR logs.
We clearly shouldn't be doing this for the 'parsearchive' command or for
anything
Stephen Finucane writes:
> This is mostly a tech debt reduction exercise. As noted in the main
> patch, the M:N relationship between series and patches was, in
> hindsight, a design decision made for the wrong reasons. It's one of the
> things holding us back on the improved tagging series and
Stephen Finucane writes:
> Previously, we allowed users to download patch mboxes with dependencies
> included using a 'series' parameter. This accepted either a numeric ID,
> corresponding to the ID of the patch series that dependencies should be
> included from, or a wildcard value ('*').
>
>
Also LGTM.
Reviewed-by: Daniel Axtens
Regards,
Daniel
Stephen Finucane writes:
> Compare against known values to ensure bugs introduced in the function
> are caught.
>
> Signed-off-by: Stephen Finucane
> ---
> patchwork/tests/test_series.py | 8 ++--
> 1 file changed, 2 insertions(+),
Stephen Finucane writes:
LGTM and tests are good.
Reviewed-by: Daniel Axtens
Regards,
Daniel
> Cover some testing gaps identified during the migration from a M:N to a
> 1:N series-patch relationship, namely:
>
> - Downloading a patch's mbox with dependencies using a numerical series
> ID
Stephen Finucane writes:
> On Sat, 2018-09-22 at 00:22 +1000, Daniel Axtens wrote:
>> Hi Stephen,
>>
>> > I've rebased a couple of things onto these two patches and am starting
>> > to rely on it locally, so I'm just going to apply both. It's easy to
>> > revert either of the if necessary.
>>
Stephen Finucane writes:
> On Sat, 2018-09-22 at 00:19 +1000, Daniel Axtens wrote:
>> Stephen Finucane writes:
>>
>> > Given that 'tox' doesn't actually read any of these, there's no reason
>> > to use ranges of requirements. Instead, use the latest and greatest for
>> > live instances and
Hi Stephen,
>> /message/ does not require a project, but therefore if a mail
>> has been sent to multiple projects, the project that you will be
>> redirected to is arbitrary.
>
> Personally, I'm not a fan of the latter as I don't see what value it
> would bring. Is there any reason to keep it or
Don Zickus writes:
> On Tue, Sep 11, 2018 at 12:21:26PM -0600, Stephen Finucane wrote:
>> > Personally I would *really* like labels to land. They unlock a lot of
>> > potential improvements to workflow for maintainers, eg. automated
>> > tagging, tagging based on test results etc. As well as
On Sat, 2018-09-22 at 00:19 +1000, Daniel Axtens wrote:
> Stephen Finucane writes:
>
> > Given that 'tox' doesn't actually read any of these, there's no reason
> > to use ranges of requirements. Instead, use the latest and greatest for
> > live instances and rely on tox to validate behavior with
On Sat, 2018-09-22 at 00:22 +1000, Daniel Axtens wrote:
> Hi Stephen,
>
> > I've rebased a couple of things onto these two patches and am starting
> > to rely on it locally, so I'm just going to apply both. It's easy to
> > revert either of the if necessary.
>
> They're breaking the build:
>
>
Hi Stephen,
> I've rebased a couple of things onto these two patches and am starting
> to rely on it locally, so I'm just going to apply both. It's easy to
> revert either of the if necessary.
They're breaking the build:
https://travis-ci.org/getpatchwork/patchwork/jobs/431231311#L486
I don't
Stephen Finucane writes:
> Given that 'tox' doesn't actually read any of these, there's no reason
> to use ranges of requirements. Instead, use the latest and greatest for
> live instances and rely on tox to validate behavior with older versions.
I don't really understand the motivation for
21 matches
Mail list logo
