Re: Admin accessibility tweaks
On Thu, Feb 25, 2010 at 12:29 AM, Chris Adams wrote: > We've been collecting various tweaks to the stock Django 1.1.1 which > have been requested by our 508 testers. I'd appreciate it if someone > could review these tickets: > > Add scope=col to changelist table headers: > http://code.djangoproject.com/ticket/12957 > > Add alt text to SelectFilter2's filter widget: > > http://code.djangoproject.com/ticket/12959 > > SelectFilter2 loses help_text - not a pure accessibility issue but it > can cause confusion in some cases: > > http://code.djangoproject.com/ticket/6183 > > Feedback on streamlining these reports is welcome - I don't think we > have too much else but I'm still waiting for details about the issues > reported on all of our projects. > > I'm tracking our changes here: > > http://github.com/acdha/django/commits/1.1.1-508-fixes Thanks for that Chris. We're certainly interested in hearing in any suggestions on how we can improve accessibility in Django's admin, or in Django's toolset in general. Keeping a clean branch of fixes is also very helpful - it means that when one of the core team can find the time to dedicate to the problem, there is a ready-to-use source of patches. On a related note - there has been talk recently about doing a design refresh on the admin. If you have some accessibility/508 experience, you might want to keep an ear to the ground so you can participate in any design discussions that occur when this happens. 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: admin javacripts
> This kind of sounds nice, but perhaps some sort of django namespace
> could be introduced. Meaning $jQD -> dj.$:
>
>
>
> var dj = {};
> dj.$ = dj.jQuery = jQuery.noConflict(true);
>
This is a great idea, it also means that we could have a setting for
specifying which libraries to add to the django namespace, depending
on what our apps and 3rdparty apps require.
To elaborate: Say that by default the django namespace has two
libraries inlcuded:
var dj = {};
dj.jq = dj.jQuery = jQuery.noConflict(true);
Then individual apps could be given a way to add to this namespace,
following some convention, say if you want a specific version of
jQuery, say version 1.4, then you could add below the other stuff:
dj.jq_1_4 = jQuery.noConflict(true);
And if you wanted som specific version of mootools or other library
(which I don't know excactly how works, so I'm guessing):
dj.moo_1_2 = MooTools = $;
MooTools = $ = null; // or some equivalent of jQueries noConflict()
function
To make use of these namespaces the widgets would have to wrap their
library calls into closures, like so:
dj.jq(function($) {
// Here you can reference $ and be sure it's jQuery
$('#some_id').some_awesome_jquery_plugin_name();
});
I don't know if other libraries than jQuery have this closure support,
anyone?
Could we brainstorm on this a bit?
--
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: 404 debug pages should show the name of the tried urlpattern - #9310
On Thu, Feb 25, 2010 at 3:43 AM, Jeremy Dunck wrote: > On Wed, Feb 24, 2010 at 11:14 AM, Tobias McNulty > wrote: > ... >> I'm hoping this will spark a discussion about how we can work more >> efficiently and put donated time to better use. I may be a bit biased, >> because this is coming on the tail end of spending 2+ person hours trying to >> reproduce a ticket in the PyCon sprint that, I later found out, two others >> had done the same thing with a day earlier, but neither had indicated as >> much in the ticket. > > The basic problem, as ever, is managing volunteer time. In this case, > it looks like a failure of triage. A committer often looks for > ready-for-checkin, and this ticket, despite having a patch, never got > marked ready-for-checkin. There's also a more fundamental issue - simple availability of volunteer time. Part of the reason that the ticket queue is so large is a sheer lack of resources. For example, about two weeks ago, I spent just over a week triaging unreviewed tickets. This is time I didn't spend committing other tickets. The only reason I did this is because a backlog of 300 tickets had accumulated, and we can't make a release with unreviewed tickets, since an unreviewed ticket is potentially an unknown release blocker. I'm not casting blame here. Those doing triage work are doing a great job. I'm just pointing out that we have a problem. Despite the best efforts of our volunteer triage team, they haven't been able to keep up with the backlog. We either need more volunteers to do triage, or we need to accept as a community that progress isn't going to be as fast as we may like. There is also an extent to which Django 1.2 has been the culprit. Django 1.2 has been particularly unkind to the ticket queue. The feature list for 1.2 is *huge*, and this has meant that smaller issues have taken a back seat. For comparison, we made lots of bugfixes during the 1.1 development cycle - enough to warrant 1.0.1 and 1.0.2 point releases. However, during the 1.2 development cycle, there really hasn't been enough activity in 1.1.X to warrant us cutting a bugfix release. One concrete suggestion I would make is that we scale down our goals for 1.3. There are still a couple of big ticket items that are pending from 1.2 (like class-based generic views and logging). There are also some lingering big issues that we need to address (like the flexibility of auth.User). However, I think we would be well served to deliberately hold back on big features for 1.3 in the interests of clearing some of our ticket backlog. >> A couple ideas to get us started: >> >> 1) Reemphasize via documentation and/or training (and/or by reading this >> message) the proper work flow for tickets (e.g., accept it when you start >> working on it, post a comment when you're done, etc.): >> >> http://docs.djangoproject.com/en/dev/internals/contributing/#claiming-tickets > > I don't think documenting it more is the solution -- if people aren't > clear on the process as documented, I certainly haven't heard that > confusion. I think the issue is that documenting and doing are two > different things. For example, I know that I should only have tickets > assigned to me if I'm actively working them, but that hasn't stopped > me from forgetfully breaking that rule pretty often. Completely agreed. You can't fix the problem of people not reading the documentation by providing more documentation. >> 2) For each release, assign several people (I'd be happy to take a turn) the >> task of searching through all outstanding tickets in the milestone in >> question a couple weeks before the feature freeze and assigning >> "committable" ones to specific committers. Maybe this ticket is an outlier, >> but I expect there are others out there that are also getting missed. I'm >> not sure if this means that the current way ticket triage is outlined to >> work is just not happening, or if there are changes we need to make so that >> it works more effectively: >> >> http://docs.djangoproject.com/en/dev/internals/contributing/#ticket-triage > > This gets at the problem more directly -- we used to have a > feature/bug classification, but it was abused -- lots of people marked > things as bugs simply because they felt they were necessary, and hence > not "features". Everything is miscellaneous, but if there is no > consistent distinction between bug and feature, there's no point in > having the field. ... > What you're asking for, I think, is some sensitivity to the scope of a > change vs. how long it's been pending. This is a pretty hard problem > to address -- if it falls to triagers, you're back where we started of > triaging not being able to keep up with the queue. It'd be nice if > Trac stored time-stamped state transitions to reveal this sort of > thing. The things we need to have in Trac are exactly the things we can't have because of our open-door policy. Ticket fields like "feature", "severity" and "priority" are great at iden
Re: IfEqualNode is missing a get_nodes_by_type method
Since I just wrestled with this issue (albeit from a different
direction),
it would be really nice if the behavior was, if nothing else,
consistent.
On Feb 24, 8:33 pm, SmileyChris wrote:
> My ticket in #6510 [1] deals with this, along with a nice abstraction
> of common recursive nodelist gathering patterns.
>
> Although the ticket description, comments (and even tests in my patch)
> mention {% block %}, this has *nothing* to do with conditional
> inheritance.
>
> If the patch is deemed too much of a feature to fit in the 1.2
> schedule, I'd still advocate for just adding a get_nodes_by_type
> method to the IfEqualNode. It's not a difficult or overly
> controversial change, and the bug has existed far too long because of
> confusion over the actual issue.
>
> [1]http://code.djangoproject.com/ticket/6510
--
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: 404 debug pages should show the name of the tried urlpattern - #9310
Just two small points I'd like to highlight:
On Feb 26, 3:50 am, Russell Keith-Magee
wrote:
> I'm not casting blame here. Those doing triage work are doing a great
> job. I'm just pointing out that we have a problem. Despite the best
> efforts of our volunteer triage team, they haven't been able to keep
> up with the backlog. We either need more volunteers to do triage, or
> we need to accept as a community that progress isn't going to be as
> fast as we may like.
More volunteers! Come one people! *SmileyChris blows his triage
trumpet*
> There is also an extent to which Django 1.2 has been the culprit.
> Django 1.2 has been particularly unkind to the ticket queue. The
> feature list for 1.2 is *huge*, and this has meant that smaller issues
> have taken a back seat. For comparison, we made lots of bugfixes
> during the 1.1 development cycle - enough to warrant 1.0.1 and 1.0.2
> point releases. However, during the 1.2 development cycle, there
> really hasn't been enough activity in 1.1.X to warrant us cutting a
> bugfix release.
I concur with Russ' points here, and I like his followon points that
1.3 should have scaled down goals to try and slim down the ticket
backlog.
But I do think it's critical to see a new 1.1 release before 1.2 is
out - if for no other reason than having {% csrf_token %} in a 1.1
official release.
--
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: 404 debug pages should show the name of the tried urlpattern - #9310
On Thu, Feb 25, 2010 at 3:05 PM, SmileyChris wrote:
>
> But I do think it's critical to see a new 1.1 release before 1.2 is
> out - if for no other reason than having {% csrf_token %} in a 1.1
> official release.
>
>
Before 1.2 is out or at the same time as 1.2 goes out? We normally do a
final micro release for the previous release when a new release goes out. At
this point doing both that and a micro release to get {% csrf_token %} into
a 1.1.X release before 1.2 goes out strikes me as too many 1.1.X micro
releases too close together (assuming 1.2 goes out reasonably close to
schedule).
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: 404 debug pages should show the name of the tried urlpattern - #9310
On 25/02/2010 20:05, SmileyChris wrote: Just two small points I'd like to highlight: On Feb 26, 3:50 am, Russell Keith-Magee wrote: I'm not casting blame here. Those doing triage work are doing a great job. I'm just pointing out that we have a problem. Despite the best efforts of our volunteer triage team, they haven't been able to keep up with the backlog. We either need more volunteers to do triage, or we need to accept as a community that progress isn't going to be as fast as we may like. More volunteers! Come one people! *SmileyChris blows his triage trumpet* I've been reading this list for a while, and just read the 'Ticket Triage' part of the documentation [http://docs.djangoproject.com/en/dev/internals/contributing/?from=olddocs#ticket-triage / http://docs.djangoproject.com/en/dev/internals/contributing/?from=olddocs#triage-by-the-general-community] What do trusted ticket triagers do in addition to the 'triage by the general community' tasks? The docs are a bit vague on that. Anyhow - i'm going to do my best to find some time to do work on general tasks. Stephen -- 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: 404 debug pages should show the name of the tried urlpattern - #9310
On Fri, Feb 26, 2010 at 6:39 AM, Stephen Wolff wrote: > On 25/02/2010 20:05, SmileyChris wrote: >> >> Just two small points I'd like to highlight: >> >> On Feb 26, 3:50 am, Russell Keith-Magee >> wrote: >> >>> >>> I'm not casting blame here. Those doing triage work are doing a great >>> job. I'm just pointing out that we have a problem. Despite the best >>> efforts of our volunteer triage team, they haven't been able to keep >>> up with the backlog. We either need more volunteers to do triage, or >>> we need to accept as a community that progress isn't going to be as >>> fast as we may like. >>> >> >> More volunteers! Come one people! *SmileyChris blows his triage >> trumpet* >> >> > > I've been reading this list for a while, and just read the 'Ticket Triage' > part of the documentation > [http://docs.djangoproject.com/en/dev/internals/contributing/?from=olddocs#ticket-triage > / > http://docs.djangoproject.com/en/dev/internals/contributing/?from=olddocs#triage-by-the-general-community] > > What do trusted ticket triagers do in addition to the 'triage by the general > community' tasks? The docs are a bit vague on that. Anyhow - i'm going to do > my best to find some time to do work on general tasks. The trusted triage team doesn't do anything extra - they just have increased authority in the triage process. The triage docs tell you to "be conservative in your actions"; the triage team has been explicitly given permission to be a little less conservative on the basis of their track record. This also means that their decisions carry a little more weight. For example, if a triage team member marks a ticket as wontfix, that shouldn't be reversed by a general community member without a discussion on django-dev. However, point taken -- that section of the docs could do with some clarification. The role of the triage team is a little vague at the moment. We should also be a little more clear on who is on the triage team (I don't think we have publicly acknowledge them by name anywhere at the moment). 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.
Status of #1480: "Don't Set TIME_ZONE [...]"
Having been bitten by issue #1480 personally, I'm wondering what the status of this ticket really is? Trac indicates it needs a better patch and better docs, but there's no information about what changes are needed. If someone will give me some guidance, I'd be happy to wrap this one up and see it ship in 1.2... See the ticket here: http://code.djangoproject.com/ticket/1480 Thanks! - Gabriel -- 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.
Django's testing infrastructure
Hey everyone, During the sprints, I worked to set up a hudson instance for Django. This is hopefully going to be the way that we are going to go forward for now with doing continuous integration for Django. I have a pretty good setup going currently, and want make it really fantastic. At this point in time, what we really need now is some more hardware to be able to run tests on. The current setup is hosted at: http://hudson.djangoproject.com/ Currently, I have tests running on the following architectures: Django trunk: Solaris: Python 2.4-2.5 Databases: sqlite, postgres, mysql Ubuntu: Python 2.5-2.6 Databases: sqlite, postgres, mysql Django 1.1.X: Solaris: Python 2.5 Databases: sqlite, postgres This gives us pretty good coverage currently, but the whole point of doing CI is that we catch bugs on other platforms we wouldn't normally run on. What we need === So I'm looking for people who can offer other boxes that they would like to see tested. Currently the big ones we aren't covering are Windows boxes, and the Oracle backends. There are lots of other permutations that we could be testing against (Different python runtimes being a good example). However, we don't want to get in a situation where boxes that people have set up just disappear. So, I'm only currently looking for machines that people would be able to dedicate to the effort. We would require a django-testing user account on the box, with our SSH key on it. There would also be a team of trusted users, who would have access to this key and thus your machine. We want the build farm to be stable and useful, and in the past we have had too much trouble having machines just disappear. Requirements === Currently the hudson requirements seem to be about <1GB of disk space, with 512MB of ram. I'm also looking into some pony build/barn based alternatives that would knock the memory requirements down pretty substantially. However, for the current 1.2 release it looks like hudson is how we're going to make it going forward. Note that for $20/mo a 512MB machine can be run on Rackspace cloud, so another way that we might be able to get this going is to be able to have donations to the DSF, and have them get some dedicated rackspace boxes. However, for now, I'm hoping that we can cobble together enough stuff to get 1.2 tested really well. Feedback == If you have any thoughts on CI, or any advice, I would love to hear it. I'm trying to make our Continuous Integration setup really kick ass, so feedback is necessary to do this. I have some notes and ideas that I have been recording while setting things up over at the pycon etherpad: http://pyconpads.net/django-testing Let me know if you have any thoughts, questions, or concerns. Cheers, Eric -- 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's testing infrastructure
A platform we probably should get into the mix is a CentOS/RHEL 5 box. I suspect a significant portion of the community is stuck on such boxes and given the ancient versions of everything available under RHEL I'm sure that there are things which will break there and not in a developer's standard environment. I personally don't have a suitable RHEL box laying around but this seems like a good candidate for either another volunteer or DSF funds. Sean O'Connor http://seanoc.com On Thu, Feb 25, 2010 at 10:54 PM, Eric Holscher wrote: > Hey everyone, > > During the sprints, I worked to set up a hudson instance for Django. This > is hopefully going to be the way that we are going to go forward for now > with doing continuous integration for Django. I have a pretty good setup > going currently, and want make it really fantastic. At this point in time, > what we really need now is some more hardware to be able to run tests on. > > The current setup is hosted at: http://hudson.djangoproject.com/ > > Currently, I have tests running on the following architectures: > > Django trunk: > > Solaris: > Python 2.4-2.5 > Databases: sqlite, postgres, mysql > > Ubuntu: > Python 2.5-2.6 > Databases: sqlite, postgres, mysql > > Django 1.1.X: > > Solaris: > Python 2.5 > Databases: sqlite, postgres > > This gives us pretty good coverage currently, but the whole point of doing > CI is that we catch bugs on other platforms we wouldn't normally run on. > > What we need > === > > So I'm looking for people who can offer other boxes that they would like to > see tested. Currently the big ones we aren't covering are Windows boxes, and > the Oracle backends. There are lots of other permutations that we could be > testing against (Different python runtimes being a good example). > > However, we don't want to get in a situation where boxes that people have > set up just disappear. So, I'm only currently looking for machines that > people would be able to dedicate to the effort. We would require a > django-testing user account on the box, with our SSH key on it. There would > also be a team of trusted users, who would have access to this key and thus > your machine. > > We want the build farm to be stable and useful, and in the past we have had > too much trouble having machines just disappear. > > Requirements > === > > Currently the hudson requirements seem to be about <1GB of disk space, with > 512MB of ram. I'm also looking into some pony build/barn based alternatives > that would knock the memory requirements down pretty substantially. However, > for the current 1.2 release it looks like hudson is how we're going to make > it going forward. > > Note that for $20/mo a 512MB machine can be run on Rackspace cloud, so > another way that we might be able to get this going is to be able to have > donations to the DSF, and have them get some dedicated rackspace boxes. > However, for now, I'm hoping that we can cobble together enough stuff to get > 1.2 tested really well. > > Feedback > == > > If you have any thoughts on CI, or any advice, I would love to hear it. I'm > trying to make our Continuous Integration setup really kick ass, so feedback > is necessary to do this. I have some notes and ideas that I have been > recording while setting things up over at the pycon etherpad: > > http://pyconpads.net/django-testing > > Let me know if you have any thoughts, questions, or concerns. > > Cheers, > Eric > > -- > 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: Django's testing infrastructure
I think this is a great move and will be an awesome resource for the community. I'm working on getting some CPU time at the OSU OSL and/or from Caktus to contribute to the effort. Cheers, Tobias On Thu, Feb 25, 2010 at 11:08 PM, Sean O'Connor wrote: > A platform we probably should get into the mix is a CentOS/RHEL 5 box. I > suspect a significant portion of the community is stuck on such boxes and > given the ancient versions of everything available under RHEL I'm sure that > there are things which will break there and not in a developer's standard > environment. > > I personally don't have a suitable RHEL box laying around but this seems > like a good candidate for either another volunteer or DSF funds. > > > Sean O'Connor > http://seanoc.com > > > > On Thu, Feb 25, 2010 at 10:54 PM, Eric Holscher wrote: > >> Hey everyone, >> >> During the sprints, I worked to set up a hudson instance for Django. This >> is hopefully going to be the way that we are going to go forward for now >> with doing continuous integration for Django. I have a pretty good setup >> going currently, and want make it really fantastic. At this point in time, >> what we really need now is some more hardware to be able to run tests on. >> >> The current setup is hosted at: http://hudson.djangoproject.com/ >> >> Currently, I have tests running on the following architectures: >> >> Django trunk: >> >> Solaris: >> Python 2.4-2.5 >> Databases: sqlite, postgres, mysql >> >> Ubuntu: >> Python 2.5-2.6 >> Databases: sqlite, postgres, mysql >> >> Django 1.1.X: >> >> Solaris: >> Python 2.5 >> Databases: sqlite, postgres >> >> This gives us pretty good coverage currently, but the whole point of doing >> CI is that we catch bugs on other platforms we wouldn't normally run on. >> >> What we need >> === >> >> So I'm looking for people who can offer other boxes that they would like >> to see tested. Currently the big ones we aren't covering are Windows boxes, >> and the Oracle backends. There are lots of other permutations that we could >> be testing against (Different python runtimes being a good example). >> >> However, we don't want to get in a situation where boxes that people have >> set up just disappear. So, I'm only currently looking for machines that >> people would be able to dedicate to the effort. We would require a >> django-testing user account on the box, with our SSH key on it. There would >> also be a team of trusted users, who would have access to this key and thus >> your machine. >> >> We want the build farm to be stable and useful, and in the past we have >> had too much trouble having machines just disappear. >> >> Requirements >> === >> >> Currently the hudson requirements seem to be about <1GB of disk space, >> with 512MB of ram. I'm also looking into some pony build/barn based >> alternatives that would knock the memory requirements down pretty >> substantially. However, for the current 1.2 release it looks like hudson is >> how we're going to make it going forward. >> >> Note that for $20/mo a 512MB machine can be run on Rackspace cloud, so >> another way that we might be able to get this going is to be able to have >> donations to the DSF, and have them get some dedicated rackspace boxes. >> However, for now, I'm hoping that we can cobble together enough stuff to get >> 1.2 tested really well. >> >> Feedback >> == >> >> If you have any thoughts on CI, or any advice, I would love to hear it. >> I'm trying to make our Continuous Integration setup really kick ass, so >> feedback is necessary to do this. I have some notes and ideas that I have >> been recording while setting things up over at the pycon etherpad: >> >> http://pyconpads.net/django-testing >> >> Let me know if you have any thoughts, questions, or concerns. >> >> Cheers, >> Eric >> >> -- >> 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. > -- Tobias McNulty Caktus Consulting Group, LLC P.O. Box 1454 Carrboro, NC 27510 (919) 951-0052 http://www.caktusgroup.com -- 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-devel
admin action breakage with changeset 12525
changeset 12525 added code that would prematurely exit from the reponse_action method of ModelAdmin if it detected that the "Go" button was not pressed. However this meant the "delete selected" action would not be performed because the view was being posted to from the confirmation screen. I've opened ticket #12973 and included a patch that that gets things working again. But in a way I think there is some more design thinking needed here for 1.3 in terms of how an action follows through. The number of code paths going through the changelist view seems a little convoluted. It would make sense if there was some design pattern that allowed an action to be more self contained and able to perform its action independent from the changelist view. -Preston -- 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's testing infrastructure
On Fri, Feb 26, 2010 at 11:54 AM, Eric Holscher wrote: > Hey everyone, > > During the sprints, I worked to set up a hudson instance for Django. This is > hopefully going to be the way that we are going to go forward for now with > doing continuous integration for Django. I have a pretty good setup going > currently, and want make it really fantastic. At this point in time, what we > really need now is some more hardware to be able to run tests on. Great work Eric! > So I'm looking for people who can offer other boxes that they would like to > see tested. Currently the big ones we aren't covering are Windows boxes, and > the Oracle backends. There are lots of other permutations that we could be > testing against (Different python runtimes being a good example). Two others to put on this list of unusual platforms that need testing (in case they aren't on your radar already): * MySQL has two configurations that require testing: MyISAM and InnoDB. * We also need testing for GIS configurations. Russ %-) -- 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: Status of #1480: "Don't Set TIME_ZONE [...]"
On Fri, Feb 26, 2010 at 8:55 AM, Gabriel Hurley wrote: > Having been bitten by issue #1480 personally, I'm wondering what the > status of this ticket really is? Trac indicates it needs a better > patch and better docs, but there's no information about what changes > are needed. > > If someone will give me some guidance, I'd be happy to wrap this one > up and see it ship in 1.2... In this case, I think it's just a matter of spam that hasn't been cleaned up properly. Looking at the history, the 'better patch, needs docs, needs tests' flags were all set by an anonymous user, and some (but not all) of those flags were reverted very soon after. The ticket hasn't been committed because the ticket hasn't ever been promoted it to ready for checkin, and it's never been put up for consideration on a milestone. >From a quick look at the patch, it looks fine; I've marked it ready for >checkin. 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.
