Re: A bunch of little fixes
Malcolm Tredinnick wrote: > I just did a random sampling of four tickets and #10504 is a feature > addition, it can wait until 1.2 (and maybe even then isn't actually > something to do, since render_to_response is a *shortcut*, not a > complete replacement). true, not really a problem here > #10647 and #9992 are already in the 1.1 milestone > an #10528 has been fixed. amusing, they were closed almost at the same time of my mail :) no problem here again > My point being, we already have a huge list of open tickets that are > being worked on and you must be aware that we're in the lead up to a 1.1 > release. Posting a list of ticket numbers with no explanation of why > they're more important than the existing ones isn't helpful. Size > doesn't matter at this point. Sometimes the quick ones won't be fixed > first, because they're something that, by definition can be fixed in > idle moments when we're taking a break from something else, or towards > the end in a hurry. It's the problems that are big bugs requiring more > thought that have to be done first, since they are the ones that could > well take a lot longer to resolve than we can reliably estimate. > > Regards, > Malcolm yes, I was *too* concise, my bad: yes, they can wait 1.1 release (as I track trunk) but for some of them I would like to be resolved ASAP * add app_label name to related_name http://code.djangoproject.com/ticket/9638 Here we have a some abstract model which are inherited from a lot of application models, and it breaks when we have two (or more) models with the same name. Actually I've monkey patched django model.ForeignKey to use a custom contribute_to_class which bypasses the original one. I've copied what original contribute_to_class does and integrated with RelatedField.contribute_to_class, throwing away only if hasattr(sup, 'contribute_to_class'): sup.contribute_to_class(cls, name) which doesn't work. It works but it's a solution I'd really like to throw away ASAP * check action permission http://code.djangoproject.com/ticket/10609 I think this is already managed by r10408, so no more a problem here * application names i18n in admin http://code.djangoproject.com/ticket/10436 This fix a really bad situation for our customers, which have the admin site in italian language and where the model names are in italian language and the application names are in english one. They are always confused by this. Thanks for your time -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele at salmaso punto org | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: A bunch of little fixes
On Fri, 2009-04-03 at 17:50 +0200, Raffaele Salmaso wrote: > * add app_label name to related_name > http://code.djangoproject.com/ticket/9638 [... etc, etc...] What are you wanting to achieve here? Are some of these actual bug fixes (as opposed to feature enhancements) that are not already in the 1.1 milestone and cannot wait until later? I just did a random sampling of four tickets and #10504 is a feature addition, it can wait until 1.2 (and maybe even then isn't actually something to do, since render_to_response is a *shortcut*, not a complete replacement). #10647 and #9992 are already in the 1.1 milestone an #10528 has been fixed. My point being, we already have a huge list of open tickets that are being worked on and you must be aware that we're in the lead up to a 1.1 release. Posting a list of ticket numbers with no explanation of why they're more important than the existing ones isn't helpful. Size doesn't matter at this point. Sometimes the quick ones won't be fixed first, because they're something that, by definition can be fixed in idle moments when we're taking a break from something else, or towards the end in a hurry. It's the problems that are big bugs requiring more thought that have to be done first, since they are the ones that could well take a lot longer to resolve than we can reliably estimate. Regards, Malcolm --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
A bunch of little fixes
* add app_label name to related_name http://code.djangoproject.com/ticket/9638 * creation of m2m not managed tables http://code.djangoproject.com/ticket/10647 * avoid a js error in admin pages http://code.djangoproject.com/ticket/10651 * check action permission http://code.djangoproject.com/ticket/10609 * unicode name in unique_together http://code.djangoproject.com/ticket/10645 * pass content_type in render_to_response http://code.djangoproject.com/ticket/10504 * application names i18n in admin http://code.djangoproject.com/ticket/10436 * excluded fields can be updated http://code.djangoproject.com/ticket/10363 DOCUMENTATION = * file upload http://code.djangoproject.com/ticket/10400 * clarify get_object_or_404 parameter http://code.djangoproject.com/ticket/10709 * clarify admin reverse names http://code.djangoproject.com/ticket/10528 * **extra_parameter in test client http://code.djangoproject.com/ticket/9607 * get_profile/get_model http://code.djangoproject.com/ticket/9992 -- ()_() | That said, I didn't actually _test_ my patch. | + (o.o) | That's what users are for! | +---+ 'm m' | (Linus Torvalds) | O | (___) | raffaele at salmaso punto org | --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
