Changes between Version 6 and Version 7 of SummerOfCode2025

Timestamp:

Mar 12, 2025, 4:24:44 PM (8 months ago)

Author:

Timothy Schilling

Comment:

Removing TBC projects as we don't have mentors for them. We may re-add if people volunteer to mentor them for 2025.

SummerOfCode2025

@@ -148 +148 @@
 
 
-== Security: Bring CORS and CSP into core ==
-
-|| Difficulty || Medium
-|| Size || 350hrs
-|| Potential Mentors || TBC
-|| Key Skills || HTTP request-response cycle, middleware, decorators
-
-There are third-party apps providing support for [https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS Cross-Origin Resource Sharing (CORS)] `django-cors-headers` and [https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP Content Security Policy (CSP)] `django-csp`, but it would be good to have support built-in to core.
-
-Following the design of the CSRF/clickjacking protection, having safe defaults, and allowing straightforward per-path customisation, via e.g. decorators, would improve the security of all Django projects.
-
-Outcome would be a pair of PRs adding these into Django. 
-
 == Auto-detection of custom migration operations ==
 
@@ -177 +164 @@
 Expected outcome here would be a PR allowing auto-detection of custom migration operations. 
 
-== Improve the Database Cache Backend ==
-
-|| Difficulty || Medium.
-|| Size ||       350hrs
-|| Potential Mentors|| TBC
-|| Key Skills || Cache Framework 
-
-Setting up a shared cache backend is nearly always required, as many
-third-party packages assume the cache works like this (unlike the default
-locmemcache which is per process). DatabaseCache is the easiest such cache
-backend, not requiring any extra infra and working on shared hosts without a
-filesystem. But it could be better.
-
-Django-Mysql has had a much better DB cache backend implementation since 2015: https://adamj.eu/tech/2015/05/17/building-a-better-databasecache-for-django-on-mysql/ . This has never been adapted for the other supported databases but it should be fairly straightforward, mostly some translation of SQL to different dialects.
-
-Expected outcome would be a PR improvement database cache backend. 
-
-As a stretch goal, it would also be nice to hook the database cache tables into
-migrations somehow rather than the current hacky duck typing approach:
-https://github.com/django/django/blob/64b3c413da011f55469165256261f406a277e822/django/core/cache/backends/db.py#L12-L28 ).
 
 == Expand django-stubs coverage ==
@@ -209 +176 @@
 django-stubs uses Mypy’s stubtest tool to check that its type hints align with Django’s source, per [https://github.com/typeddjango/django-stubs/blob/master/CONTRIBUTING.md#testing-stubs-with-stubtest its contributing documentation]. The “todo” list contains ~1600 functions and classes missing type hints. A proposal targeting a specific, significant subset of the missing types is likely to be accepted.
 
-== Configurable Content Type Parsing ==
-
-|| Difficulty || Medium.
-|| Size || 350hrs
-|| Potential Mentors || TBC
-|| Key Skills || HTTP request-response cycle 
-
-For Django 5.0 we're looking to modernize the `HTTPRequest` object, adding a content-type aware `request.data` property. This will parse `request.body` according to the content type.
-
-The initial phase — targeted for before GSoC — will add `request.data` and add support for JSON body handling, but the next phase is to make that fully pluggable with custom parsers.
-
-- Add a list of parsers to the request object, that can be customised — in a middleware for example — at any point prior to accessing `request.data`.
-- Parsers should implement a `can_handle(content_type) -> Bool` method. The first parser returning True will be selected to parse the `request.body`.
-
-Expected outcome is a PR allowing configurable content type parsing. 
-
-
 == Django Admin: Add Command palette ==