Re: DEPs (was: Making Django more PaaS-friendly)

[Andrew Godwin]

On Tue, May 10, 2016 at 1:58 PM, Aymeric Augustin <
aymeric.augus...@polytechnique.org> wrote:

> On 10 May 2016, at 19:18, Carl Meyer  wrote:
>
> > I would say that a DEP is generally a good idea if the people working on
> > the feature feel that it would be helpful to them to organize and record
> > the various design decisions
>
> DEPs have the additional advantage or drawback, depending on your
> perspective,
> of raising the bar for arguing about the design. The first step is to read
> 10
> to 20 pages, and perhaps a bunch of other sources they reference.
>
> Compared to the traditional process, which simply consists in ranting on
> this
> mailing-list based on partial data and approximate assumptions, DEPs take
> all
> the fun away ;-)
>
> (More seriously: discussions are rarely very bad here, however I believe
> that
> a DEP makes them much more efficient once a certain amount of complexity is
> reached, because the DEP provides a consolidated vision of the discussion.)
>

I'd like to agree with this point strongly - having a centralised place
that outlines the entire approach and all the discussion around it seems
invaluable for larger features, and would have been Nice To Have given
recent events.

Andrew

-- 
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/CAFwN1uouyxp2tMn1qffyQk%3Dr_mP99SUmtGiMQ7HN-dfvGNxHuA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: DEPs (was: Making Django more PaaS-friendly)

[Aymeric Augustin]

On 10 May 2016, at 19:18, Carl Meyer  wrote:

> I would say that a DEP is generally a good idea if the people working on
> the feature feel that it would be helpful to them to organize and record
> the various design decisions

DEPs have the additional advantage or drawback, depending on your perspective,
of raising the bar for arguing about the design. The first step is to read 10
to 20 pages, and perhaps a bunch of other sources they reference.

Compared to the traditional process, which simply consists in ranting on this
mailing-list based on partial data and approximate assumptions, DEPs take all
the fun away ;-)

(More seriously: discussions are rarely very bad here, however I believe that
a DEP makes them much more efficient once a certain amount of complexity is
reached, because the DEP provides a consolidated vision of the discussion.)

-- 
Aymeric.

-- 
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/5DB56C87-8DE1-450F-8F97-60E909D02F65%40polytechnique.org.
For more options, visit https://groups.google.com/d/optout.

Re: DEPs (was: Making Django more PaaS-friendly)

[Carl Meyer]

Hi Anssi,

Thanks for the clarification, that all makes sense. A few comments below:

On 05/10/2016 12:00 AM, Anssi Kääriäinen wrote:
> It's not so much the DEPs that have been written (though the channels
> DEP is going to be post-design instead of supporting the design). It's
> more about those features that don't have a DEP at all. For example
> database schemas and subquery expressions come to mind (these are
> ongoing work, PRs available at GitHub). There are various design
> choices and the features are somewhat significant, yet the design
> hasn't been at all DEP driven.

I would say that a DEP is generally a good idea if the people working on
the feature feel that it would be helpful to them to organize and record
the various design decisions, or if people in the community are
expressing concern about the feature or there's significant disagreement
about the design decisions that isn't quickly and easily resolved. When
there's a proposal to change a core aspect of Django in a pretty
fundamental way (like with multiple-template-engines or middleware),
that's a good case to just start out right away with a DEP, because it's
important to make really sure the community is on board with the change.
Again, I think DEPs ideally should be a useful tool, not a hoop to jump
through.

> Also, having DEP requested for channels only at this point, and Andrew
> (a technical board member) assuming a DEP wasn't required should point
> out there might be a problem. This is not to criticize Andrew but the
> way DEPs are sometimes required, sometimes not.

I didn't intend to be "requiring" a DEP for channels as some kind of
pro-forma dotting of the I's and crossing of the T's for a decision that
in practice had already been made; if that's how my message in that
thread came across, then I miscommunicated. I (strongly) suggested a
DEP, because when I looked back at e.g the discussion thread from
December I saw a number of concerns expressed about channels that still
didn't seem to me to have been resolved (and it also seemed clear from
messages from you and Mark that they weren't) and it seemed to me that
channels still needed the sort of focused public resolution of questions
and concerns that a DEP discussion can provide.

But it's quite possible I was just wrong in that suggestion. If in fact
all the important decisions are already made, and the only thing
channels really needs to address the concerns is real-world proving and
testing, then perhaps a DEP at this point is a waste of time. (Though a
DEP could also be a useful place to record and summarize the discussion
around the results of such real-world testing.)

> I'm not seeing a problem with the DEP idea in general, with any
> particular DEP or with any single feature having or not having a DEP.
> I'm criticizing the approach where sometimes patches are called out
> randomly for DEP, often at a point where the DEP is just documenting
> what has been already decided, not supporting the decision process
> itself.

Yeah, I certainly agree that the way it worked out for channels wasn't
ideal.

> I probably picked the wrong thread to complain about this - if we are
> going to want DEPs for features similar to the ideas discussed in this
> thread, then the timing for requesting a DEP was accurate.

Agreed.

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/573217E2.4010702%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature