The author discusses these points in the about page, but for me, does not sufficiently address them.
My experience of contributing to Django does not match theirs, and I don't feel this page sufficiently justifies this being a fork. In fact it actually makes me suspect that Plain will/has diverged enough that it won't be able to pull in changes from Django. As a user this would concern me, as Django ships meaningful changes regularly, as well as having a mature approach to security disclosures.
I have disclosed vulnerabilities in Django and they were handled very well and quickly. I actually went to see if Plain was vulnerable to the issue I disclosed, but my issue was around the memcached integration, and it seems Plain has completely removed all caching (except from a database-backed cache), making it in one way less batteries-included than regular Django. This puzzles me, for a project that is all about including more batteries, and as a potential user would lead me to further question the project.
Upstreaming to Django becomes very hard because he's moved stuff around. Also, switching to plain just to try it out becomes super hard because of this same thing. The idea of having a faster moving fork makes sense, but this isn't it.
Agreed. The about page also says that the plan is to update Plain to include new Django changes, but that would also be hard.
Django has a "contrib" package. I could see a fork with a fast moving contrib directory, or even just the Django project doing that with an explicit call-out for that package having a different set of breaking change expectations. A bunch of features started in contrib and graduated out of it over time, would be nice to keep that going.
I understand the frustrating with Django progress (and, to be honest, I would like for Django to more agressively upstream stuff).
I'm curious about what he would want to get into Django that feels like he couldn't though. Since this _is_ a fork of Django, he's still gonna hit a lot of issues that people wanting to improve Django hit.
Backwards compat is an issue, but "all of this code within the library is built off of existing assumptions" is _also_ an issue.
If all the improvements could be third party packages, just making plain be a big third party omnipackage that also has a helper to "fix" settings feels like it would go a long way.
My experience of contributing to Django does not match theirs, and I don't feel this page sufficiently justifies this being a fork. In fact it actually makes me suspect that Plain will/has diverged enough that it won't be able to pull in changes from Django. As a user this would concern me, as Django ships meaningful changes regularly, as well as having a mature approach to security disclosures.
I have disclosed vulnerabilities in Django and they were handled very well and quickly. I actually went to see if Plain was vulnerable to the issue I disclosed, but my issue was around the memcached integration, and it seems Plain has completely removed all caching (except from a database-backed cache), making it in one way less batteries-included than regular Django. This puzzles me, for a project that is all about including more batteries, and as a potential user would lead me to further question the project.