Re: High Level Discussion about the Future of Django

[Tom X. Tobin]

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

[Jerome Leclanche]

On Sat, Apr 17, 2010 at 6:35 AM, Tom X. Tobin  wrote:
> 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.
>
>

And it's not supposed to be. Sometimes, all you need is feedback. Here is some!

I personally love to refer to the Bazaar development process as an
extremely healthy project and way to work. Hopefully, you guys can
learn a thing of two out of this.

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!

Of course this is just a proposal, but I've seen the "Wrong mailing
list!" warning spat out too easily. Sometimes questions should be
answered by developers. Who else is more able to answer about the
Proper Usage of a specific feature than its own author?

Another health feature of Bazaar is how tight the community is.
Django's community is similarly-sized, yet Bazaar manages to gather
its community, giving it a much friendlier environment. Launchpad
(their bug tracking platform) is being used for much of the off-list
discussions and lets the users easily contact developers on the list,
while trac still looks confusing, has a disgusting login system, and
Thousands More Issues.
(Before anyone throws me a "Shut up and show me the code!", I've been
working on a bug/issue tracker using Django as backend. I'll gladly
accept help from anyone who also wants to work on this!)

Plugin development and discussion is also done on the same list. This
ties the community even closer, while Django's best fallback is
djangosnippets.org. Last time I saw anything like it on this list was
a few days ago with the django template language port to Qt. And what
does the Django Developer say to the guy who releases a Cool Project?
"Wrong mailing list!".
Needless to say (but saying it anyway), this is also the sort of
undeserved hostility people have been talking about in this thread.

Oh and lastly, they don't use svn ;)

2¢

J. Leclanche / Adys

-- 
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

[Tom X. Tobin]

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.

Re: High Level Discussion about the Future of Django

[Russell Keith-Magee]

On Sat, Apr 17, 2010 at 6:02 AM, orokusaki  wrote:
> When I first started posting things on trac, I put up a request that
> took me an hour to create, explaining the justification, as well as
> putting the code in there. I didn't know how to make a patch, and I
> went about it the wrong way, but regardless of that, I put a lot of
> thought into it. Less than 3 minutes after I posted it, it was closed
> and resolution set to `wontfix`. It was an extremely minor change that
> didn't break any backwards compatibility, but I didn't follow the
> right procedures, so wham, gone.

I'm going to stop you there. You repeatedly *asserted* that it was
backwards compatible. We (Joseph and I) *repeatedly* told you that we
didn't think it was, and we *repeatedly* told you to take the
discussion to django-dev, and you *repeatedly* didn't, and we
*repeatedly* pointed you at the contribution docs to tell you why we
were saying you should take it to django-dev, and you *repeatedly*
didn't... until you finally did, at which point, we demonstrated why
your idea wasn't backwards compatible, and -- unless I'm mistaken --
you agreed.

Please don't characterize what Joseph and I did as arbitrary or closed minded.

> If the core team doesn't want to change the backwards compatibility
> policy a tiny bit to accommodate faster paced code ( keeping up with
> the Jone's and such, such as RoR 3.0 ),

Django's backwards incompatibility policy doesn't mean *no change*. It
means *no sudden change*. There are *many* examples in Django 1.2
alone of features that are being deprecated or altered in ways that
will ultimately be incompatible. Code written for Django 1.0 won't run
unmodified in Django 1.4 due to changes in admin registration,
messaging, CSRF, and many other features. However, these changes are
introduced as a series of progressive enhancements rather than sudden
changes. This enables use to provide ample active warnings advising
that code changes will be required. It also avoids the need to
introduce "USE_NEW_BEHAVIOR" settings switches that require us to
maintain two implementations in parallel and in perpetuity.

We're open to any proposal to change the status quo - as long as it
can be done gradually and gracefully. If you think hard enough, *most*
problems can be fixed in this way. Those that can't are unfortunate
warts, but that's the price we pay for having a stable platform. As
Jacob said, that's not a claim that Django-style stability is
"correct" - it's just the policy we have adopted based on our
particular priorities.

Yours,
Russ Magee %-)

-- 
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: Long-running tests

[Karen Tracey]

On Fri, Apr 16, 2010 at 11:00 PM, Tom X. Tobin wrote:

> [snip details of run times]
>
> 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?
>
>
The ones that are sticking out like sore thumbs have always been sticking
out like sore thumbs (on my slow machines).  Whenever I glance at a test run
to see how it's going it's almost invariably "stalled" on one of those you
mention.  And I know why. There are 10 of these:

