Hi, On Tuesday, 2 June 2015 11:25:14 UTC+2, Andrew Godwin wrote: > > Hi Emil, > > I agree that there perhaps needs to be a more "pull" here than just making > a third party app, but I feel I can speak from a good place when I say > third party apps can absolutely prove core Django features in a way that > gives them much faster release cycles and freedom from things like LTS > commitments initially, so they can be rapidly improved upon before being > deemed worth merging. The alternative is either merging something into core > that's not ready, dooming it to a slow release cycle and perhaps community > pushback, or developing it as a parallel branch which is not something > that's going to be long-term sustainable. >
With "pull" I mean someone saying "I think this is something that would fit well with Django, given that it's implemented in a way that satisfied X, Y and Z". I'm of course not saying "merge my code now" when there is no code :) So this should definitely be a third party app first. I also see how you must have great trust in the model that South was developed under. You built something great, *everyone* started using it, you put down months of work into rewriting it for Django, and it's now part of the handful (?) of third party projects that made it into core. So it is possible, but just not very likely. > This problem has been something I've been wanting to tackle for a while > now - I've always felt that the next step for Django is to start moving > away from being so married to the request-response cycle of traditional > HTTP - and I've been formulating a plan over the last few months about how > to tackle it. It's relatively ambitious, but I think entirely achievable > and would be almost completely backwards-compatible. Unfortunately, it's > taken a while to get over the 1.7 release cycle and migrations work being > slightly overwhelming, or it would have been sooner. > Hearing that you are interested in working on the "async problem" makes me very happy. And solving async "generally" would of course satisfy the same problem I'm hoping to solve with my parallel process approach. Really looking forward to this. > I'm sounding out some of the ideas here at DjangoCon Europe, and hopefully > come to the list with an initial proposal or implementation soon - I think > the best way to approach this is to sit down and design the API and core > code architecture, start proving it's possible, and then present that, > because in my experience having code examples can really make a proposal a > lot easier to understand. Of course, I'm also fully prepared for people to > shoot down my ideas - being a core team member doesn't give me some magical > ability to push through changes. > I'll take the code example lesson with me for next time :) Looking forward to read you proposal. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/c9117ec9-de61-4480-a09a-8d648e7ecbc8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
