Re: Django/Python Job
On Mon, Nov 29, 2010 at 9:27 PM, Bita Bita wrote: > My client is in a immediate need for a front end engineer whi knows > Django, Python, AJAX, and/or html5 . This is a full time position with > a really good pay in Palo Alto, CA. Sent me your updated resume if > interested. You're on the wrong group; you want django-users: http://groups.google.com/group/django-users django-developers is for discussion about developing Django itself, not for using it as a web developer. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Ticket #12248 (moving django.template.__init__ contents to django.template.base)
On Fri, Nov 26, 2010 at 8:38 PM, Russell Keith-Magee wrote: > Ok - looks like I had a couple of seriously loose screws last night. > I'll take another look today. Apologies for the confusion. I noticed that you merged the change in — thanks! I saw that you explicitly imported the names that used to live in django.template.__init__ instead of simply doing "from django.template.base import *" like I had, and I think that yours is the better solution there; it only brings in what used to live in __init__ (and thus is required for backward compatibility) without further polluting the __init__ namespace unnecessarily. Now I feel like I can hack on the django.template module without going crazy. :-D -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Pluggable encryption for django auth (design proposal)
On Sun, Nov 28, 2010 at 12:11 PM, Christophe Pettus wrote: >> I'm not arguing that a salt helps against brute-forcing a *single* >> password (it doesn't), but it does in fact help against someone trying >> to brute-force your entire password database (or any subset of more >> than one password), since each password with a different salt lies >> within an entirely different space that must be brute-forced >> separately from the rest. > > I'm not sure what you mean by the "space"; I think you are thinking of a > rainbow dictionary attack, where the hashes are precomputed; a salt does > indeed help (and probably blocks) that kind of attack. In the case of a > straight brute-force attack or a standard dictionary attack without > precomputing, the only benefit of the salt is that it makes computing the > candidate hash a bit longer, based on the length of the salt. It's a trivial > amount of time. > > Remember, it's extremely inexpensive to brute-force a single MD5 or SHA1 > hash, and the salt does not make it appreciably more expensive. If a CUDA > application can brute force 700 million MD5s per second, doubling the length > is not really going to make it any more secure. No, I'm not thinking of rainbow tables. The key word here is *single*. As I said before, a salt *does* help against an attacker trying to brute-force multiple passwords from your database, since he can't simply test each brute-force result against all your passwords at once; he has to start all over from scratch for every single password that has a different salt. If he only cares about one *particular* account, the salt doesn't help, no. But regardless, I apologize for derailing this conversation so far off. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Pluggable encryption for django auth (design proposal)
On Sun, Nov 28, 2010 at 12:19 AM, Christophe Pettus wrote:
> Let's do the math. The space of eight alphanumeric character passwords is
> 2.8e12. Even assuming you can cut two orders of magnitude off of that with
> good assumptions about the kind of passwords that people are picking, this
> means that the attacker has to run about 28 billion times more computations
> that you do. At 10ms per password, it would take them about 447.8 years to
> crack a single password, assuming hardware of equivalent speed.
The point is that I'm *not* assuming hardware of equivalent speed.
I'm assuming that a worst-case attacker has hardware significantly
faster than your webserver at their disposal, so I was curious if the
purported benefit still held in that case. Maybe it does; I don't
know.
>> It does in fact slow down brute force attacks against multiple
>> encrypted passwords; each password with a different salt is within an
>> entirely different space that needs to be brute forced separately from
>> the other passwords.
>
> Remember how a brute force attack works. Given a hash x, the attacker does:
>
> hash('' + salt) = x? No, then,
> hash('0001' + salt) = x? No, then,
> ...
>
> The only benefit of the salt here is that it makes the string to be hashed a
> bit longer, but the benefit is linear, not exponential.
I'm not arguing that a salt helps against brute-forcing a *single*
password (it doesn't), but it does in fact help against someone trying
to brute-force your entire password database (or any subset of more
than one password), since each password with a different salt lies
within an entirely different space that must be brute-forced
separately from the rest.
> Anyway, back to the discussion of the actual proposal. :)
Sure, I didn't mean to veer things too far off course here; even
assuming the bcrypt argument doesn't hold, it's entirely possible that
someone may want to easily plug in SHA512/SHA3/whatever into their
password encryption.
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@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: Pluggable encryption for django auth (design proposal)
On Sat, Nov 27, 2010 at 11:47 PM, Christophe Pettus wrote: > Actually, no, the situations are really quite asymmetrical. In order to > brute-force a password, an attacker has to be able to try many, many > thousands of combinations per second. To log in a user, an application has > to do it exactly once. A hash computation time of, say, 10ms is probably > unnoticeable in a login situation, unless you have tens of thousands of users > logging in per minute (and if this is the case, then you probably have other > problems than the speed of your password hash algorithm). But that would > pretty much slam the door down on any brute force attempt at a password > recovery. But how far are you willing to go in your assumption of the worst-case computational ability of your attacker? Would tuning the hash to (say) a 10ms delay for your web server's modest hardware translate into a significant delay for an attacker with far more resources? (This isn't a rhetorical question; I honestly don't know.) > A salt is of no benefit on a brute force attack; it's function is to prevent > dictionary attacks, which are a different animal. It does in fact slow down brute force attacks against multiple encrypted passwords; each password with a different salt is within an entirely different space that needs to be brute forced separately from the other passwords. > And if you are willing to assume that no attacker can ever get access to your > database, then you don't have to hash the password at all. Sure, but my point was that there are various walls you can throw up against attackers to slow them down that don't involve slowing down your hash algorithm. > But, as you point out, that's a separate discussion from the value of > pluggable encryption algorithms. Right; I didn't mean to dissent from (or concur with) that proposal. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Pluggable encryption for django auth (design proposal)
On Sat, Nov 27, 2010 at 10:14 PM, Christophe Pettus wrote: > Right now, Django's auth system pretty much uses sha1 hardwired in > (literally, in the case of User.set_password) for the hash. For a discussion > of why a general-purpose hash function is not the best idea in the world for > password encryption, see: > > http://codahale.com/how-to-safely-store-a-password/ Completely leaving aside the potential benefit of allowing different hash algorithms, I think the specific argument made by the author of that article, along with their proposed solution of an "intentionally slow" algorithm, is the wrong approach. Your application ends up just as hobbled by such an algorithm as a potential attacker. If you're choosing a slowdown factor based on your worst-case attacker, you're likely to significantly impair the ability of a website running on hardware that's not as fast, especially if you're authenticating users all the time. I think there are better potential solutions to concerns about password cracking. Django already salts the hashes, which is asymmetrical in a good way: it helps complicate brute force attacks without slowing down Django's ability to test a given password. Better password policies can also help; e.g., each additional letter you require in your users' passwords exponentially increases the space of passwords that need to be brute-forced. In cases where your attacker doesn't have direct access to the database, you can greatly slow them down by only allowing a certain amount of login attempts in a given time period. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Ticket #12248 (moving django.template.__init__ contents to django.template.base)
On Fri, Nov 26, 2010 at 9:44 AM, Russell Keith-Magee wrote: > I just took a look at your patch. For the most part, it seems fairly > straightforward -- but I was stumped by the extremely small subset of > symbols you've put in __all__. > > It makes perfect sense to me that we should adopt an __all__ > attribute, but the __all__ attribute in the patch seems excessively > restrictive, only allowing Template, Context, RequestContext, and > compile_string. > > This omits some seemingly (to me) obvious candidates, such as the > Library, the various exceptions that a template can raise, and the raw > building blocks - Node, NodeList, etc. > > Is there a particular reason that you've made __all__ so restrictive? I'm not sure what you're referring to; I kept __all__ exactly the same in django.template.__init__, before and after my changes. I don't think we should modify __init__'s __all__ when people might be relying on those four symbols, and nothing else, being pulled in when doing "from django.template import *". > In the same vein, is there a reason that you chose to from base import > *, and then delete unwanted symbols, rather than just importing the > symbols you actually want? It seems to me like the __all__ list and > the import list for base should actually be pretty similar. Because I wanted to pull everything from base into the django.template namespace; I don't want to break any existing third-party code that happened to import a symbol defined in what used to be django.template.__init__ but wasn't defined in django.template.__init__'s __all__. If I only imported the four symbols defined in __all__, existing code like "from django.template import TemplateSyntaxError" would break. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Git-using core devs: preference for merge vs. rebase?
Do the Git-using core developers have a preference for merge vs. rebase for updating an upstream-tracking branch? I prefer to rebase to keep the changes in question at the branch HEAD, especially if the branch hasn't been pushed publicly yet, but a rebase for something that *has* been pushed means a forced overwrite is necessary, which may trip up anyone who has already added the branch as a remote and isn't expecting it. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Ticket #12248 (moving django.template.__init__ contents to django.template.base)
I've updated the changes for ticket #12248 and placed them on GitHub: http://code.djangoproject.com/ticket/12248 http://github.com/tomxtobin/django/tree/template-import-refactor-t12248 Is there any chance this might make it into the next release? The ticket has been Accepted for several months, but I'm at fault for not having kept the changes up to date until now. There's no functionality change; it's purely a rearrangement of django.template's internals so future refactoring of that subpackage can avoid circular import horrors. All tests pass as of a few minutes ago. I'll happily keep the GitHub branch aggressively up-to-date until it's merged if it's got a shot at inclusion. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: django template revision (for 1.4?)
On Thu, May 27, 2010 at 7:36 AM, Tom Evans wrote: > Most PHP templating languages allow you to do things that are by > design not in django's templating, for example in Smarty, one can > assign new variables on the fly in the template, and even do crazy > stuff like call functions that take arguments. This isn't impossible; you can write custom template tags that can pretty much do anything (e.g., assign variables). Whether I'd *recommend* you do so is another matter; the abuse potential is high. :-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Cujo .... an experimental branch of django.
On Wed, Apr 21, 2010 at 1:33 PM, Jeremy Dunck wrote: > On Wed, Apr 21, 2010 at 1:14 PM, Tom X. Tobin wrote: > ... >> There are no formal plans (on experimental's side) to merge anything >> from experimental to trunk. Anyone is welcome to package up code from >> experimental and champion a change for inclusion in Django proper, but >> it won't be me; I'm done working with patch files and Trac tickets. >> :-) > > This will be pretty difficult to pull off unless there are feature > branches in -experimental. Will you recommend that, at least? Development will certainly happen in feature branches, but master will be an integrated combination of the work done on -experimental. I'm absolutely not telling anyone *not* to maintain something independently for upstream inclusion; that's just not the primary focus of the project. Let's move further discussion over to the -experimental mailing list. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Cujo .... an experimental branch of django.
On Wed, Apr 21, 2010 at 1:08 PM, Tom Evans wrote: > On Wed, Apr 21, 2010 at 6:14 PM, Tom X. Tobin wrote: >> That said, we don't want to degrade the signal-to-noise ratio here, so >> we'll be working off of the mailing list Kevin mentioned. >> > > Presumably, you will be discussing anything you plan to merge from > django-experimental to django-trunk on here in depth, and using that > mailing list for discussing the day to day operation of that branch? There are no formal plans (on experimental's side) to merge anything from experimental to trunk. Anyone is welcome to package up code from experimental and champion a change for inclusion in Django proper, but it won't be me; I'm done working with patch files and Trac tickets. :-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Cujo .... an experimental branch of django.
On Wed, Apr 21, 2010 at 11:46 AM, Kevin Howerton wrote: > Thanks for the support Russ... > > I think Cujo (the name at least) has been abandoned and I have joined my > efforts with some other developers also interested in contributing to an > experimental branch. > > http://github.com/tomxtobin/django-experimental > http://groups.google.com/group/django-experimental?hl=en Please keep in mind that this is a very new venture. There are just a handful of us at the moment, and we're still getting off the ground; there's not much to "look at" yet. That said, we don't want to degrade the signal-to-noise ratio here, so we'll be working off of the mailing list Kevin mentioned. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: Cujo .... an experimental branch of django.
On Wed, Apr 21, 2010 at 11:53 AM, Jeremy Dunck wrote: > Tom, it may be inconvenient at this point, but please consider forking > the github django repo so that upstream pulls can be handled more > easily. I've been running a private Git mirror of Django for a long time now, which we source for the internal branch at The Onion, and which I'll be pushing into experimental's "upstream" branch; I just need to set up a cronjob to automate it. I'd rather not have it based on the existing GitHub django/django branch, because I don't control that mirror and don't want to depend on it not breaking. Aside: Interestingly enough, though, my mirror and the django/django mirror are still hash-identical for the same commits, which means git-svn is doing a good job of being deterministic: - http://github.com/django/django/commit/ab7e351604d556af0fdf79e5efff67f2bed39034 - http://github.com/tomxtobin/django-experimental/commit/ab7e351604d556af0fdf79e5efff67f2bed39034 -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: High Level Discussion about the Future of Django
On Fri, Apr 16, 2010 at 11:13 PM, Jerome Leclanche wrote: > For one, there is no split between a -users mailing list and a > -developers mailing list. Understand that the Bazaar mailing list is > just as active as django-developers (so less active than -users + > -developers). But it does have one clear benefit. Users don't get > pushed around with "Django-developers is for discussion about blah > blah blah". > Django, even more so than Bazaar, is an application that has > developers as its primary userbase. Using the same mailing list for > "everything" gives developers an unique insight into what users want, > where problems exist and gives users the feeling they are able to > contribute more easily, including with code! I think this is due to an unfortunate (but common) confusion of "developers" and "users". In the mailing list sense, "developers" means developers *of Django itself*, not "developers who use Django"; "users" means "anyone who uses Django", which (obviously) includes developers in the general sense of the term. I feel the separation of mailing lists is a must, even if their names are not necessarily ideal; considering the high volume of posts to -users, it would be far too easy for posts about developing Django itself to get lost there. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: High Level Discussion about the Future of Django
On Fri, Apr 16, 2010 at 10:10 PM, Russell Keith-Magee wrote: > However, at this point, I would like to tell you a story about four > people named Everybody, Somebody, Anybody, Nobody. This is exactly why I try not to bitch too much about Django's development process. It's very easy to complain, but it's not quite so easy to "shut up and show me the code". -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
Long-running tests
I recently noticed that the Django test suite seemed to be ballooning in run time, so I wrote a new test runner that tracked run times. I set it to emit run times longer than two seconds, and had the following results (under PostgresSQL, since that's what we use in production): ** Long run (3s): test_user_creation (regressiontests.admin_views.tests.IncompleteFormTest) Long run (1090s): API_TESTS (modeltests.fixtures.models.__test__) Long run (8s): test_table_exists (modeltests.proxy_model_inheritance.tests.ProxyModelInheritanceTests) Long run (106s): API_TESTS (modeltests.fixtures_model_package.models.__test__) Long run (109s): API_TESTS (modeltests.aggregation.models.__test__) Long run (6s): test_correct_url_but_nonexisting_gives_404 (modeltests.validation.tests.BaseModelValidationTests) Long run (14s): API_TESTS (regressiontests.queries.models.__test__) Long run (7s): test_urlfield_39 (regressiontests.forms.fields.FieldsTests) Long run (105s): API_TESTS (regressiontests.aggregation_regress.models.__test__) Long run (225s): test_json_serializer (regressiontests.serializers_regress.tests.SerializerTests) Long run (105s): test_json_serializer_fields (regressiontests.serializers_regress.tests.SerializerTests) Long run (112s): test_json_serializer_stream (regressiontests.serializers_regress.tests.SerializerTests) Long run (213s): test_python_serializer (regressiontests.serializers_regress.tests.SerializerTests) Long run (112s): test_python_serializer_fields (regressiontests.serializers_regress.tests.SerializerTests) Long run (213s): test_xml_serializer (regressiontests.serializers_regress.tests.SerializerTests) Long run (112s): test_xml_serializer_fields (regressiontests.serializers_regress.tests.SerializerTests) Long run (105s): test_xml_serializer_stream (regressiontests.serializers_regress.tests.SerializerTests) Long run (2s): test_expiration (regressiontests.cache.tests.DBCacheTests) Long run (2s): test_set_many_expiration (regressiontests.cache.tests.DBCacheTests) Long run (2s): test_expiration (regressiontests.cache.tests.DummyCacheTests) Long run (2s): test_expiration (regressiontests.cache.tests.FileBasedCacheTests) Long run (2s): test_set_many_expiration (regressiontests.cache.tests.FileBasedCacheTests) Long run (2s): test_expiration (regressiontests.cache.tests.LocMemCacheTests) Long run (2s): test_set_many_expiration (regressiontests.cache.tests.LocMemCacheTests) Long run (112s): API_TESTS (regressiontests.m2m_through_regress.models.__test__) Long run (4s): API_TESTS (regressiontests.fixtures_regress.models.__test__) ** Sticking out like a sore thumb is API_TESTS under modeltests.fixtures.models.__test__, which clocks in at 1090 seconds(!). The serializer tests also seem to take a pretty chunk of time at about 1-3 minutes each. I run the test suite fairly regularly (since we merge from upstream aggressively), and the total run time recently jumped from about 20 minutes to around an hour. Any ideas as to why these tests are taking so long? -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: High Level Discussion about the Future of Django
On Fri, Apr 16, 2010 at 9:36 PM, Russell Keith-Magee wrote: > On Sat, Apr 17, 2010 at 12:33 AM, sago wrote: >> >> On a completely unrelated note, any plans to move Django to git? > > I answered this exact question earlier in this thread. The answer is > no, because it would make exactly no difference to anything. Search > out the earlier answer for more detail. I *strongly* disagree with "it would make exactly no difference to anything", and I'd like to address it at some point in the future. I'll start bugging you guys about it after you're done with the 1.2 push. :p -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: High Level Discussion about the Future of Django
On Fri, Apr 16, 2010 at 4:34 PM, Taylor Marshall wrote: > On Fri, Apr 16, 2010 at 12:23 PM, Tom X. Tobin > wrote: >> None of this means that I think the core development process should >> change. (Well, besides my fervent desire that they officially adopted >> git — and yes, I do believe it *would* make a difference, centralized >> "official" branch and all — but that's a discussion for another time >> and a few beers.) >> > > You might be able to make a case on the whole DVCS thing in general, > but I'm not sure why any particular flavor is necessarily *the* choice > (i.e. the whole git vs mercurial vs bazaar holy war). There's a *huge* difference between git and the other DVCSs (completely different model), but let's save that for another time. :-) >> So ... who has a GitHub account and some neat code to look at? :-) >> > > There's already a unofficial mirror on GitHub which is maintained by jezdez: > > http://github.com/django/django > > Doesn't that solve the "make it easier to branch and track upstream > changes" thing? No, because it doesn't address ultimately pushing back up from the DVCS-using developers; git makes me loathe submitting patch files to Trac. But gah, again, I'd rather address the DVCS issue another time. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: High Level Discussion about the Future of Django
On Fri, Apr 16, 2010 at 11:23 AM, Tom X. Tobin wrote: > But here's the great part: nothing is stoping anyone from hacking new Argh, the snoot in me just winced at re-reading my post and noticing that I misspelled "stopping". ::hangs head:: -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: High Level Discussion about the Future of Django
On Fri, Apr 16, 2010 at 10:32 AM, Jacob Kaplan-Moss wrote: > I'm not arguing that "stability, maturity, and longevity" are > "correct" priorities, only that, well, those are the ones we've > chosen. I'm not saying it's "wrong" to want more rapid improvement, > only that it's lower on *my* list. My priorities overlap, but not completely. Stability is very important to me, and should be important to *anyone* whose livelihood depends on Django. Stability is a large part of the reason we *can* run our own Django branch and run production sites based on it, yet not lose our minds in the process. Maturity is fairly important; I want solutions that have experience and judgement behind them. Maturity can become rigidity, though; I enjoy exploring new ways to solve existing problems, and a new, but superior, solution isn't — strictly speaking — "mature". Longevity is where I part ways; I'd much rather have a clean break than keep working around a wart. I think my overriding principle here is correctness; I'm perfectly happy to do the work to fix my code if it means adopting the *right* solution. None of this means that I think the core development process should change. (Well, besides my fervent desire that they officially adopted git — and yes, I do believe it *would* make a difference, centralized "official" branch and all — but that's a discussion for another time and a few beers.) Django has been very successful with the current process, and I'd be very wary of tinkering with the foundations of that success. But here's the great part: nothing is stoping anyone from hacking new paths through the jungle on their own branches. What you *can't* get — and honestly *shouldn't* get — is automatic recognition that your branch is somehow officially supported, and all the notions of stability, maturity, and longevity that go with that recognition. If you know enough to make significant changes to Django, you also probably know enough to fix the problems that can crop up due to your changes — and that's not something we should expect from the average developer who just wants to Get Work Done. So ... who has a GitHub account and some neat code to look at? :-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: High Level Discussion about the Future of Django
On Fri, Apr 16, 2010 at 9:32 AM, Mike wrote: > On Apr 15, 3:32 pm, Jacob Kaplan-Moss wrote: >> For better or worse, we've chosen a development policy that >> prioritizes stability, maturity, and longevity. If those aren't your >> priorities, then perhaps a fork is the right answer. >> > Correct me if I'm wrong but I read it as "If you do not like our > policy > then stability, maturity, and longevity aren't your priorities". > With all due respect it is not fair. Logically speaking, P -> Q doesn't imply Q -> P. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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: High Level Discussion about the Future of Django
On Thu, Apr 15, 2010 at 1:57 PM, Kevin Howerton wrote: > "You seem to be suggesting that a fork will somehow magically fix the > speed of Django development. I ask you: who is going to work on this > fork?" > > I think a hostile fork is almost a certain outcome if development > continues as it has. Not only is the resistance to make backwards > incompatible changes in future releases a bad policy for the quality > of the framework, but the behavior in trac has a negative effect on > community contributions. [...] > Personally I believe my time might be better spent developing a fork, > than arguing over clear flaws in architecture decisions that "can't be > changed". Django is BSD licensed; no one is going to stop someone from making a fork if they want to. That no one has done so is, IMHO, a good sign that the Django codebase and development process is considered solid by the community. Solid, of course, can sometimes be boring. :-) There's nothing wrong with public experimentation; why not push a Django branch up on GitHub with some features you find interesting? You don't have to "fork" in order to develop your own branch; we've been maintaining an internal branch of Django at The Onion for a couple of years now, but we still track upstream aggressively. Sometimes I wonder if a long-running experimental playground branch (or branches) on GitHub would be a healthy way to direct some of the energy and interest in less conservative changes; as pieces matured there, they could be considered for the mainstream trunk, and trunk would in turn remain nice and stable. -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@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.