>>> management.call_command('flush', verbosity=0, interactive=False)

for example, in modeltests/fixtures/models.py. That's a full re-build of the
entire test database. Many if not all of the others cited above have at
least one of those calls.

These are not new, so the question is why are you suddenly noticing them?
Did some recent change make re-syncing the DB even more expensive than it
used to be? Or has the number of test apps and model tables just been
growing, growing, growing slowly and now it's noticeably slower? You
mention, though, a recent jump from 20 minutes to an hour -- specifics on
what changeset(s), exactly, caused that dramatic difference in time might
give a clue.

Karen

-- 
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

[Russell Keith-Magee]

On Sat, Apr 17, 2010 at 7:30 AM, George Sakkis  wrote:
> On Apr 15, 8:57 pm, Kevin Howerton  wrote:
>
>> The level of resistance I see to change or outsider code contribution
>> is an enormous de-motivator for people (like me) to want to make any
>> contributions in the first place.  Why should I contribute a patch to
>> your flawed architecture if I'm going to be talked down to, ridiculed,
>> then eventually have the patch rejected because it breaks code in some
>> edge-use-case?
>
> Good luck pushing backwards incompatible patches when as we speak
> there are almost 400 open tickets with patches at accepted [1] and
> "ready for checkin" [2] stage. Under these circumstances, backwards
> compatibility is almost a red herring; the bigger issue IMO is the
> increasing pile of bug fixes and solid, backwards compatible patches
> languishing for months or years.
>
> A fork that encouraged and achieved a faster submit-review-accept-
> commit lifecycle, even with the same stability, maturity, and
> longevity policies, could be a breath of fresh air.

As I have said *many* times in the past - I would *love* for someone
to do this. "Fork" is an extreme way of describing it -- I'd prefer to
think of it as a "trunk-ready branch", in the same way that Linus
relies on his lieutenants as a source of vetted patches for Linux
trunk -- but I have no problem with the basic idea.

If such a branch were to exist, and the person (or people) maintaining
the branch (or branches) maintained the same levels of quality that
Django's trunk expects - good architectural style, extensive
documentation, testing, good commit messages, etc - I would use that
branch as a source of material to commit to trunk *in a heartbeat*.
Examining a small number of branches that have been curated by people
I trust would be a much more effective use of my bug-fixing time than
trolling the entirety of Trac.

However, at this point, I would like to tell you a story about four
people named Everybody,  Somebody, Anybody, Nobody.

Everybody agreed that a trunk-ready branch was needed.

Somebody should have worked on the trunk-ready branch.

Anybody could have worked on the trunk-ready branch.

However, Nobody actually worked on the trunk-ready branch.

It's *really* easy to stand on the sidelines and say "there are too
many open tickets" or "progress isn't fast enough". It's another thing
entirely to actually put the time and effort into doing the work. It's
yet another thing to *still* be doing that same work 3 months (or, in
my case, 4 years) later.

So - if you want Django to progress faster - pitch in. If anyone wants
to put the effort into maintaining a trunk-ready branch, go right
ahead. Personally, I have the ability to merge branches from both git
and hg, so you can't claim that the lack of an official DVCS is
hampering you. Once you've got something worth merging, post to
django-dev describing what you've got, and we'll take a look.

Yours,
Russ Magee %-)

-- 
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

[Tom X. Tobin]

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

[Tom X. Tobin]

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

[Russell Keith-Magee]

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.

Yours,
Russ Magee %-)

-- 
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: Import problem starting with r12977

[Derek Hoy]

On Sat, Apr 17, 2010 at 12:36 AM, Derek Hoy  wrote:
>
> I'll dig around a bit more.

The problems seemed to come from the same models.py that was shared
across the projects. I moved a couple of imports and it seems fine
with trunk (r12996).

So it looks like it's the change in the error handling that is showing
up problems in the code.

And that means we should be in django-users :)

Derek

-- 
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: Import problem starting with r12977

[Derek Hoy]

Strange, I had the same problem and rolling back to 12976 fixed it.
But another project still failed. It worked when I rolled back to
r12949.

http://code.djangoproject.com/changeset/12950 is the first of a few
that deal with app loading. It may be our projects had import errors
that weren't being reported I suppose.

I'll dig around a bit more.

Derek

