aboutsummaryrefslogtreecommitdiff
path: root/releasenotes
Commit message (Collapse)AuthorAge
* Release 3.0.0Stephen Finucane2020-12-13
| | | | | | | Major version bump because of Python 2.7 removal and the unfortunately large DB migration. Signed-off-by: Stephen Finucane <stephen@that.guru>
* Add Python 3.9 supportStephen Finucane2020-12-13
| | | | | | This has been out since October. Time to support it. Signed-off-by: Stephen Finucane <stephen@that.guru>
* Add release note for #379Stephen Finucane2020-12-13
| | | | Signed-off-by: Stephen Finucane <stephen@that.guru>
* Add support for djangorestframework 3.12Stephen Finucane2020-10-01
| | | | | | No changes necessary. Signed-off-by: Stephen Finucane <stephen@that.guru>
* models: Validate Project.linkname does not contain forward slashThomas Bracht Laumann Jespersen2020-10-01
| | | | | | | | | | | | | | | | | | | | | | | | | | I started by creating a project that contained a forward slash (importing patches from https://lists.sr.ht/~sircmpwn/sr.ht-dev/) and it fails to render the "projects" main page. The specific error reads: NoReverseMatch at / Reverse for 'patch-list' with keyword arguments '{'project_id': 'foo/bar'}' not found. 1 pattern(s) tried: ['project/(?P<project_id>[^/]+)/list/$'] which appears to explicitly disallow forward slashes. So I think it makes sense to validate that project linkname doesn't contain forward slahes. This implementation uses the validate_unicode_slug validator instead of just rejecting inputs that contain forward slashes. Signed-off-by: Thomas Bracht Laumann Jespersen <t@laumann.xyz> Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #380
* Add support for Django 3.1Andrew Donnellan2020-08-28
| | | | | Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Reviewed-by: Stephen Finucane <stephen@that.guru>
* parser: don't trigger database IntegrityErrors on duplicate coverlettersJeremy Kerr2020-04-18
| | | | | | | | | As we've done for the Patch and Comment models, this change prevents database errors from duplicate CoverLetters. Signed-off-by: Jeremy Kerr <jk@ozlabs.org> Signed-off-by: Stephen Finucane <stephen@that.guru> [stephenfin: Add release note]
* REST: Allow update of bundle without patchesStephen Finucane2020-04-18
| | | | | | | | | | Presently, when updating a patch we assume that patches are provided. This isn't necessary - you might just want to make it public - and isn't enforced by the API itself. However, because we make this assumption, we see a HTTP 500. Resolve the issue and add tests to prevent a regression. Signed-off-by: Stephen Finucane <stephen@that.guru> Resolves: #357
* api: allow filtering patches and covers by msgidDaniel Axtens2020-04-14
| | | | | | | | | | | | | | | | | | | | In the process of fixing the previous bug, I realised that: a) /api/patches/msgid is a perfectly reasonable thing to attempt b) We have no way of finding a patch by message id in the API We can't actualy make /api/patches/msgid work because it may not be unique, but we can add a filter. I'm shoehorning this into stable/2.2, even though it's technically an API change: it's minor, not incompatible and in hindsight a glaring hole. Cc: Michael Ellerman <mpe@ellerman.id.au> Tested-by: Jeremy Kerr <jk@ozlabs.org> Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com> Reviewed-by: Stephen Finucane <stephen@that.guru> Signed-off-by: Daniel Axtens <dja@axtens.net>
* Add Django 3.0 supportAndrew Donnellan2020-04-08
| | | | | | | | Add the latest version of Django. Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #311
* tox: Drop support for Django < 2.2, Python < 3.6Stephen Finucane2020-04-08
| | | | | | | | | Each of these versions of Django is now EOL, and Python 3.5 will be EOL by time we release the next version. Drop it. The Python 2.7 cleanup will be done separately. Signed-off-by: Stephen Finucane <stephen@that.guru>
* docs: Remove 'earliest_version' configStephen Finucane2020-04-05
| | | | | | | This is unnecessary and was disabling reno's built-in ability to detect a base branch. Signed-off-by: Stephen Finucane <stephen@that.guru>
* REST: Add release note for faster queriesDaniel Axtens2020-03-19
| | | | | | | | Didn't quite seem like it fit anywhere else in the series. I want the release note mostly because I hope to backport this to stable. Signed-off-by: Daniel Axtens <dja@axtens.net> Reviewed-by: Stephen Finucane <stephen@that.guru>
* REST: Add patch relationsMete Polat2020-03-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | View relations and add/update/delete them as a maintainer. Maintainers can only create relations of patches which are part of a project they maintain. Because this is a writable many-many nested relationship, it behaves a little unusually. In short: - All operations use PATCH to the 'related' field of a patch - To relate a patch to another patch, say 7 to 19, either: PATCH /api/patch/7 related := [19] PATCH /api/patch/19 related := [7] - To delete a patch from a relation, say 1, 21 and 42 are related but we only want it to be 1 and 42: PATCH /api/patch/21 related := [] * You _cannot_ remove a patch from a relation by patching another patch in the relation: I'm trying to avoid read-modify-write loops. * Relations that would be left with just 1 patch are deleted. This is only ensured in the API - the admin interface will let you do this. - Break-before-make: if you have [1, 12, 24] and [7, 15, 42] and you want to end up with [1, 12, 15, 42], you have to remove 15 from the second relation first: PATCH /api/patch/1 related := [15] will fail with 409 Conflict. Instead do: PATCH /api/patch/15 related := [] PATCH /api/patch/1 related := [15] -> 200 OK, [1, 12, 15, 42] and [7, 42] are the resulting relations Signed-off-by: Mete Polat <metepolat2000@gmail.com> Signed-off-by: Stephen Finucane <stephen@that.guru> Signed-off-by: Daniel Axtens <dja@axtens.net>
* views: Return Http404 if patch not foundAndriy Gelman2020-03-11
| | | | | | | | Otherwise exception DoesNotExist shows error 500 on Apache Signed-off-by: Andriy Gelman <andriy.gelman@gmail.com> Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #343
* parser: Don't group patches with different versions in a seriesStephen Finucane2020-03-11
| | | | | | | | | | | | | | | | | | | As noted in #340 [1], if a patch from a series is dropped or miscategorised, patches from a later revision of that series can end up included in the earlier series rather than in their own series. This was actually intentional as part of the fix for #105 [2]. However, completely ignoring this information can be problematic. Refine things by checking for versions and, if they don't match, using timeboxing to try guess if they should be kept together. This would resolve the issue seen in #340 while preventing a regression for #105. [1] https://github.com/getpatchwork/patchwork/issues/340 [1] https://github.com/getpatchwork/patchwork/issues/105 Signed-off-by: Stephen Finucane <stephen@that.guru> Tested-by: Ali Alnubani <alialnu@mellanox.com> Related: #340 Related: #105
* Add support for djangorestframework 3.11Stephen Finucane2020-02-28
| | | | | | There are no breaking changes apparent. Signed-off-by: Stephen Finucane <stephen@that.guru>
* docs: Change category of API release noteStephen Finucane2019-12-01
| | | | Signed-off-by: Stephen Finucane <stephen@that.guru>
* docs: Correct location of release noteStephen Finucane2019-12-01
| | | | | | | | Not sure how this ended up here but we both missed this. Correct the location. Signed-off-by: Stephen Finucane <stephen@that.guru> Fixes: d380219e ("api: support filtering patches by hash")
* docs: Add release notes for recently added featuresStephen Finucane2019-12-01
| | | | Signed-off-by: Stephen Finucane <stephen@that.guru>
* Allow ordering events by dateJeremy Cline2019-11-30
| | | | | | | | | | | By default, the events API orders events by date in descending order (newest first). However, it's useful to be able to order the events by oldest events first. For example, when a client is polling the events API for new events since a given date and wishes to process them in chronological order. Signed-off-by: Jeremy Cline <jcline@redhat.com> Reviewed-by: Stephen Finucane <stephen@that.guru>
* Revert "Remove Django 2.0 support"Daniel Axtens2019-11-05
| | | | This reverts commit f09bfd460814d7125437b0b45a183a221692584a.
* Remove Django 2.0 supportDaniel Axtens2019-11-05
| | | | | | | It's no longer supported upstream, per https://www.djangoproject.com/download/#supported-versions Signed-off-by: Daniel Axtens <dja@axtens.net>
* Python 3.8 supportAndrew Donnellan2019-10-24
| | | | | | | Enable Python 3.8 in our tests and list it as a supported version. Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Daniel Axtens <dja@axtens.net>
* parser: Unmangle From: headers that have been mangled for DMARC purposesAndrew Donnellan2019-10-18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | To avoid triggering spam filters due to failed signature validation, many mailing lists mangle the From header to change the From address to be the address of the list, typically where the sender's domain has a strict DMARC policy enabled. In this case, we should try to unmangle the From header. Add support for using the X-Original-From or Reply-To headers, as used by Google Groups and Mailman respectively, to unmangle the From header when necessary and associate the patch with the correct submitter based on the unmangled email address. When downloading mboxes, rewrite the From header using the unmangled address, and preserve the original header as X-Patchwork-Original-From in case someone needs it for some reason. The original From header will still be stored in the database and exposed via the API, as we want to keep messages as close to the original received format as possible. Closes: #64 ("Incorrect submitter when using googlegroups") Reported-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Tested-by: Daniel Axtens <dja@axtens.net> # mailman only [dja: add release note] Signed-off-by: Daniel Axtens <dja@axtens.net>
* REST: Allow creating, updating, deleting of bundlesStephen Finucane2019-10-17
| | | | | | | | | | Allow users to create a new bundle, change the name, public flag and patches of an existing bundle, and delete an existing bundle. Some small nits with existing tests are resolved. Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #316
* Use secrets and fall back to random.SystemRandom for keysJeremy Cline2019-10-17
| | | | | | | | | | | | | | | | | | The random module uses the Mersenne Twister pseudorandom number generator and is not a cryptographically secure random number generator[0]. The secrets[1] module is intended for generating cryptographically strong random numbers, so recommend using that to generate the secret key. It's new in Python 3, so if it's unavailable fall back to using the ``os.urandom()`` backed implementation of random. NOTE(stephenfin): Modified to include change to 'config.yaml'. Also renamed reno to just stick with hyphens for filenames. [0] https://docs.python.org/3/library/random.html [1] https://docs.python.org/3/library/secrets.html Signed-off-by: Jeremy Cline <jcline@redhat.com> Signed-off-by: Stephen Finucane <stephen@that.guru>
* trivial: Style fixesStephen Finucane2019-09-27
| | | | | | An assortment of fixes identified through the integration of pre-commit. Signed-off-by: Stephen Finucane <stephen@that.guru>
* Move to msgid based URLsDaniel Axtens2019-09-25
| | | | | | | | | | | | | | | | | | | | | | | | Migrate our URL schema as follows: Patches: /project/<linkname>/patch/<msgid>/ Cover Letters: /project/<linkname>/cover/<msgid>/ The usual sub-resources (mbox, raw) hang off those URLs. The old style URLs (/patch/NNN/*, /cover/NNN/*) redirect appropriately. I haven't attempted to do anything meaningful with series, and I have dropped any attempt to provide a generic message-id lookup or search functionality. One step at a time. Our database still stores message ids as with angle brackets; we just work around that rather than trying to migrate. That too can come later if we think the pain is justified. Partially-closes: #106 Reported-by: Konstantin Ryabitsev <konstantin@linuxfoundation.org> Reported-by-but-I-don't-want-to-spam: Linus Torvalds <torvalds@linux-foundation.org> Reported-by: Stephen Finucane <stephen@that.guru> Signed-off-by: Daniel Axtens <dja@axtens.net>
* Add support for djangorestframework 3.10Stephen Finucane2019-09-09
| | | | | | | This is necessary for proper Django 2.2 support. We retain support for older versions since 3.10 is Python 3-only. Signed-off-by: Stephen Finucane <stephen@that.guru>
* Drop support for Python 3.4, add Python 3.7Stephen Finucane2019-09-08
| | | | | | | It's no longer supported upstream and the *second* last Ubuntu LTS release provides something newer. Time to move on. Signed-off-by: Stephen Finucane <stephen@that.guru>
* releasenotes: Add release note for new list archive fieldsAndrew Donnellan2019-08-22
| | | | | Signed-off-by: Andrew Donnellan <ajd@linux.ibm.com> Signed-off-by: Daniel Axtens <dja@axtens.net>
* Add 'dumparchive' management commandMete Polat2019-07-19
| | | | | | | | | Introduces a new management command which can export all patches in a project as one mbox file. Export of multiple projects is supported. Additionally allows to compress the output. Signed-off-by: Mete Polat <metepolat2000@gmail.com> Signed-off-by: Stephen Finucane <stephen@that.guru>
* Remove pwclient release noteStephen Finucane2019-07-06
| | | | | | | We will remove 'pwclient' in v2.3 so it doesn't make much sense to keep a release note for it around. Remove that too. Signed-off-by: Stephen Finucane <stephen@that.guru>
* docs: Add a release note for CVE-2019-13122Daniel Axtens2019-07-05
| | | | Signed-off-by: Daniel Axtens <dja@axtens.net>
* Remove pwclientStephen Finucane2019-06-17
| | | | | | | | | Let's start managing this via a separate project, which will allow the client to evolve separately from the server. No redirect is added for the old '/pwclient' URL as it seems wiser to return a HTTP 404 error code. Signed-off-by: Stephen Finucane <stephen@that.guru>
* templates: Fix pwclientrc sampleStephen Finucane2019-06-17
| | | | | | | | INI files should use 'key = value' values, not 'key: value'. Correct this and fix some other whitespace issues. Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #277
* filters: re-add the possibility of filtering undelegated patchesMauro Carvalho Chehab2019-06-05
| | | | | | | | | | | | | | | The filters.py redesign that happened for patchwork 1.1 removed a functionality that we use a lot: to filter patches that weren't delegated to anyone. Also, it is a way harder to find someone to delegate with a free text input. Use, instead a combo-box just like before. Signed-off-by: Mauro Carvalho Chehab <mchehab@osg.samsung.com> Signed-off-by: Stephen Finucane <stephen@that.guru> Fixes: f439f541 ("Add delegate filter autocomplete support") Closes: #60 [stephenfin: Rework release note and fix some style issues]
* Fix typo in release noteStephen Finucane2019-06-05
| | | | Signed-off-by: Stephen Finucane <stephen@that.guru>
* Add support for Django 2.2Stephen Finucane2019-06-05
| | | | Signed-off-by: Stephen Finucane <stephen@that.guru>
* Revert "parser: Ensure whitespace is stripped for long headers"Daniel Axtens2019-05-14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit 841f966b8d54b2f51ab1c498eed6e5391f2546a9. In July 2018, we received a report of OzLabs patchwork mangling emails that have subjects containing words with internal commas, like "Insert DT binding for foo,bar" (#197). Stephen took a look and came up with the comment this reverts. Quoting the commit message: RFC2822 states that long headers can be wrapped using CRLF followed by WSP [1]. For example: Subject: Foo bar, baz Should be parsed as: Foo bar,baz As it turns out, this is not the case. Journey with me to section 2.2.3 of RFC 2822: 2.2.3. Long Header Fields Each header field is logically a single line of characters comprising the field name, the colon, and the field body. For convenience however, and to deal with the 998/78 character limitations per line, the field body portion of a header field can be split into a multiple line representation; this is called "folding". The general rule is that wherever this standard allows for folding white space (not simply WSP characters), a CRLF may be inserted before any WSP. For example, the header field: Subject: This is a test can be represented as: Subject: This is a test So the issue with the example in the reverted commit is that there is no folding white space in "bar,baz", so it's not valid to split it. These are valid: Subject: Foo bar,baz Subject: Foo bar,baz but splitting "bar,baz" into "bar,\n baz" is not valid. What then is correct unfolding behaviour? Quoting the RFC again: The process of moving from this folded multiple-line representation of a header field to its single line representation is called "unfolding". Unfolding is accomplished by simply removing any CRLF that is immediately followed by WSP. Each header field should be treated in its unfolded form for further syntactic and semantic evaluation. In other words, the unfolding rule requires you to strip the CRLF, but it does not permit you to strip the WSP. Indeed, if "bar,\n baz" is received, the correct unfolding is "bar, baz". If you do strip the WSP, you end up mashing words together, such as in https://patchwork.ozlabs.org/patch/1097852/ So revert the commit, restoring original behaviour, but keep a corrected version of the test. This presents a big question though: how did Rob's email up with a mangled subject line? To answer this question, you end up having to learn about OzLabs Patchwork and how it differs from Patchwork the project. OzLabs Patchwork (patchwork.ozlabs.org) is an installation of Patchwork. Part of what makes it so useful for so many projects is a little intervening layer that can massage some mail to make it end up in the right project. Email that lands in the device tree project is an example of email that goes through this process. I only learned about this today and I haven't looked in any detail at precisely what is done to the mail. The script is not part of the Patchwork project. This intervening filter is a Python script that runs - and this is an important detail - in Python 2.7. Ignoring all the details, the filter basically operates in a pipe between the mail program and patchwork's parsemail, like (mail from system) | filter.py | parsemail At it's very simplest, filter.py acts as follows: import email import sys mail = email.parse_from_file(sys.stdin) sys.stdout.write(mail.as_string()) Fascinatingly, if you take Rob's email from #197 and put it through this process, you can see that it is getting mangled: Before: Subject: [PATCH v2 3/4] dt-bindings: sound: wm8994: document wlf,csnaddr-pd property After: Subject: [PATCH v2 3/4] dt-bindings: sound: wm8994: document wlf, csnaddr-pd property You can see that python27 has incorrectly wrapped the header, breaking where there is not a foldable space. Python3 does not have this issue. To summarise: - part of the magic of OzLabs PW is a filter to make sure mail gets to the right place. This isn't part of the Patchwork project and so is usually invisible to patchwork developers. - the filter is written in python27. The email module in py27 has a bug that incorrectly breaks subjects around commas within words. - patchwork correctly unfolds those broken subjects with a space after the comma. - the extra space was interpreted as a bug in patchwork, leading to a misinterpretation of the spec to strip out the whitespace that was believed to be in error. - that broke other wrapped subjects. To solve this, revert the commit and I'll work with jk to get the filter script into py3 compatibility. (Given that py27 sunsets in ~7mo, trying to fix it is not worth it.) Closes: #273 Signed-off-by: Daniel Axtens <dja@axtens.net> Signed-off-by: Stephen Finucane <stephen@that.guru> [stephenfin: Use a new release note instead of editing the original one]
* parser: Ensure whitespace is stripped for long headersStephen Finucane2018-12-22
| | | | | | | | | | | | | | | | | | | | | | RFC2822 states that long headers can be wrapped using CRLF followed by WSP [1]. For example: Subject: Foo bar, baz Should be parsed as: Foo bar,baz While we were stripping the former, we were not stripping the latter. This mean that we ended up with the following: Foo bar, baz Resolve this. Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #197
* models: Ensure UserProfile.user is configuredStephen Finucane2018-12-22
| | | | | | | | | | Django Admin seems to be doing something funky with how it's handling the creation of a User's corresponding UserProfile instance when modelled as an inline field. Re-setting the UserProfile.user attribute seems to resolve the issue, so do just that. Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #110
* REST: Fix typo in embedded serializersStephen Finucane2018-12-22
| | | | | | | This was preventing the v1.1 fields from getting dropped as intended. Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #237
* REST: Ensure submission exists for comment listingStephen Finucane2018-12-22
| | | | | Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #225
* REST: Ensure patch exists for check creationStephen Finucane2018-12-22
| | | | | Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #226
* REST: Show 'web_url' in embedded series responsesStephen Finucane2018-12-22
| | | | | | Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #224 Fixes: 9c179bf4c ("REST: Add 'web_url' link to API responses")
* docs: Update links for django-rest-framework 3.7, 3.8Stephen Finucane2018-10-18
| | | | | | | Don't you hate it when links break? These release notes haven't been included in a release yet so we can just go ahead and update things. Signed-off-by: Stephen Finucane <stephen@that.guru>
* Add support for Django REST Framework 3.9Stephen Finucane2018-10-18
| | | | | | | As with 3.7 and 3.8, there are no breaking changes we need to be concerned with here. Signed-off-by: Stephen Finucane <stephen@that.guru>
* REST: Allow setting of values using embedded serializersStephen Finucane2018-10-14
| | | | | | | | | | | | | Unfortunately, the use of embedded serializers for some fields breaks the ability to update these fields, either via the HTML interface (where the widget is totally busted) or via a client like 'git-pw'. What we actually want is to be able to update these fields like normal primary key but show them using the embedded serializer. We do just this by using a modified variant of the PrimaryKeyRelatedField and using the serializers simply for displaying. Signed-off-by: Stephen Finucane <stephen@that.guru> Closes: #216
generated by cgit v1.2.3 (git 2.45.0) at 2024-11-21 19:42:42 +0000