Hi all,
I think it's time for me to officially step down from Patchwork maintainership.
I've been in a new job for 3 months now, and this company doesn't use
mailing lists for development. So I'm no longer using Patchwork as a
patch submitter, and the low volume of patches to the Patchwork
Stephen Finucane writes:
> I've seen reports that the mailing list is rejecting emails. Let's see if
> that's
> true for everyone. Please ignore.
Just the moderation queue getting overfull and me missing emails about
people who post before subscribing :/
Kind regards,
Daniel
>
> Stephen
>
Sean Anderson writes:
> Hi Stephen,
>
> On 11/29/21 12:58 PM, Stephen Finucane wrote:
>> On Mon, 2021-11-22 at 18:20 -0500, Sean Anderson wrote:
>>> This adds a link to all patches currently delegated to a user. This can
>>> be much easier than going through the delegate filter, especially if
Konstantin Ryabitsev writes:
> On Wed, Oct 27, 2021 at 05:00:34PM +0100, Stephen Finucane wrote:
>> v2.2.6 is available now. Let me know if there are any issues.
>
> Thanks!
>
>> Somewhat related: are there any large blockers preventing you moving to
>> v3.0.x?
>> Is it the major version bump
e list about the server [1].
>
> [1] https://lists.ozlabs.org/pipermail/patchwork/2021-September/007226.html
>
> Signed-off-by: Stephen Finucane
> Cc: Daniel Axtens
> ---
> README.rst | 4
> 1 file changed, 4 insertions(+)
>
> diff --git README.rst README.r
Hi Lukas,
>> It currently detects mails with identical subjects (after prefixes are
>> removed) within a 180 day window. This is not a very sophisticated
>> matching system, but given that it's an API client and not in the core,
>> I'm much happier to experiment and build up sophistication as and
Stephen Finucane writes:
> Start making series more useful by tracking whether the state is open,
> meaning one or more patches are in a state with action_required=True, or
> not. This means that the 'git-pw series list' command will only list
> series that are actually actionable.
>
>
Hi all,
Recently I set up a Discord 'server' for patchwork discussions.
We used it a bit during Raxel's internship at Google and it was quite
helpful to have a slightly lower latency and less formal place to
chat. I'd like to welcome anyone else interested in patchwork or related
projects
Hi all,
I have written the simplest patch relation detector that might possibly
work as an API client. It is running against the patchwork and
linuxppc-dev projects on patchwork.ozlabs.org.
It currently detects mails with identical subjects (after prefixes are
removed) within a 180 day window.
Not really something for this exact patch, but I do wonder as API
versions proliferate if we should have infrastructure to test something
on all supported API versions.
[Perhaps it's my lack of a formal CS education showing here but I feel
like there's probably some software design pattern for
LGTMed-by: Daniel Axtens
I haven't looked at it quite enough to give it a proper Review but I
don't have any obvious objections.
Kind regards,
Daniel
Stephen Finucane writes:
> Signed-off-by: Stephen Finucane
> ---
> docs/usage/overview.rst | 28 +++-
Stephen Finucane writes:
> On Sun, 2021-08-29 at 23:04 +1000, Daniel Axtens wrote:
>> Stephen Finucane writes:
>>
>> > On Fri, 2021-08-27 at 13:50 +1000, Daniel Axtens wrote:
>> > > Stephen Finucane writes:
>> > >
>> > >
Stephen Finucane writes:
> On Fri, 2021-08-27 at 13:51 +1000, Daniel Axtens wrote:
>> Stephen Finucane writes:
>>
>> > Allow submitters to indicate that their comment is something that needs
>> > to be addressed.
>>
>> Hmm, do we have any e
Daniel Axtens writes:
> Stephen Finucane writes:
>
>> On Fri, 2021-08-06 at 11:39 +1000, Daniel Axtens wrote:
>>> Stephen Finucane writes:
>>>
>>> > On Tue, 2021-08-03 at 01:27 +1000, Daniel Axtens wrote:
>>> > > In d
Raxel Gutierrez writes:
> From: raxelg
>
> Update Google email used during internship to personal email.
>
> Signed-off-by: Raxel Gutierrez
Applied. Welcome back, it's great to have you around!
> ---
> .mailmap | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/.mailmap b/.mailmap
>
Daniel Axtens writes:
> This saves us doing a whole bunch of rewrites sequentially - instead
> we just do one big rewrite.
>
> Currently breaks postgres and sqlite, which is annoying because they
> don't need this to go faster. OTOH it makes mysql a **lot** faster - from
> a
Stephen Finucane writes:
> On Fri, 2021-08-06 at 11:39 +1000, Daniel Axtens wrote:
>> Stephen Finucane writes:
>>
>> > On Tue, 2021-08-03 at 01:27 +1000, Daniel Axtens wrote:
>> > > In discussions about how to make patchwork more user-friendly and
>> &
not sure is entirely
>> > true?
>> >
>> >> But, again, I see the un/addressed field as being for the submitter, not
>> >> the maintainer. The maintainer can't trust it anyway because what the
>> >> submitter considers 'addressed' and the maintainer c
oops, did not intend to need 3 versions. soz all.
Signed-off-by: Daniel Axtens
---
docs/usage/clients.rst | 15 +++
1 file changed, 15 insertions(+)
diff --git a/docs/usage/clients.rst b/docs/usage/clients.rst
index 01dd62a28e50..1dbdacc4de41 100644
--- a/docs/usage/clients.rst
Signed-off-by: Daniel Axtens
---
docs/usage/clients.rst | 13 +
1 file changed, 13 insertions(+)
diff --git a/docs/usage/clients.rst b/docs/usage/clients.rst
index 01dd62a28e50..e9c0ad49108b 100644
--- a/docs/usage/clients.rst
+++ b/docs/usage/clients.rst
@@ -53,3 +53,16
Signed-off-by: Daniel Axtens
---
docs/usage/clients.rst | 13 +
1 file changed, 13 insertions(+)
diff --git a/docs/usage/clients.rst b/docs/usage/clients.rst
index 01dd62a28e50..5c0024c3ddbb 100644
--- a/docs/usage/clients.rst
+++ b/docs/usage/clients.rst
@@ -53,3 +53,16
Stephen Finucane writes:
> On Fri, 2021-08-27 at 13:50 +1000, Daniel Axtens wrote:
>> Stephen Finucane writes:
>>
>> > The current workflow for the address/unaddressed attribute of comments
>> > sets all comments to unaddressed by default. This is unintui
Stephen Finucane writes:
> Allow submitters to indicate that their comment is something that needs
> to be addressed.
Hmm, do we have any evidence that any of our existing mail headers are
used by anything?
Also, I'm not confident I know how to set a header on a comment and I
write my email
by: Stephen Finucane
> Cc: Raxel Gutierrez
> Cc: Daniel Axtens
> ---
> I think it's essential we make this change in order for this patch to be
> useful. I also think it's okay to modify the migration in place, since
> (a) we don't support deployment from master in production and (
', 'delegate',
- 'series')
+ 'series', 'submitter__user')
patches = patches.only('state', 'submitter', 'delegate', 'project',
'series__name', 'name', 'date', 'msgid')
Daniel Axtens writes:
>>
> TODO: The loading of the patch-list page is very slow now because it
> seems that for each call to check if a patch is editable by a user, the
> db is accessed. Changes in the backend need to be made so this is done
> with only done with only one call to the db.
AFAICT, the issue is that the
> This series is a revision to the previous version of the patch series.
> The series addresses the review comments from the v3 series [1] and also
> adds support for cover letter comments.
Series applied, with some minor tweaks as (hopefully) documented in my replies.
We could probably have
Raxel Gutierrez writes:
I've merged this with some small changes as detailed below.
> Add new endpoint for patch and cover comments at
> api/.../comments/.
> This involves updating the API version to v1.3 to reflect the new
> endpoints as a minor change, following the usual semantic versioning
Raxel Gutierrez writes:
> Add new label to patch and cover comments to show the status of whether
> they are addressed or not and add an adjacent button to allow users to
> change the status of the comment. Only users that can edit the patch
> (i.e. patch author, delegate, project maintainers)
I made some changes to handle the bugfixes that we made over the weekend
and then applied this.
Raxel Gutierrez writes:
> Rename cover lookup parameter `pk` to `cover_id` for the cover comments
> list endpoints to disambiguate from the lookup parameter `comment_id` in
> upcoming patches which
Applied.
Raxel Gutierrez writes:
> Change both of the message containers in the "Commit Message" and
> "Comments" to have their content be left-aligned which improves the
> proximity of items which boosts the efficiency of gathering information
> and performing actions. Before [1] and after [2]
Applied in order to apply Raxel's first 2 patches.
Daniel Axtens writes:
> Basically, finish the job of commit fecf7c86c2c5 ("urls: Add missing path
> converters for REST APIs"). With this commit, there are no more uses of
> Http404 in patchwork/api
>
> Sig
Basically, finish the job of commit fecf7c86c2c5 ("urls: Add missing path
converters for REST APIs"). With this commit, there are no more uses of
Http404 in patchwork/api
Signed-off-by: Daniel Axtens
---
patchwork/api/comment.py | 8 +++-
1 file changed, 3 insertions(+), 5
fixed, hold back the Sphinx version to < 4.1.0
Signed-off-by: Daniel Axtens
---
docs/requirements.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/docs/requirements.txt b/docs/requirements.txt
index e2641c8fb996..b60bca53215f 100644
--- a/docs/requirements.txt
+++ b/d
and addressed comments in the
>> patch-detail page.
>>
>> Signed-off-by: Raxel Gutierrez
>> Reviewed-by: Daniel Axtens
>
> I'm still not entirely happy with this design. It's functional, but it seems
> overly verbose for what I think we're trying to do here. In
4' in some places
> to provide additional protection.
LGTM, applied with a tweaked commit message and the change mentioned below:
>
> Signed-off-by: Stephen Finucane
> Cc: Daniel Axtens
> ---
> patchwork/api/base.py | 3 ++-
> patchwork/api/check.
Applied.
Daniel Axtens writes:
> commit 3a979ed8bfc6 ("migrations: don't go to the db for 0041_python3
> migration")
> made a bunch of strings go past 79 characters, breaking flake8 checks.
>
> `black` doesn't seem to fix this and reflowing the strings manually is
Hi Konstantin,
Thanks for your bug reports. Fixes to both for upstream are on the
list. Fixes for the first (v1.1 errors) should apply directly to
stable/2.2; the second one will require a minor backport.
It's now very late so I'm going to leave this for now. Stephen feel free
to take the wheel,
to return a 400 and some explanation,
but I can't see an easy way to bend Django or DRF to my will here.
Signed-off-by: Daniel Axtens
---
Will need some tweaking for 2.2, but conceptually simple.
Stephen, would be interested if you can come up with a better way
to propagate a meaningful error out
> Some of the others returning 500 errors are:
>
> GET /api/patches/{msgid}/comments/
>
> I'd be happy to provide tracebacks if I can figure out how to get them.
yeah msgid is not a valid argument there, it needs to be a number. If
you got a traceback it would look like this:
File
This has been broken for a long time and we didn't notice. Weird.
We fixed it, now add a test.
Signed-off-by: Daniel Axtens
---
patchwork/tests/api/test_patch.py | 14 ++
1 file changed, 14 insertions(+)
diff --git a/patchwork/tests/api/test_patch.py
b/patchwork/tests/api
present.
This is odd, but not harmful and we definitely shouldn't 500.
Fixes: d944f17ec059 ("REST: Use versioning for modified responses")
Signed-off-by: Daniel Axtens
---
patchwork/api/base.py | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/patchwork/api/base.py b
> Here's the PATCH traceback:
It's broken upstream too - we don't have a test for PATCH of a patch
with APIv1.1. I can't figure out why 2.2.5 would have exposed it but I
don't pretend to understand the fine detail of the patch that went in
between 2.2.4 and 2.2.5.
I'll send a patch for this then
Konstantin Ryabitsev writes:
> Hello:
>
> After the 2.2.2->2.2.5 upgrade, we seem to be getting lots of /api/1.1/ errors
> for PATCH calls:
>
> PATCH /api/1.1/patches/{id}/
>
> switching to /api/1.2/ seems to fix it, but requires other client app fixes
> for API incompatibility.
>
> Some of
d with the comment (i.e. patch author, project maintainers, and
> delegate) and add permissions to change `addressed` status for comment
> authors as well.
>
As discussed in another email, I tested the migration and I have no
concerns about it.
Reviewed-by: Daniel Axtens
I'm not plan
Daniel Axtens writes:
> Raxel Gutierrez writes:
>
>> Add new label to patch comments to show the status of whether they are
>> addressed or not and add an adjacent button to allow users to change the
>> status of the comment. Only users that can edit the patch (i.e. p
>> > +operations = [
>> > +migrations.AddField(
>> > +model_name='patchcomment',
>> > +name='addressed',
>> > +field=models.BooleanField(default=False),
>
> Thinking out loud: I suspect this will be an expensive migration since it will
> add a new
is file so just don't run
flake8 against it.
Fixes: 3a979ed8bfc6 ("migrations: don't go to the db for 0041_python3
migration")
Signed-off-by: Daniel Axtens
---
patchwork/migrations/0041_python3.py | 8
1 file changed, 8 insertions(+)
diff --git a/patchwork/migrations/0041_pyt
for the network request to resolve,
but that's complex to do and is only really useful in the edgecase where
the request fails for some reason. So it shouldn't block inclusion now.
Pending Stephen's stylistic comments:
Reviewed-by: Daniel Axtens
Stephen, I'll let you merge this once you're happy
Stephen Finucane writes:
> On Wed, 2021-08-18 at 12:01 +0100, Stephen Finucane wrote:
>> On Tue, 2021-08-17 at 21:31 +, Raxel Gutierrez wrote:
>> > Refactor the messages container to make use of message.tags [1] which
>> > allows for more customization for each level (e.g. success, warning,
Raxel Gutierrez writes:
> Refactor the messages container to make use of message.tags [1] which
> allows for more customization for each level (e.g. success, warning,
> error, etc.) of a message through CSS selectors. As basic proof of
> concept, customize the text color of each existing message
Raxel Gutierrez writes:
> Add `rest.js` file to have a utilities JavaScript module that can be
> reused by any Patchwork JS files that make requests to the REST API. In
> particular, this patch provides the following function:
>
> - `updateProperty`: make PATCH requests that partially update
.com/js-cookie/js-cookie/releases
>
> Signed-off-by: Raxel Gutierrez
Reviewed-by: Daniel Axtens
I will merge this once we get the bugs fixed in the REST js.
Something somewhere in the pipeline is corrupting the JS file so I will
replace the js.cookie.min.js with the contents of the v3.0.
Raxel Gutierrez writes:
> Add new label to patch comments to show the status of whether they are
> addressed or not and add an adjacent button to allow users to change the
> status of the comment. Only users that can edit the patch (i.e. patch
> author, delegate, project maintainers) as well as
Raxel Gutierrez writes:
> Add `rest.js` file to have a utilities JavaScript module that can be
> reused by any Patchwork JS files that make requests to the REST API. In
> particular, this patch provides the following function:
>
> - `updateProperty`: make PATCH requests that partially update
> Thinking out loud: I suspect this will be an expensive migration since it will
> add a new non-nullable field to all patchcomment rows. Maybe that's something
> we
> can live with, but making this nullable might make more sense, particularly if
> we want to make this feature
Raxel Gutierrez writes:
> Add new label to patch comments to show the status of whether they are
> addressed or not and add an adjacent button to allow users to change the
> status of the comment. Only users that can edit the patch (i.e. patch
> author, delegate, project maintainers) as well as
Raxel Gutierrez writes:
> Add new endpoint for patch comments at api/.../comments/.
> The endpoint will make it possible to use the REST API to update the new
> `addressed` field for individual patch comments with JavaScript on the
> client side. In the process of these changes, clean up use of
Daniel Axtens writes:
> Hi Raxel,
>
> Some general comments:
>
>> Currently, there is no state or status associated with patch comments.
>> In particular, knowing whether a comment on a patch is addressed is
>> useful for transparency and accountability in t
Raxel Gutierrez writes:
> Signed-off-by: Raxel Gutierrez
> ---
> ...essed-patch-comments-bfe71689b6f35a22.yaml | 20 +++
> 1 file changed, 20 insertions(+)
> create mode 100644
>
Raxel Gutierrez writes:
> Add new label to show the status of whether a comment is addressed and a
> button to change the status of the comment. Only users that can edit
> the patch (submitter, delegate, project maintainers) can change the
> status of a comment. Clean up submission.html to have
Raxel Gutierrez writes:
> Add tests for the new api/.../comments/ endpoint that takes
> GET, PATCH, and PUT requests. The tests cover retrieval and update
> requests and handle calls from the various API versions. Also, they
> handle permissions for update requests on the new `addressed` field
Hi Raxel,
Some general comments:
> Currently, there is no state or status associated with patch comments.
> In particular, knowing whether a comment on a patch is addressed is
> useful for transparency and accountability in the review and
> contribution process. This series adds labels to
Raxel Gutierrez writes:
> Add js file to have REST API requests utilities JavaScript module to be
> reused by other Patchwork js files making updates to objects.
>
> - Add function to make fetch requests that update properties through
>'PATCH' requests with the REST API endpoints.
>
> -
Raxel Gutierrez writes:
> Use new comment detail REST API endpoint to update the addressed field
> value when "Addressed" or "Unaddressed" buttons are clicked. After, the
> request is made, the appearance of the comment status label and buttons
> are toggled appropriately.
As a general note, if
Stephen Finucane writes:
> On Tue, 2021-08-03 at 01:27 +1000, Daniel Axtens wrote:
>> As with the UI.
>>
>> Signed-off-by: Daniel Axtens
>> ---
>> patchwork/tests/test_xmlrpc.py | 90 ++
>> patchwork/views/xmlrpc.
Stephen Finucane writes:
> On Tue, 2021-08-03 at 01:27 +1000, Daniel Axtens wrote:
>> In discussions about how to make patchwork more user-friendly and
>> suitable for more projects, we realised that perhaps the current
>> ability for submitters to change their patch state
Raxel Gutierrez writes:
> Hi,
>
> I want to use this fairly new JS function `Element.replaceChildren()` [1]
> to replace error/update messages. Looking at browser stats, it seems pretty
> compatible but it doesn't work with IE. How should browser compatibility be
> approached?
>From caniuse.com
Hi Raxel,
A few bugs:
- if you submit a change with the dropdowns that errors out, and then
subsequently submit one that succeeds, the error messages are not
cleared.
- You've somehow ended up with two td.patch-delegate:
New
.djangoproject.com/en/3.2/ref/csrf/#ajax
This still isn't applying properly but I can at least find it online
fairly easily. I suspect mailman is forcing linebreaks that it shouldn't
do, but idk.
Anyway,
Acked-by: Daniel Axtens
Once I find a patch that uses this that is ready to apply I'm happy to
Hi Raxel,
I think this patch may do a bit much, and I am struggling to follow it.
If I understand correctly,
> Clean up the patch-list page by moving forms to a new template file
> patch-forms.html and move them to the top of the page, add ids to
this bit makes a user visible change, but
> No
As with xmlrpc and the UI.
Signed-off-by: Daniel Axtens
---
patchwork/api/patch.py| 10 +
patchwork/tests/api/test_patch.py | 70 +++
2 files changed, 80 insertions(+)
diff --git a/patchwork/api/patch.py b/patchwork/api/patch.py
index 9d222754412e
As with the UI.
Signed-off-by: Daniel Axtens
---
patchwork/tests/test_xmlrpc.py | 90 ++
patchwork/views/xmlrpc.py | 4 ++
2 files changed, 94 insertions(+)
diff --git a/patchwork/tests/test_xmlrpc.py b/patchwork/tests/test_xmlrpc.py
index 4726fdffa5d5
.
Allow a project to stop a submitter from changing the state of
their patches. This is not the default but can be set by a patchwork
administrator.
Signed-off-by: Daniel Axtens
---
...45_project_submitter_state_change_rules.py | 24 +
patchwork/models.py | 36
-driven API-centric automation.
This set of 3 patches allows a project to stop a submitter from
changing the state of their patches - in the UI, via xmlrpc and via
REST. This is not the default behaviour but can be set by a patchwork
administrator on a per-project basis.
Daniel Axtens (3):
Allow
Raxel Gutierrez writes:
> Added styling to the new patch list html code to make the change
> property and bundle action forms more usable. Before [1] and after [2]
> images for reference.
>
> [1] https://imgur.com/Pzelipp
> [2] https://imgur.com/UtNJXuf
Nice! I'll run it past the local
Raxel Gutierrez writes:
> Add dropdown for the cell values of the Delegate and State columns for
> each individual patch to make one-off changes to patches. Change the
> generic_list method to pass the list of states and maintainers to the
> patch list view context to populate the dropdown
Raxel Gutierrez writes:
> Currently, requests are made only through form submission and the
> csrftoken is added to templates using {% csrf_token %}. Following Django
> docs [1], the library is useful to add csrftoken when making requests in
> JavaScript.
>
> [1]
Stewart Smith writes:
> On Jul 16, 2021, at 10:20 AM, Daniel Axtens wrote:
>>
>> - we do a lot of legwork to prevent there being a column with the same
>> name in a base class and subclass. This is purely for django's benefit
>> as databases don't see the cl
.
Mostly, however, this is RFC because I am not sure about the random-ish
strings in the middle of the constraint names. I took them from the
`sqlmigrate` output but I don't know if they're random or special.
Thoughts?
Signed-off-by: Daniel Axtens
---
.../migrations
Migrate 1 rows at a time. This:
- provides a view on progress
- means replication happens in manageable chunks
- hopefully prevents db lockups
Signed-off-by: Daniel Axtens
---
.../migrations/0043_merge_patch_submission.py | 146 ++
1 file changed, 82 insertions(+), 64
table, not the other way around.
Signed-off-by: Daniel Axtens
---
.../migrations/0043_merge_patch_submission.py | 140 +-
1 file changed, 68 insertions(+), 72 deletions(-)
diff --git a/patchwork/migrations/0043_merge_patch_submission.py
b/patchwork/migrations
the state as seen by Django only.
This makes the migration ~instant, even for a huge database.
Signed-off-by: Daniel Axtens
---
patchwork/migrations/0041_python3.py | 632 ++-
1 file changed, 318 insertions(+), 314 deletions(-)
diff --git a/patchwork/migrations/0041_pyt
migration in chunks which
should make administrators' lives nicer.
It currently breaks postgres/sqlite, but I'm hoping to get some feedback
from larger deployments on whether I'm moving in the right direction here
before I polish it up too much.
Kind regards,
Daniel
Daniel Axtens (4):
migrations: don't
Daniel Axtens writes:
> However, given that this is the first time comments have mattered at
> all, I'd be OK to ignore multi-line comments. I would like nested
> comments to work though, unless it makes a real mess of things.
Ah so it turns out I'm totally wrong here: we've been g
Hi,
Thanks for your contribution Raxel!
>> When contributors using Gnus reply to a patch, the In-Reply-To &
>> References header fields include comments in the form described in
>> remove_rfc2822_comments spec. These comments can lead to threading
>> issues where users' replies don't get
Series applied.
Daniel Axtens writes:
> Two small fixes to testing:
> - a fix to grant the right permissions for mysql to unbreak parallel testing
> - install python3.9 in docker so we can run those tests
>
> Travis CI has basically died for our purposes - you now need
Applied.
Daniel Axtens writes:
> The docker dev docs:
>
> - had the links for docker and docker-compose swapped.
>
> - had a old docker install link.
>
> - lacked an up-front explanation of the requirement that a regular user
>be able to manage the docker daemon
Since commit 9a54bf4bfc54 ("Add Python 3.9 support"), Python 3.9 is tested
by tox, so currently `docker-compose run web --tox` fails due to missing
Py3.9 binaries. Fix it.
Fixes: 9a54bf4bfc54 ("Add Python 3.9 support")
Signed-off-by: Daniel Axtens
---
tools/docker/Docker
of the required permissions in the automated
script, you need to delete the old db data in order to observe the
issue.
Amusingly postgres worked the whole time.
Fixes: 6025f0e2533f ("Add parallel testing")
Signed-off-by: Daniel Axtens
---
tools/docker/entrypoint.sh | 2 +-
1 file
this month.
I'll send another patch/series just ripping out support for it
soon. Hopefully we can replace it with github actions.
Daniel Axtens (2):
tests: fix parallel tests
docker: install Python 3.9
tools/docker/Dockerfile| 3 ++-
tools/docker/entrypoint.sh | 2 +-
2 files changed, 3
> I am thinking of doing a little scriptlet that just iterates on ncpus
> but if you were able to get this to work on your end (or if anyone knows
> how to actually do what we're going for) I'd be keen to know.
Ah so interestingly the MySQL docs seem to suggest this does work, if
you use
Hi Stephen,
> diff --git tools/docker/entrypoint.sh tools/docker/entrypoint.sh
> index 6314f1b6..8f7ea4f7 100755
> --- tools/docker/entrypoint.sh
> +++ tools/docker/entrypoint.sh
> @@ -26,7 +26,7 @@ reset_data_mysql() {
> DROP DATABASE IF EXISTS patchwork;
> CREATE DATABASE patchwork CHARACTER
block.)
Fix it all.
Reported-by: Emily Shaffer
Signed-off-by: Daniel Axtens
---
v2: properly use the link format. sigh.
---
docs/development/installation.rst | 20 ++--
1 file changed, 14 insertions(+), 6 deletions(-)
diff --git a/docs/development/installation.rst
b/docs
block.)
Fix it all.
Reported-by: Emily Shaffer
Signed-off-by: Daniel Axtens
---
docs/development/installation.rst | 17 +++--
1 file changed, 11 insertions(+), 6 deletions(-)
diff --git a/docs/development/installation.rst
b/docs/development/installation.rst
index ff81229dfbd9
Hi all,
> I'd like to introduce Raxel (cc-ed), who is starting an internship
> this June with the Git team at Google.
>
> He'll be working on a bit of an experimental project: we want to take
> Patchwork[1], which in principle can be a helpful addition to a
> mailing list centric workflow[2], and
Bin Meng writes:
> On Wed, Oct 28, 2020 at 1:58 PM Bin Meng wrote:
>>
>> Hi,
>>
>> Please see below two series:
>>
>> Series #1: http://patchwork.ozlabs.org/project/qemu-devel/list/?series=210330
>> Series #2: http://patchwork.ozlabs.org/project/qemu-devel/list/?series=210336
>>
>> The
> I think we may be oversetimating how many people out there run
> patchwork. :) My general concern was to make sure that parsemail doesn't
> do things like clear django data. If, to your knowledge, all it does is
> write to the database without interacting with the running process, then
> there's
Simon Glass writes:
> Hi,
>
> This patch failed to make it into patchwork. The series is here:
>
> http://patchwork.ozlabs.org/project/uboot/list/?series=204488
>
> I just resent it and still don't see it.
>
> Is this a bug?
>
> Regards,
> Simon
>
> -- Forwarded message -
> From:
Stephen Finucane writes:
> On Wed, 2020-10-14 at 11:06 +1100, Daniel Axtens wrote:
>> Hi Konstantin,
>>
>> > Would adding an index across (id, project_id, msgid) make this query
>> > faster to run?
>>
>> Thanks for the report, and once again
1 - 100 of 874 matches
Mail list logo