On Fri, Apr 16, 2010 at 5:55 PM, Erik Stein  wrote:
>
> Hello --
>
> I hope that's the correct place to ask, else point me to django-users.
>
> Starting with changeset
>
>        http://code.djangoproject.com/changeset/12977 (Fixed #13328 -- Added a 
> getstate/setstate pair to fields so that callable default values aren't 
> pickled. Thanks to bkonkle for the report, and Vitaly Babiy for the patch.)
>
> I get import errors which are very difficult to debug (at least for me). I'm 
> hangling from file to file. It seems to boil down to
>
>        self.model = cls
>
> in fields/__init__.py.
>
> It may be related to some non-obvious circular import on my side, but what 
> exactly am I supposed to do concerning r12977? File a new bug or just try to 
> fix my code?
>
> best
> -- erik
>
>
>
> Erik Stein
> Programmierung, Grafik
>       Oranienstr. 32   10999 Berlin, Germany
>       fon +49 30 69201880   fax +49 30 692018809
>       email e...@classlibrary.net
>
>
>
>
>
> Erik Stein
> Programmierung, Grafik
>        Oranienstr. 32   10999 Berlin, Germany
>        fon +49 30 69201880   fax +49 30 692018809
>        email e...@classlibrary.net
>
>
>
> --
> 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.
>
>

-- 
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

[George Sakkis]

On Apr 15, 8:57 pm, Kevin Howerton  wrote:

> The level of resistance I see to change or outsider code contribution
> is an enormous de-motivator for people (like me) to want to make any
> contributions in the first place.  Why should I contribute a patch to
> your flawed architecture if I'm going to be talked down to, ridiculed,
> then eventually have the patch rejected because it breaks code in some
> edge-use-case?

Good luck pushing backwards incompatible patches when as we speak
there are almost 400 open tickets with patches at accepted [1] and
"ready for checkin" [2] stage. Under these circumstances, backwards
compatibility is almost a red herring; the bigger issue IMO is the
increasing pile of bug fixes and solid, backwards compatible patches
languishing for months or years.

A fork that encouraged and achieved a faster submit-review-accept-
commit lifecycle, even with the same stability, maturity, and
longevity policies, could be a breath of fresh air.

George


[1]
http://code.djangoproject.com/query?status=new=assigned=reopened_better_patch=!1_tests=!1_docs=!1_patch=1=priority=Accepted

[2]
http://code.djangoproject.com/query?status=new=assigned=reopened_better_patch=!1_tests=!1_docs=!1_patch=1=priority=Ready+for+checkin

-- 
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

[George Sakkis]

On Apr 15, 8:57 pm, Kevin Howerton  wrote:

> The level of resistance I see to change or outsider code contribution
> is an enormous de-motivator for people (like me) to want to make any
> contributions in the first place.  Why should I contribute a patch to
> your flawed architecture if I'm going to be talked down to, ridiculed,
> then eventually have the patch rejected because it breaks code in some
> edge-use-case?

Good luck pushing backwards incompatible patches when as we speak
there are almost 400 open tickets with patches at accepted [1] and
"ready for checkin" [2] stage. Under these circumstances, backwards
compatibility is almost a red herring; the bigger issue IMO is the
increasing pile of bug fixes and solid, backwards compatible patches
languishing for months or years.

A fork that encouraged and achieved a faster submit-review-accept-
commit lifecycle, even with the same stability, maturity, and
longevity policies, could be a breath of fresh air.

George


[1]
http://code.djangoproject.com/query?status=new=assigned=reopened_better_patch=!1_tests=!1_docs=!1_patch=1=priority=Accepted

[2]
http://code.djangoproject.com/query?status=new=assigned=reopened_better_patch=!1_tests=!1_docs=!1_patch=1=priority=Ready+for+checkin

-- 
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

[Tom Evans]

On Fri, Apr 16, 2010 at 11:02 PM, orokusaki  wrote:
>...
> I think I speak for a pretty broad user base when I say that folks who
> use Django are bleeding edge developers who want cool stuff, and don't
> mind paying a little extra to have it. It isn't like IBM and Microsoft
> are using Django for huge distributed projects, and upgrading all
> their clients to the latest version each week. And, again back to
> Kevin's point; if they are upgrading quickly, they are the types that
> understand the value of doing so.

I don't work for Microsoft or IBM, but as someone who actually does
run a mission critical service built around django, with 99.99% uptime
requirements (60 mins downtime/year), we seriously appreciate the
stability of django development - it was one of the main pros compared
to other frameworks when we decided to move our web development from
C++ to a dynamic language.

