I have reformated my proposal content on this group, any suggestion?
Abstract --------------- Django currently assumes that an application will only ever be loaded once, and that the name of that application will be determined solely by the package name holding the models.py. A gread idea has been proposed as a GSOC idea in 2010[1] and continued in 2011[2], which will improve the old app loading mechism a lot, e.g. deploy several instances of the same application, deploy two applications with the same name, support convenient interface for internationalizing application names, etc. However, the [2] branch is not well prepared for being merged to the master branch, and work been made in 2010 and 2011 towards these feathers has made some big changes to current codebase, see[3]. So it's very necessary to check the changes and make sure whether these work can be merged and everything runs smoothly or not after merged. Introduction ----------------- Because the purpose is to check if everything runs ok after merged, so we should know what kind of features current app loading mechanism supports and what kind of improvements 'future' advanced work has made. 1 current app loading features 1) app can be reused in multiple projects 2) reused app can be found by Django in INSTALLED_APPS of settings.py, which is written in dotted path 3) each string in INSTALLED_APPS should be a full Python path to a Python package that contains a Django application, as created by django-admin.py startapp 4) app names must be unique 2 'future' app loading features 1) backward compatibility: 'future' app loading mechanism should support current app loading features well 2) can deploy several instaces of the same application 3) can deploy two applications with the same name,(not have the requirements of unique app name) 4) convenient interface for internationalizing application names 5) good support to rename an application with a name that isn't helpful from a UI perspective While,how to check these above, I think the best tool we can use is unit-test. First, we should check if all the funtions(get_apps, get_app,get_models, etc.) still work after these changes, thus the test cases towards these funtions should be run again to see if all is ok. Second, good use cases should be establised to check if it still supports current features well; we can borrow these use cases from previous work I think. Third, also construct good use cases be used to check if will- be-added features work well after merged, we can reuse the tests new app-loading has offered. But to the unittest point of view, we should pay more attention on the files which has been modified. Specifically, except for the unittest files, in [3], 6 files are added, 20 files are modifiled. Thus one part important work is to check if file changes does make bad or unexpected consequenses or not. Towards unittest files, 21 files are added, 1 file is removed, 6 files are modified, thus we also should check after these changes, whether tests still cover old app loading unit test or not, what's more, cover new features has been implemented in 2010 and 2011 well or not. Detailed Plan: Week 1: Read the source code corresponding with app loading of current Django thoroughly, to know best what current app loading does and how it does Week 2: Read the source code of new app loading code, to check whether it implement the new features interested developers proposed before [4] Week 3: Try to merge and check if old test cases can all be run successfully, and make some necessary improvement work Week 4-5: Establish good use cases to check if old app loading features are all not been destroyed, meanwhile do necessary modification work Week 6: Check all new test cases can be run sucessfully or not, and make some necessary work to help pass all tests Week 7-8: Construct use cases to check how many new features have already been implemented, and if there are some interesting features that should be added, then I can do neccessary coding work Week 9: make up current not well-done coding and tests work to make app loading run perfectly Week 10: Begin to create patches and create/write the documention Week 11-12: Investigate the Django tickets host and contact with corresponding and interested developers to know if there are some necessary work or changes should be added , and if all is ok, try to begin to submit the patches to Django About me: I am a student from China, and have about 3 years Python programming skill and uses Django for 2 years. I love this kind of activity Google has offered and am very interested in communicating with open source guys all over the world. Hope I can make some contributions to Django through this wonderful activity. Email: [email protected] IRC: zennauho Links: [1] https://code.djangoproject.com/wiki/SummerOfCode2010#Apploading [2]https://github.com/jezdez/django/commits/app-loading [3]https://github.com/jezdez/django/compare/master...app-loading [4]https://code.djangoproject.com/wiki/InstalledAppsRevision ------------------------------------------------------- I will appreciate that anyone can make some suggestiones about this proposal. We have all the same purpose to make Django better and better. Best wishes to everyone! nauho -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
