On 05/05/2016 04:37 PM, Andrew Godwin wrote: > To be honest, I had entirely forgotten the DEP process existed until > this thread started up; I'm not sure what to blame this on, but as a > member of the tech board I haven't got an email about approving a DEP > since last October, so it's been a while.
There has been more recent activity on several in-progress DEPs on this mailing list, but it has been a while since one was accepted. > Part of me does not want to aggravate my RSI by having to write and rush > through a DEP in the next 10 days, but I can't deny that you are likely > correct that it sends the right signal given that we have the process in > place. > > That said, a couple of decently-sized features (full text search, > password validators) have landed recently without one, so I can't > entirely feel justified dropping this from 1.10 given that it is fully > written, has extensive documentation, a mostly-complete test suite and > several fully-worked examples - far more context than a DEP would ever > provide. It would feel like a bit of a kick in the teeth, to be honest. I've no desire either to aggravate your RSI or kick you in the teeth! I understand the multiple competing pressures here and won't stand in the way of a merge into 1.10 sans DEP if that still seems like the best path forward to you. It's not like a merge into alpha is the end of the line in terms of possible design changes or updates (or even possibly reverts). A DEP could even happen post-merge; that would be unusual but perhaps still better than none at all. I have a couple more comments, more in the line of general thoughts about the whys and hows of DEPs. I do think that DEPs have a significant value that goes beyond just providing information that could be found elsewhere (e.g. in the channels documentation). They collect that information (or references to it) in one place, in a standard digestible format, and formally present it to the community as a requested change, with rationale and rejected alternatives (including a fair representation of the objections that have been raised and your answers to them), and present a formal opportunity for anyone with concerns to raise them (and give you a reasonable place to later say "this is precisely when you should have raised your concerns if you had them") and then also store that in a stable place for future reference when someone comes by in two years and can't understand why we did things the way we did. (I'm not saying this to put further pressure on, just to defend the DEP process against the implicit charge that it's possibly-useless make-work when other documentation has already been written.) There's been no clear delineation of what size features should have a DEP. I think channels, multiple-template-engines, and reworked-middleware (and migrations, for that matter) are all rethinkings of long-standing core aspects of how Django works, which in my mind makes them prime DEP candidates, whereas FTS and password validation both seem to me like small-to-medium peripheral features that I wouldn't necessarily have expected to have one. Carl -- 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 post to this group, send email to django-developers@googlegroups.com. Visit this group at https://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/572BD5AB.1050007%40oddbird.net. For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