Don't get me wrong, we love new features as much as the next person,
and we're eagerly awaiting the chance to get 1.2-release into testing,
but each new release means about a week of testing, code reviews and
so on. The current balance between new features and stability suits us
just fine - features aren't rushed in, even in contrib, and that has
to be a good thing.

Cheers

Tom

-- 
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

[orokusaki]

When I first started posting things on trac, I put up a request that
took me an hour to create, explaining the justification, as well as
putting the code in there. I didn't know how to make a patch, and I
went about it the wrong way, but regardless of that, I put a lot of
thought into it. Less than 3 minutes after I posted it, it was closed
and resolution set to `wontfix`. It was an extremely minor change that
didn't break any backwards compatibility, but I didn't follow the
right procedures, so wham, gone. I tend to agree with Kevin's
assertion that it's not worth spending time developing when you don't
know if your ideas will be thrown in the trash, but I won't complain
about it because everything these people do for Django is free to us,
and if they weren't hardcore, the framework could have turned into
muck by this point (with the number of feature requests out there).

After a few rounds of doing that, I realized that people like Russell,
who appear to be closed minded at first glance, are really not closed
minded at all, but just overworked by tickets and don't have extra
time to do every single ticket. I believe this is primarily because
for every added feature, tons and tons of code has to be changed /
added to keep everything backwards compatible with code from a year
ago.

I think I speak for a pretty broad user base when I say that folks who
use Django are bleeding edge developers who want cool stuff, and don't
mind paying a little extra to have it. It isn't like IBM and Microsoft
are using Django for huge distributed projects, and upgrading all
their clients to the latest version each week. And, again back to
Kevin's point; if they are upgrading quickly, they are the types that
understand the value of doing so.

If the core team doesn't want to change the backwards compatibility
policy a tiny bit to accommodate faster paced code ( keeping up with
the Jone's and such, such as RoR 3.0 ), it might be worth investing
the time to start a fork. A little competition for the core team
wouldn't hurt them a bit. It would relieve a little of the stress of
being bombarded by tickets for things that are not possible for a
whole year, etc. I would only suggest that if you were to go this
route, to do so in a way that isn't harmful to Django as a whole (e.g.
making empty promises will leave a bitter taste and ruin the name).



On Apr 15, 12: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.
>
> The level of resistance I see to change or outsider code contribution
> is an enormous de-motivator for people (like me) to want to make any
> contributions in the first place.  Why should I contribute a patch to
> your flawed architecture if I'm going to be talked down to, ridiculed,
> then eventually have the patch rejected because it breaks code in some
> edge-use-case?
>
> 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".
>
> It's a good idea to avoid breaking backwards compatibility in point
> releases, but as far as major releases go ... I whole heartedly
> encourage it.  If keeping backwards compatibility was a good idea, my
> macbook pro would have a 5.12" floppy drive, a 3.25" drive, a jazz
> drive, it would accept serial and adb plugs and maybe have a
> display mode to emulate those green crt monitors of yore.
>
> Good software is about removing flaws, improving the architecture, and
> learning from past mistakes.  If this comes at a price, then pay.
>
> -k
>
> On Wed, Apr 14, 2010 at 9:25 AM, Russell Keith-Magee
>
>  wrote:
> > On Wed, Apr 14, 2010 at 8:34 PM, veena  wrote:
>
> >> I know there's django deprecation policy nicely documented
> >>http://docs.djangoproject.com/en/1.1/internals/release-process/#inter...
>
> >> But what I don't know is how you discover it. Is it described
> >> somewhere in the text or the video from conference? What were the
> >> reasons to have this deprecation policy? Was there any user research?
> >> Research of when the django users upgrade, what are the main problems
> >> of upgrades and how they imagine upgrading should work?
>
> > The policy was arrived at after a debate between the core team, based
> > on how the core team believe a well-behaved project should behave. For
> > the record, it wasn't much of a debate, either - we were all pretty
> > much in agreement on the core points from the beginning.
>
> > In the opinion of the core, well-behaved projects don't 

Re: High Level Discussion about the Future of Django

[Tom X. Tobin]

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

[James Bennett]

On Fri, Apr 16, 2010 at 4:34 PM, Taylor Marshall
 wrote:
> There's already a unofficial mirror on GitHub which is maintained by jezdez:

AFAIK there are mirrors on pretty much every DVCS/"social code"
hosting site; bitbucket's got one as well, for example.


-- 
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."

-- 
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

[Taylor Marshall]

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).

>
> 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?

-- 
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: logialogin_required does not check User.is_active

