The description of that project needs to be updated as I don't think it accurately reflects a direction we want to go. A goal might be the ability to use django.forms without the rest of Django, but there's no need to break django.forms into a separate repository to make this possible. In fact, doing so would probably create a lot of chaos. For example, if a change requires modifying both django/forms/forms.py and django/forms/models.py, then it would require coordinating two patches in two separate repositories and how you can you run CI on that combination of pull request? Similar issues with removing other parts like django.utils.
So if one of your project's goals is to allow using django.forms without the rest of Django, then for your proposal you need to research what the current obstacles are for doing so (dependency on settings, for example), and then explain the solution you will implement to allow this. I don't think there's strong or desire to remove any of the current contrib apps (some have already been removed recently). By the way, have you contributed to Django before? Your odds of acceptance are greatly enhanced if you have a track record of producing good patches (and it will also help you write a better proposal, I think). On Monday, February 2, 2015 at 11:46:25 AM UTC-5, Asif Saifuddin wrote: > > Hi Josh, > > There are two technical problems that need to be solved in order to make > this happen. > > - Implement the packaging definitions to allow for multiple packages. > - Clean up dependencies between components. Despite the best of > intentions, there are some interesting dependencies between modules, some > of which may need to be clarified or separated. > > The aim of this project would be to clean up one or more of Django's > internal "parts" so that it could be delivered as a standalone package. > This may not be something that can be immediately delivered - for example, > it may be necessary to move or rename components to enable separate > packaging. In this case, the project deliverable would be to document the > strategy, and provide whatever initial moves in that direction are possible. > > A simpler version of this project would be to enable separate packaging > and distribution of Django's contrib apps. > > alongside reduce tight coupling how should I approach to following part? > > "A simpler version of this project would be to enable separate packaging > and distribution of Django's contrib apps." > > > I am looking for dev teams suggestions > > > ./auvipy > > > > > > On Mon, Feb 2, 2015 at 9:58 PM, Asif Saifuddin <auv...@gmail.com > <javascript:>> wrote: > >> Hi Fabio, >> >> Thank you for your project ideas. I'm going to follow the ideas from >> https://code.djangoproject.com/wiki/SummerOfCode2015 >> >> >> for your babel porting probably Aymeric Augustin's template refactor >> project have some plan with babel integration, but I'm willing to work on >> reduce decoupling/Improve template dispatching for first priority from my >> side till now. >> >> >> Regards >> >> ./auvipy >> >> On Mon, Feb 2, 2015 at 9:39 PM, Fabio Caritas Barrionuevo da Luz < >> bna...@gmail.com <javascript:>> wrote: >> >>> Some ideas. (which still require approval of the core developers): >>> >>> >>> * Improve database backend base API and related features(including >>> introspection feature used by inspectdb), so that it is less complicated to >>> add in the future support the specific features of some backends. eg >>> multiple database schemas (common used in Oracle and PostgreSQL) and/or >>> Oracle synonym tables >>> >>> * port Django i18n and i10 and related translation features to use >>> Babel: http://babel.pocoo.org/ >>> >>> >>> >>> Em terça-feira, 27 de janeiro de 2015 14:15:20 UTC-3, Asif Saifuddin >>> escreveu: >>> >>>> Hi, >>>> >>>> Although probably It's quite very early to ask about GSOC 2015 in >>>> January, I would like to start analyzing to prepare myself for choosing a >>>> correct project and submitting a good proposal for that to get selected. I >>>> haven't found any GSOC 2015 project ideas pages yet. But got some older >>>> idea pages of year 2013 and 2014. Should I look forward to the ideas that >>>> were unimplemented or wait for gsoc 2015 wiki ideas page? >>>> >>>> ./auvipy >>>> >>> -- >>> You received this message because you are subscribed to a topic in the >>> Google Groups "Django developers (Contributions to Django itself)" group. >>> To unsubscribe from this topic, visit >>> https://groups.google.com/d/topic/django-developers/WF3My-cZNtY/unsubscribe >>> . >>> To unsubscribe from this group and all its topics, send an email to >>> django-develop...@googlegroups.com <javascript:>. >>> To post to this group, send email to django-d...@googlegroups.com >>> <javascript:>. >>> 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/cbb457c7-66cb-4370-99de-c9cfcd2a5622%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-developers/cbb457c7-66cb-4370-99de-c9cfcd2a5622%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> > -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/25e8f58e-9b1b-4f20-bdb1-647244eb0d1a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
