Re: Tagging 1.4 django release in Subversion
On 27/03/12 11:01, Florian Apolloner wrote: > Hi, > > On Tuesday, March 27, 2012 7:09:44 AM UTC+2, Łukasz Rekucki wrote: > > For a moment, I thought we could have some more of that magic and > amend the commits in git, so that "author" would be the patch > contributor and commit author would be the "committer". This should be > possible in most cases, as you only need to map the "Thanks username>" to an email address and github should do the rest. > > Not really possible, or how are you planning to map "Thanks me, you, > someoneelse" to git -- afaik the support only one author field ;) (Aside > from that, I guess the migration is enough work already, so…) And also, even for the single author case, I have very often committed patches where I have made slight or extensive tweaks, and I wouldn't want that code to be attributed to them, since I might have introduced bugs myself. Luke -- "I spilled spot remover on my dog. Now he's gone." (Steven Wright) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: GSOC2012 Proposal for 'Finishing off the App Refactor'
On Monday, March 26, 2012 7:57:02 PM UTC-7, Nauho Zen wrote: > > I have reformated my proposal content on this group, any suggestion? > Thank your for taking the time to consider this project, hopefully you will get some other feedback than just mine - I'm not sure that many projects are worthy of *two* GSOC projects myself. I believe that the baton was somewhat passed to tswicegood at pycon, see: https://github.com/tswicegood/django/commit/241c455d9b8d03144a24f869f819efda031813ba See some other comments below: > > 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 > not sure how this is related to app_loading, it is the case currently > 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 > While I think this should still be true, currently there is the option for an iterable for defining an app, there was an "APP_CLASSES" setting in the branch transiently, but is now gone. I think it would be better to keep INSTALLED_APPS flat and introduce a new setting for configured apps - which could then add their flat representation to INSTALLED_APPS 4) app names must be unique > This is, as far as I can tell from my review, and unresolved limitation in the current branch - that django.contrib.auth and mypackage.auth collide. Seems a duplicate of your #3 below. > > 2 'future' app loading features > 1) backward compatibility: 'future' app loading mechanism should > support current app loading features well > This backwards compatibility is present currently as a set of module level functions at the old location in the db module > 2) can deploy several instaces of the same application > If you see the discussion here: http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879/5045645100f5b8ea?lnk=gst&q=app+loading#5045645100f5b8ea It was determined that this feature was too problematic to tackle as part of app_loading > 3) can deploy two applications with the same name,(not have the > requirements of unique app name) > There remains some room for improvement and clarification about what an app_name is vs app_label vs fully qualified 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 > Some of the above needs clarification. I do think app_loading needs some sort of new push - but I'm dubious that a GSOC would be the way to go. For your detailed plan, I would complete your items for week 1 and 2 before writing a final proposal, not as part of your proposal. -Preston > > 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: zenna...@gmail.com > IRC: zennauho > > > Links: > > [1] https://code.djangoproject.com/wiki/SummerOfCode2010#Apploading > [2]https://github.com/jezdez/django/commi
Re: GSOC2012 Proposal for 'Finishing off the App Refactor'
> Thank your for taking the time to consider this project, hopefully you
> will get some other feedback than just mine - I'm not sure that many
> projects are worthy of *two* GSOC projects myself.
>
I don't know, but I think GSOC still offers a good chance to finish off the
people's valuable work on app loading.
And this idea has been listed on the Django GSOC-Idea page, which has a
little high priority, so I think it may
be a good summer project for student to complete it to a good status. Take
a look at:
https://code.djangoproject.com/wiki/SummerOfCode2012
> I believe that the baton was somewhat passed to tswicegood at pycon, see:
>
>
> https://github.com/tswicegood/django/commit/241c455d9b8d03144a24f869f819efda031813ba
>
>
I will take a good look at it.
>
>> 1 current app loading features
>> 1) app can be reused in multiple projects
>>
>
> not sure how this is related to app_loading, it is the case currently
>
You are right, while what I mean is app_loading allow settting a string in
the INSTALLED_APPS,
thus can allow same app to be used in different 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
>>
>
> While I think this should still be true, currently there is the option for
> an iterable for defining an app, there was an "APP_CLASSES" setting in the
> branch transiently, but is now gone. I think it would be better to keep
> INSTALLED_APPS flat and introduce a new setting for configured apps - which
> could then add their flat representation to INSTALLED_APPS
>
You are very right, the following is a good way:
settings.INSTALLED_APPS = ('django.contrib.auth',
App('django.contrib.admin', name='SuperAdmin'),
App('myapp', name='Wow', db_prefix='pref'))
But I am still not sure I should consider this stuff in this summer
proposal or project, because it has been implemented in a
raw way through the work in 2010 and 2011 I think, what I do is to check if
it can well do this and other good things as expected. However, if it does
not perform well, I still need to enhance the code.
>
> 4) app names must be unique
>>
>
> This is, as far as I can tell from my review, and unresolved limitation in
> the current branch - that django.contrib.auth and mypackage.auth collide.
> Seems a duplicate of your #3 below.
>
OK, there is still not a workaround way?
>
>> 2 'future' app loading features
>> 1) backward compatibility: 'future' app loading mechanism should
>> support current app loading features well
>>
>
> This backwards compatibility is present currently as a set of module level
> functions at the old location in the db module
>
Sounds good.
>
>
>> 2) can deploy several instaces of the same application
>>
>
> If you see the discussion here:
>
>
> http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879/5045645100f5b8ea?lnk=gst&q=app+loading#5045645100f5b8ea
>
> It was determined that this feature was too problematic to tackle as part
> of app_loading
>
A good start point to check if previous work has solved this problem or not
?
>
>
>> 3) can deploy two applications with the same name,(not have the
>> requirements of unique app name)
>>
>
> There remains some room for improvement and clarification about what an
> app_name is vs app_label vs fully qualified name
>
Yes, it can be one part of this summer work if this proposal can be
accepted.
>
>
>> 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
>>
>
> Some of the above needs clarification.
>
> I do think app_loading needs some sort of new push - but I'm dubious that
> a GSOC would be the way to go.
>
I don't know if there is a better way, but I just want to help it move
forward even in one step. If time permits,
work can be continued after summer.
>
> For your detailed plan, I would complete your items for week 1 and 2
> before writing a final proposal, not as part of your proposal.
>
OK, I will spend more time on the week1and week2 work before summer coding
begins.
At last, thank you very much to you for these good suggestions, and I think
it will help me a lot to make a good
proposal and maybe-good project in this summer.
Best regards,
nauho
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
[GSOC Announce] Student application period open
Just a quick note to everyone to say that the student application period for GSOC is now open, and closes on Friday, 6th April. As I've mentioned on this list previously, please discuss your applications with us first so we can give you some feedback rather than just submitting them directly - there's much more detail in my previous post about the GSOC process. Thanks, Andrew -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
Re: GSOC2012 Proposal for 'Finishing off the App Refactor'
On Wednesday, March 28, 2012 at 9:16 AM, Nauho Zen wrote:
> > I believe that the baton was somewhat passed to tswicegood at pycon, see:
> >
> > https://github.com/tswicegood/django/commit/241c455d9b8d03144a24f869f819efda031813ba
> >
>
> I will take a good look at it.
The best place to start is the pull request:
https://github.com/django/django/pull/129
That has the current state of the app-loading branch against Django's master
branch.
Before I go into any further specifics, one thing I want to do (whether this
makes it into GSoC or not) is make sure that we keep the scope reigned in on
this merge. From my point-of-view (and hopefully Jannis will correct me if I'm
off) these are the things this branch should do:
* Introduce the concept of an App object to represent each
* Keep the concept of an `app_label` as just the last part of an app's module
name (example: django.contrib.auth has an app_label of auth).
* Be entirely backwards compatible
The majority of the above work is already done. Right now the two biggest
hurdles to getting the code merged in are:
* Getting the main test suite running again. The tests break spectacularly
with the new code. Some of the failures are tests using internal APIs that
changed, other are valid public APIs that haven't been ported yet. Ideally
this merge should be able to take place without a single test having to be
changed.
* Buy-in from all of the core-devs that this is a needed and/or good change.
All of this said, I'd love for this to be a GSoC project, but I agree Preston
that yet-another-GSoC slot spent on this might not be the best use of the
project's GSoC slots.
> > This is, as far as I can tell from my review, and unresolved limitation in
> > the current branch - that django.contrib.auth and mypackage.auth collide.
> > Seems a duplicate of your #3 below.
> OK, there is still not a workaround way?
There is not a way to work around this. The app-loading branch provides a path
forward, but does not take it. I don't think this pull request should fix this
problem.
Dealing with application conflicts requires a broader design decision on what
constitutes an application's "name": it's app_label
("django.contrib.auth".split(".")[-1]), or it's full name
("django.contrib.auth"). The biggest issue is backwards compatibility -- we
have to keep app_label around for awhile, so we need to deal with both. We
can't immediately switch all table names around to refer to something other
than the app_label.
> > > 2) can deploy several instaces of the same application
> >
> > If you see the discussion here:
> >
> > http://groups.google.com/group/django-developers/browse_thread/thread/4cca2086dd485879/5045645100f5b8ea?lnk=gst&q=app+loading#5045645100f5b8ea
> >
> >
> > It was determined that this feature was too problematic to tackle as part
> > of app_loading
> A good start point to check if previous work has solved this problem or not ?
This is a problem and I recommend punting on it (see above).
-T
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
Re: GSOC2012 Proposal for 'Finishing off the App Refactor'
> Before I go into any further specifics, one thing I want to do (whether this
> makes it into GSoC or not) is make sure that we keep the scope reigned in on
> this merge. From my point-of-view (and hopefully Jannis will correct me if
> I'm off) these are the things this branch should do:
>
> * Introduce the concept of an App object to represent each
> * Keep the concept of an `app_label` as just the last part of an app's
> module name (example: django.contrib.auth has an app_label of auth).
> * Be entirely backwards compatible
>
> The majority of the above work is already done. Right now the two biggest
> hurdles to getting the code merged in are:
>
> * Getting the main test suite running again. The tests break spectacularly
> with the new code. Some of the failures are tests using internal APIs that
> changed, other are valid public APIs that haven't been ported yet. Ideally
> this merge should be able to take place without a single test having to be
> changed.
> * Buy-in from all of the core-devs that this is a needed and/or good change.
>
I will import this important part to my proposal, which will help a lot if I am
accepted to finish off the "App Refactor" work.
> All of this said, I'd love for this to be a GSoC project, but I agree
> Preston that yet-another-GSoC slot spent on this might not be the best use
> of the project's GSoC slots.
>
Well, as a candidate student, I still cann't judge the whole workload
should be paid
in this project and don't know whether if it make the best use of GSoC
slots. However, if because it has been taken as a project in previous
GSOC which make
a similar idea (finish off old work) not that significant to be a 2012
project, then
how about taking it as one part of 2012 work which I may charge if
accepted, and at the same time importing more interesting ideas that
can help my proposal make the best use of our slots?
Travis and Preston, what's your opinion?
> There is not a way to work around this. The app-loading branch provides a
> path forward, but does not take it. I don't think this pull request should
> fix this problem.
OK. I will consider that.
> Dealing with application conflicts requires a broader design decision on
> what constitutes an application's "name": it's app_label
> ("django.contrib.auth".split(".")[-1]), or it's full name
> ("django.contrib.auth"). The biggest issue is backwards compatibility -- we
> have to keep app_label around for awhile, so we need to deal with both. We
> can't immediately switch all table names around to refer to something other
> than the app_label.
OK.
> This is a problem and I recommend punting on it (see above).
OK.
Best regards,
nauho
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
