> > This year was interesting. Sage in particular did well putting together a > cross-db JSONField, but he was probably under-mentored, > since Mariusz has spent quite a bit of time reworking the PR, and still > has a bit to go, before we can pull it in, hopefully for 3.1 > > So, one consideration we need to think about seriously is our capacity for > mentoring. (This isn't just about the candidate's ability — Sage was able > to implement all suggestions — we just didn't have as much capacity as we > might have liked to think about the requirement implementation — and there > were four of us actively giving some time each... — Anyhow, to think > about.) >
I think your analysis is pretty accurate Carlton. Sage was a pretty self-motivated candidate, writing some great blog posts about his code, and we still didn't manage to merge his PR. Perhaps the project was larger than we can reasonably expect? Nice work on the descriptions there Andrew. Django Service Hooks > I think a key use case of this is background task processing. Nearly all the Django integrated libraries need to remember to "connection.close()" / "close_old_connections" at the end of requests. I've seen a couple in-house ones that needed this. That said I can't think of much else to go inside the "service hook"? There's not much else to "the end of a Django context" at the moment is there? Evented Datastores > I'm not sure if other databases have it but MariaDB recently implemented "temporal tables" which are an SQL standard way of doing historical views on data: https://mariadb.com/kb/en/library/temporal-data-tables/ Admittedly not quite the same as event sourcing but perhaps easier to implement given it would be limited to the ORM layer. Django Benchmarking > I love djangobench, and do wish it was maintained and expanded. Running on CI would be amazing. 2FA also sounds like a great idea. Other ideas: - Support MySQL/MariaDB storage engines. I think other databases tend to support some table-level customizations to. - Official CORS middleware/view decorator. I took over maintenance of https://github.com/adamchainz/django-cors-headers and its design is a bit pants. On Sat, 14 Dec 2019 at 17:30, Andrew Godwin <and...@aeracode.org> wrote: > Here's my take on each of these, leaving out async as that'd be more > dependent on where we were: > > Secrets Manager > Many environments Django is deployed in use a separate secrets manager to > store and provide secrets per environment - either as environment > variables, files, or via a direct HTTP API. The project would be to design > and add an abstraction interface over secrets managers that allows users to > easily map to an external secret in a settings file. There's also room for > giving Django a better, built-in per-environments settings option too, > pulling from popular third-party patterns. > > Django Service Hooks > Django has a lot tied to the HTTP lifecycle, and if you run it outside of > this, you miss out on some key things - like database connections being > closed properly, or logging, or some middleware. The project would be to > design and implement a separate way of calling Django from a service > framework - even if that framework was itself HTTP based (basically, don't > rely on Django having to run through WSGI/ASGI). Initial idea is to provide > a context manager that replaces the wrapping of a request, but the project > would have to include requirements-gathering and interviewing people who > use Django to power microservices to work out what they want. > > Evented Datastores > Evented, or event-sourcing, database schemas are growing in popularity - > essentially, a way to implement an append-only pattern on top of a > relational database, where every single event that has happened is stored, > but you can still efficiently retrieve the current state of an item. Given > the way the pattern works, this would be possible to implement on top of > Django models - likely as a whole new Model subclass - and implement with a > matching QuerySet/Model API. It would require someone very skilled in > database design, and it's also arguable if it should be in Django itself, > or comprise of developing a third-party app alongside adding hooks/fixes to > the Django ORM where needed to make it work well. > > GraphQL > Basically, work on an "official" graphql-to-ORM mapper for Django, > probably re-using a considerable amount of third-party work. This one could > really vary in its application, based on how much other "API-ish" work the > project includes (given that Django REST Framework is still separate, we > should follow that rough pattern). > > Plus, some bonus ones that aren't Django code itself: > > Django Case Studies > Our long-talked-about website which brings together case studies and white > papers about why people choose Django, aimed at companies working out what > they want to choose. This is likely only some coding and a lot of > writing/legwork, so may not be a good fit for GSOC, but should be on any > future plan we have. > > Django Benchmarking > Django has had a benchmarking suite for a while, but we've generally got > more slack at tracking the effects each commit and release has. We should > institute a set of top-level benchmarks aimed at various areas (the current > set in djangobench are weak in, say, the HTTP-serving-speed area) and then > run them against pull requests and each release, so we can make sure Django > doesn't get slower while nobody is looking. > > I'm sure there's a lot more, but these are top of mind at the moment! > > Andrew > > > On Tue, Dec 10, 2019 at 11:52 AM Carlton Gibson <carlton.gib...@gmail.com> > wrote: > >> Hey Andrew. >> >> Yes, Async, of course. It's not until *next July* so I'd still think we >> should list this. Worst case is there's exactly zero progress between now >> and decision day, in which case you could say that we could only accept a >> clearly capable candidate. (Jannis was once our GSoC person, so... :) >> >> The other ideas seem good: the secrets manager abstraction is a nice one >> (!) >> >> No rush, but when you have a moment, perhaps you could draft a couple of >> paragraphs for each? (Even if they don't go to GSoC directly, it would come >> in handy for the TB's direction guidance...) >> >> Kind Regards, >> >> Carlton >> >> >> On Tuesday, 10 December 2019 19:14:51 UTC+1, Andrew Godwin wrote: >>> >>> I agree that 2FA could be a good choice - some of the async support work >>> would also have been good, had I made more progress in the latter half of >>> this year. >>> >>> A couple of other ideas for big projects: >>> >>> * A secrets manager abstraction and built-in support for Vault, KMS, and >>> other common ones >>> * A proper story and hooks for running Django as a service (i.e. outside >>> of a traditional HTTP request/response cycle) >>> >>> And some ludicrous projects I'd still consider: >>> >>> * Evented/event-sourcing database work on top of the ORM >>> * A GraphQL-to-ORM mapper >>> >>> Andrew >>> >>> >>> On Tue, Dec 10, 2019 at 8:25 AM Carlton Gibson <carlto...@gmail.com> >>> wrote: >>> >>>> Hi all. >>>> >>>> It's time to start thinking about Google Summer of Code (GSoC). If >>>> we're going to participate and projects we might propose. >>>> >>>> This year was interesting. Sage in particular did well putting together >>>> a cross-db JSONField, but he was probably under-mentored, >>>> since Mariusz has spent quite a bit of time reworking the PR, and still >>>> has a bit to go, before we can pull it in, hopefully for 3.1 >>>> >>>> So, one consideration we need to think about seriously is our capacity >>>> for mentoring. (This isn't just about the candidate's ability — Sage was >>>> able to implement all suggestions — we just didn't have as much capacity as >>>> we might have liked to think about the requirement implementation — and >>>> there were four of us actively giving some time each... — Anyhow, to think >>>> about.) >>>> >>>> Then it's projects. There are three that I have on my list that would >>>> require a "competent candidate": >>>> >>>> 1. Work on the migrations. Markus mentioned a particular ticket here >>>> but... >>>> 2. Make the parallel test runner work on Windows. ("fork" vs "spawn") >>>> >>>> And 3, and this is the big one: >>>> >>>> 3. Add 2FA to Django. >>>> >>>> This has been raised a few times: >>>> >>>> * >>>> https://groups.google.com/d/topic/django-developers/T-kBSvry6z0/discussion >>>> * >>>> https://groups.google.com/d/topic/django-developers/d92P2V0YrbI/discussion >>>> >>>> * ... others... >>>> >>>> If I'm honest, in 2020, it's the one "battery" I feel a little bit >>>> embarrassed we haven't got a story for. Maybe it's not possible in a GSoC >>>> type scope but... >>>> — What would it look like? What can we leverage? Is it worth a go? >>>> >>>> I'm looking at James, Florian, Joe, ... — who else has been keen here? >>>> I'm also looking at the Technical Board, which I'm thinking has (will >>>> have) a new guiding role to come up with suggestions for the direction of >>>> Django. >>>> >>>> >>>> Other Projects: Are there other ideas? (Do you have one?) Are there >>>> easier things that we could take "weaker" candidates for? But with that is >>>> there a commitment for the mentoring help they'd need? >>>> >>>> Anyhow, we have until January, so I'm just starting the discussion >>>> here. >>>> >>>> Kind Regards, >>>> >>>> Carlton >>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Django developers (Contributions to Django itself)" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to django-d...@googlegroups.com. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/django-developers/af075d59-ece3-4044-9204-b690c746b9e0%40googlegroups.com >>>> <https://groups.google.com/d/msgid/django-developers/af075d59-ece3-4044-9204-b690c746b9e0%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Django developers (Contributions to Django itself)" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to django-developers+unsubscr...@googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/django-developers/e1818353-9fa0-4e49-a6e9-4757f06c7e19%40googlegroups.com >> <https://groups.google.com/d/msgid/django-developers/e1818353-9fa0-4e49-a6e9-4757f06c7e19%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> > -- > You received this message because you are subscribed to the Google Groups > "Django developers (Contributions to Django itself)" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to django-developers+unsubscr...@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/django-developers/CAFwN1uqaniLZayw19gKOzEi3KT2EqD8VD-3%3Dd77FExQaYEUVYw%40mail.gmail.com > <https://groups.google.com/d/msgid/django-developers/CAFwN1uqaniLZayw19gKOzEi3KT2EqD8VD-3%3Dd77FExQaYEUVYw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- Adam -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAMyDDM1q2xG8Y_xd-GCBiyam6nSiuY8cHXLt9T18nj-KkDVZ5Q%40mail.gmail.com.
