Tagging 1.4 django release in Subversion
Can a developer please tag the 1.4 release in the SVN repository please? Ie create http://code.djangoproject.com/svn/django/tags/releases/1.4 Looks like it was forgotten... Johan -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/UDO5XqYGNeIJ. 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: metrics: Django case study
Thanks for sharing these results with us. I found them very interesting, and agree that they provide food for thought, and point to areas that might be improved. -Paul On Sat, Mar 24, 2012 at 12:57 AM, Gary Wilson Jr. wrote: > For those interested, I've made available a couple reports from a > class assignment where we analyzed the Django codebase, bug tracker, > and wiki. The motivation of these reports was to answer questions > related to code size, modularity, complexity, unit test coverage, and > component quality. > > Instead of attaching the roughly 3.5MB worth of PDF reports in an > email to the list, I've made the reports available on my website: > http://thegarywilson.com/blog/2012/software-metrics-django-case-study/ > > For the lazy, here are several points mentioned in the papers: > * Since 2005, slightly more than linear growth of source lines of code > (SLOC) and number of files, with a noticeably faster SLOC growth rate > in the last couple years. > * Project started with 11k SLOC in July 2005 and has grown to over 70k > SLOC in Nov. 2011. > * Almost half of the SLOC within Django reside in the contrib package. > * Growth rate of "complex" files (files with at least one function > with cyclomatic complexity greater than 10) has also been nearly > linear over time, but at a lesser rate than the SLOC growth rate. > * Average complexity of files (weighted by SLOC) peaked in 2008 and > has been in a declining trend since. > * 10 files contained at least one function with cyclomatic complexity > greater than 20. > * Percentage of functions and classes with docstrings peaked in May > 2009 near 50% and has been declining since (to near 40% in Nov. 2011). > * Packages with the lowest percentage of classes/functions/methods > with docstrings include: templatetags, http, template, and db. > * 16000 tickets: 63% not categorized. Of the remaining, categorized > tickets: 59% bug/defect, 17% new feature, 15% enhancement, 8% > cleanup/optimization, 1% task. > * Ticket resolution times: At one month after opening 35% of new > feature tickets are closed compared to 50-80% with other ticket types. > * Average defect repair time (i.e. time to ticket close) is 65 days > (though varies from 127 days for tickets categorized as normal to 31 > days for tickets categorized as trivial). In general, average repair > time has steadily decreased over the life of the project. > * The components with the most defects reported are, in order: > documentation, database layer, contrib.admin, and core, which in total > account for almost 60% of all reported defects. > * If taken in aggregate, defects reported for apps in the contrib > package account for about 25% of all defect reports. > * 13% of all tickets submitted have been marked as duplicates. > * When normalized by size (defects per SLOC), core had the highest > defect density by far, followed by the database, forms, and templates > components. > * The most edited wiki page is the "DevelopersForHire" page. > * The wiki consists of 600 pages with an average of 0.26 attachments, > 18.4 revisions, and 32512 characters. > * From 2007 to 2011, code coverage of the unit test suite more than > doubled, from 39% to 90%, with a large increase seen between the 0.96 > and 1.0 releases. > * 59.3% of the non-zero-length modules had 95% or greater test suite > line coverage, and 40.3% had 100% coverage. > > So, I think these reports show that there are some things Django is > doing well at (e.g. test coverage, avg. defect repair time > improvements, avg. complexity), and that there are some areas that > could be targeted for improvement (e.g. components with high defect > counts and densities, docstrings and source comments). > > Thanks, > Gary > > -- > 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. > -- 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 2012] Questions regarding the contrib.auth project
Hi, I would like to participate in this years Google Summer of Code. As a project I would like to tackle Django's beloved auth.User model. The topic has been discussed quite extensively the last days so I won't repeat everything here again. My prefered solution would be "Solution 3" from the ContribAuthImprovements wiki page [1] since it does solve the problem in the most generic way (and I think we should eat our own food once we land app-refactor). Given the current discussions I have the feeling that the discussion is moving toward this solution too -- but I'd like to be sure, so I'd like to see consensus between the core devs (or a BDFL ruling) before I submit a proposal to Google. Thx & Cheers, Florian 1: https://code.djangoproject.com/wiki/ContribAuthImprovements -- You received this message because you are subscribed to the Google Groups "Django developers" group. To view this discussion on the web visit https://groups.google.com/d/msg/django-developers/-/Ex7fJVg-9_kJ. 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: ANNOUNCE: Django 1.4 released
Thank you for the excelent work you have done 2012/3/24 Alec Taylor > Awesome! > > -- > 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. > > -- 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: gsoc proposal, dynamic list form field
But yes thank you Alex, you description is inline with my idea, though I failed to articulate it as eloquently. On Saturday, March 24, 2012, Roy McElmurry IV wrote: > I am working on a better proposal. I will post it here as soo as I can. > > On Friday, March 23, 2012, Alex Ogier wrote: >> Re: Facebook integration. If you want your app to go viral at all, then requiring Facebook permissions the moment someone hits your site is going to put a damper on things. Much better to have it only for actions that require identity, such as adding a recipe or recommending recipes or whatever. >> Anyways, that's not actually the main point of the discussion. I think having a field that encompasses some collection is pretty cool. I have personally made several models in my time that were never intended to be queried individually, but rather just had a single foreign key to a parent model and behaved like a bag of values. The code to manipulate them ends up everywhere: contrib.admin needs StackedInlines, forms need InlineFieldsets, etc. even though the model is really just there to match relational databases' notions about how data is represented. A semantic collection that boils down to an auto-generated table would be very cool; I picture it working something like ManyToManyFields do. The support is already in django core for tables that serve as auto-generated intermediaries. >> Once you have semantic collections as fields, all sorts of things are possible. contrib.admin can provide inlines for free. ModelForms can provide inlines for free. Also, the non-relational fork of Django might be able to take advantage of them. >> I second Russell's request for a better description of what you are proposing exactly, because the concept I constructed for myself doesn't necessarily match your conception. >> -Alex Ogier >> >> -- >> 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. >> > > -- > Roy McElmurry IV > > -- Roy McElmurry IV -- 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: gsoc proposal, dynamic list form field
I am working on a better proposal. I will post it here as soo as I can. On Friday, March 23, 2012, Alex Ogier wrote: > Re: Facebook integration. If you want your app to go viral at all, then requiring Facebook permissions the moment someone hits your site is going to put a damper on things. Much better to have it only for actions that require identity, such as adding a recipe or recommending recipes or whatever. > Anyways, that's not actually the main point of the discussion. I think having a field that encompasses some collection is pretty cool. I have personally made several models in my time that were never intended to be queried individually, but rather just had a single foreign key to a parent model and behaved like a bag of values. The code to manipulate them ends up everywhere: contrib.admin needs StackedInlines, forms need InlineFieldsets, etc. even though the model is really just there to match relational databases' notions about how data is represented. A semantic collection that boils down to an auto-generated table would be very cool; I picture it working something like ManyToManyFields do. The support is already in django core for tables that serve as auto-generated intermediaries. > Once you have semantic collections as fields, all sorts of things are possible. contrib.admin can provide inlines for free. ModelForms can provide inlines for free. Also, the non-relational fork of Django might be able to take advantage of them. > I second Russell's request for a better description of what you are proposing exactly, because the concept I constructed for myself doesn't necessarily match your conception. > -Alex Ogier > > -- > 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. > -- Roy McElmurry IV -- 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: ANNOUNCE: Django 1.4 released
Thanks for your hard work ! -- 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.
metrics: Django case study
For those interested, I've made available a couple reports from a class assignment where we analyzed the Django codebase, bug tracker, and wiki. The motivation of these reports was to answer questions related to code size, modularity, complexity, unit test coverage, and component quality. Instead of attaching the roughly 3.5MB worth of PDF reports in an email to the list, I've made the reports available on my website: http://thegarywilson.com/blog/2012/software-metrics-django-case-study/ For the lazy, here are several points mentioned in the papers: * Since 2005, slightly more than linear growth of source lines of code (SLOC) and number of files, with a noticeably faster SLOC growth rate in the last couple years. * Project started with 11k SLOC in July 2005 and has grown to over 70k SLOC in Nov. 2011. * Almost half of the SLOC within Django reside in the contrib package. * Growth rate of "complex" files (files with at least one function with cyclomatic complexity greater than 10) has also been nearly linear over time, but at a lesser rate than the SLOC growth rate. * Average complexity of files (weighted by SLOC) peaked in 2008 and has been in a declining trend since. * 10 files contained at least one function with cyclomatic complexity greater than 20. * Percentage of functions and classes with docstrings peaked in May 2009 near 50% and has been declining since (to near 40% in Nov. 2011). * Packages with the lowest percentage of classes/functions/methods with docstrings include: templatetags, http, template, and db. * 16000 tickets: 63% not categorized. Of the remaining, categorized tickets: 59% bug/defect, 17% new feature, 15% enhancement, 8% cleanup/optimization, 1% task. * Ticket resolution times: At one month after opening 35% of new feature tickets are closed compared to 50-80% with other ticket types. * Average defect repair time (i.e. time to ticket close) is 65 days (though varies from 127 days for tickets categorized as normal to 31 days for tickets categorized as trivial). In general, average repair time has steadily decreased over the life of the project. * The components with the most defects reported are, in order: documentation, database layer, contrib.admin, and core, which in total account for almost 60% of all reported defects. * If taken in aggregate, defects reported for apps in the contrib package account for about 25% of all defect reports. * 13% of all tickets submitted have been marked as duplicates. * When normalized by size (defects per SLOC), core had the highest defect density by far, followed by the database, forms, and templates components. * The most edited wiki page is the "DevelopersForHire" page. * The wiki consists of 600 pages with an average of 0.26 attachments, 18.4 revisions, and 32512 characters. * From 2007 to 2011, code coverage of the unit test suite more than doubled, from 39% to 90%, with a large increase seen between the 0.96 and 1.0 releases. * 59.3% of the non-zero-length modules had 95% or greater test suite line coverage, and 40.3% had 100% coverage. So, I think these reports show that there are some things Django is doing well at (e.g. test coverage, avg. defect repair time improvements, avg. complexity), and that there are some areas that could be targeted for improvement (e.g. components with high defect counts and densities, docstrings and source comments). Thanks, Gary -- 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.