[subs...@gmail.com]

Could the burden of this work be successfully (and sensibly) shifted
to the backend itself by calling something like... deactivate()?

In this event, the default backend's logic could be 'set is_active =
False and expire cookie' and custom backends could do (or not do)
whatever they want.

Forgive me for the hypothetical responses, as I don't have any
experience with custom backends.

-Steve

On Apr 15, 8:55 pm, Russell Keith-Magee 
wrote:

>  1) Backends aren't required to subclass a common base class, so we
> have to assume that there will be custom backends out there that
> *wont'* have an is_active check, even if we add one to ModelBackend.
> This isn't a huge problem - we can work around it with a hasattr check
> - but it's worth noting as something that will need to be addressed.
>
>  2) How do you get access to the right authentication backend in the
> login_required decorator? The only argument you are guaranteed to have
> access to is user, and the user doesn't (currently) have a way to get
> access to the backend on which they were authenticated.
>
> Yours,
> Russ Magee %-)
>
> --
> 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 
> athttp://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-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

[Tom X. Tobin]

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.

Import problem starting with r12977

[Erik Stein]

Hello --

I hope that's the correct place to ask, else point me to django-users.

Starting with changeset

http://code.djangoproject.com/changeset/12977 (Fixed #13328 -- Added a 
getstate/setstate pair to fields so that callable default values aren't 
pickled. Thanks to bkonkle for the report, and Vitaly Babiy for the patch.)

I get import errors which are very difficult to debug (at least for me). I'm 
hangling from file to file. It seems to boil down to

self.model = cls

in fields/__init__.py.

It may be related to some non-obvious circular import on my side, but what 
exactly am I supposed to do concerning r12977? File a new bug or just try to 
fix my code?

best
-- erik



Erik Stein
Programmierung, Grafik
   Oranienstr. 32   10999 Berlin, Germany
   fon +49 30 69201880   fax +49 30 692018809
   email e...@classlibrary.net





Erik Stein
Programmierung, Grafik
Oranienstr. 32   10999 Berlin, Germany
fon +49 30 69201880   fax +49 30 692018809
email e...@classlibrary.net



-- 
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

[sago]

Isn't that what forking is for?

A group of folks feel frustrated about not being able to commit, so
they make their own copy of the source code available. A few months
later they either implode when they realise just how much work it is
going to take to do anything remotely sensible, or they come up with
some bit of nuggety goodness that can be chopped around and
backported.

As long as the forking happens without falling out, that is...

On a completely unrelated note, any plans to move Django to git?

Ian.

Not that I count for jack, but its +1 on API stability and backwards
compatibility from me, btw!



On Apr 16, 5:23 pm, "Tom X. Tobin"  wrote:
> 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 
> athttp://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-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

[Tom X. Tobin]

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

[Tom X. Tobin]

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

[Jacob Kaplan-Moss]

On Fri, Apr 16, 2010 at 9:32 AM, Mike  wrote:
> 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.

But isn't that exactly what people in this thread are saying? The main
complaint I'm reading here is that folks are frustrated with Django's
backwards-compatibily policy, and that they'd be willing to break
backwards-compatibility in exchange for new features. In other words,
that forward motion and architectural changes are more desirable than
backwards-compatibility.

Or am I reading Kevin, Tom, Skylar, et al. wrong?

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.

I think you're reading a value judgement where none's intended. We've
simply chosen certain priorities; reasonable people may have different
profiles. Nobody's "right" here; I'm trying to point out what
philosophies are leading to our conservatism.

Jacob

-- 
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

[Mike]

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.

Regards,
Mike

-- 
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: Pass Thru Image Proxy Patch Interest?

[David Danier]

> Yes, I was thinking the other day that it would be a cool solution for
> serve() to be able to use storage backends

Wouldn't it be better to have some {% serve path/to/file %} template
tags, that does all the work of checking where the file exists and
returning the right URL? Putting this into serve() always means a
request to your local webserver which may lead to a HTTP-redirect (so we
have two requests).

Of course having a template tags means {{ MEDIA_URL }}path/to/file must
be replaced everywhere in your templates. But I think it's worth the
benefit.

Greetings, David Danier

-- 
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: Pass Thru Image Proxy Patch Interest?

[Suno Ano]

This blog post http://bit.ly/a4iyJ6 also talks about the ability to use
what is called a remote URL to eventually server content (read content
delivery network).

In my opinion it also has a pretty good solution about caching images
when setting up a pass though image proxy solution.

-- 
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.