Re: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Guys
The problem is simple but it was born a very long time ago.
For MySQL 4.1 and higher there is hardcoded in
django/db/backends/mysql/base.py:
cursor.execute("SET NAMES 'utf8'")
there were lots of tickets and messages in django-users complaining to
this but in fact they all were ignored.
Personally my company used to use patched django installation where
this line was replaced to:
cursor.execute("SET NAMES 'cp1251'")
because all our templates were (and still are in the production
environment) in windows-1251 encoding so we have had to use cp1251 to
deal with db.
Ticket http://code.djangoproject.com/ticket/952 contain a complete
solution of this problem and I don't know why it was not merged into
the code but at the moment it is not matter and here is the reason why:
Since newforms library was born and the decision about using unicode
for clean_data was made, all these patches became unnecessary because
now developers must use only unicode everywhere (templates, db etc) or
manually recode all forms based on newforms from unicode to native
encoding and back. Ofcourse this is stupid and noone will do it because
it's easier to migrate to utf-8 and forget about the problem.
So, for me the quesion sounds like this: either newforms don't use
unicode to store clean_data and we can keep using 'legacy' character
sets, or django needs to drop all charsets support except of unicode.
Or it should convert strings back and forth everywhere LOL
Any other opinions ?
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
Re: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Guys Could someone please explain me what was a problem with unicode support in oldforms so newforms have been made with unicode inside ? Kick me if I wrong but what is a real reason to convert bytes back and forth ? Religion ? I agree with everyone who says that unicode is a must and 'legacy' charsets are crap but guys I already have a BIG application that was about 80% migrated from other python frameworks to django some time ago and for legacy reasons it was all in national charset, not unicode. Then I found that oldforms support will be dropped soon or later. So we at here have decided to start moving (yes, moving again !!!) all our code to newforms and what we got ? We got that we now have to recode everything to utf-8 and search for bugs in over than 10k lines of our oldforms-based code until we move everything to newforms and utf-8. But really why ? Did anyone who used unicode with oldform has any problems ? I am sure noone did. Did anyone who used native encodings with oldforms has any problems (except of patch against one line of code I dscribed before or #952) ? Noone did. So guys please explain me what was a reason to make me to migrate to unicode ? Django is a web framework for perfectionists with deadlines. I see may perfectionists here but what about deadlines ? My opinion is simple: let's decide once ether django is for unicode or django supports both unicode and national charsets and then let's work. If you tell me that from now there is only "unicode future" i'd agree and start searching for bugs and sending patches like #3370 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Michael, of you read again the topic about euro sign in newforms you can find that this touches everything. Personally I couldn't find a way to use utf-8 to connect MySQL and keep using cp1251 in my templates: it basically doesn't work. With my patch (#3370) and utf8 everywhere it does. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
> Do you know which parts of django still use bytecode strings? As far as I know, it's only newforms and this is why the topic was born: at the moment newforms work right until you want to put any non- latin1 character through them to db. I've done the patch (#3370) which fixes the issue but it only works when your templates and your db are all in utf-8. And Ivan says this is wrong. From one hand I agree with him: this is not right. From other hand, I open the page http:// www.djangoproject.com/documentation/newforms/ and there's written: "We will REMOVE django.oldforms in the release ...". So if I start a new project based on django, or I extend existing project, there is very strong reason for me to use newforms, BUT they don't work. Confused ? Me too :( Now I would like someone to explain me a few things before I start to do next patches :) 1. newforms are with unicode inside 2. ORM is with str inside Should we (me, someone other) patch ORM to make it store everything in unicode inside it too, or at the moment unicode must be only inside newforms and newforms.model.save() must be fixed to put bytestring decoded data to models ? And another thing I still don't understand is: let's pretend I use MySQL 4.0 with national charset and my templates are in the same charset too. How would work: > the path: legacy (web) - unicode (newforms) - utf-8 (db connection) - legacy > (db) specially the part "utf-8 (db connection)" ? In this situation we must convert strings to our app's encoding at the python side because our legacy db can't do it itself. But we use utf-8 for connection so who and where should do this conversion ? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
After some thoughts I came to the following conclusion: if you guys want to keep support of legacy charsets in fact you don't have to force model objects too be unicoded. Firstly, they are passed to templates and filters and we can't mix legacy charsets with unicode in one template. Next, if I don't use unicode, I don't have to code my python sources (views) in unicode. So, I need to be able to pass string values into my model objects and my strings are not unicoded. So if everyone agreed, the way is simple: 1. when django loads data from db and fills in a model object, all strings have to be encoded according to DEFAULT_CHARSET 2. when django passes data from form object to model object, it has to encode strings according to DEFAULT_CHARSET again In fact, my patch #3370 is wrong then, actually newforms.model.save() method should be patched to recode clean_data from unicode to DEFAULT_CHARSET (if it differs) when passing this data to model object and for now we would get everything in place: utf8-based templates and legacy-charset-based templates would be both correctly supported and any national characters would be stored in db perfectly as they do now with oldforms (ofcourse remember what I said about #952) And the second required patch is about recoding unicode strings loaded from db to DEFAULT_CHARSET (if differs) when passing them to model objects and back from DEFAULT_CHARSET to unicode when we save model objects to db. This patch will solve #952 issue and again it will work ok with both unicode and legacy-charset based templates. And even more here: if we have a legacy database which doesn't understand unicode, we can realize this fact immediately after connecting to db and decide the correct way to decode/encode strings. As I see, this way fixes all unicode/charsets issues and answers all questions. So, if there are no objections, I can write this patch tomorrow or by monday. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: unicode issues in multiple tickets (#952, #1356, #3370) and thread about Euro sign in django-users
Bjorn, if you read my first messages and specially my patch #3370, you find that I made a suggestion that if the guys want to move to unicode they better drop all native encodings support and so does my patch. Then people started to answer me that this is wrong. And at the moment noone is able to explain the whole thing and answer my quesions: 1. how do they want to support templates and python code (views/ scripts) in native encodings if django itself would be all in unicode. The only way i see is to encode/decode everything at programmer's end and this means for me no native encodings support at all. 2. how do they want to support legacy databases if db connection speaks unicode --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
Guys I would like to explain some things and decisions in my code. 1. REMOTE_IP. I think it is a good idea to check it. Load balancers acts as proxy servers. Every web server has a module that allow to restore REMOTE_IP from X-FORWARDED-FOR, for example apache's module is called mod_rpaf. And ofcourse it's very easy to make REMOTE_IP checking code to be disabled or enabled via settings.py, just like it is in php, such modification is quite simple. 2. In my installation I use lighttpd and django as preforked fastcgi server, python 2.4. It's hard to reproduce such things but they _do_ happen. One can say my installation is broken but I think it's rather a hole in django if it allows such things to be ever happened. 3. Perhaps, current sessions may be patched too, what is needed is to force django to try INSERT into table but it looks like dirty hack to me because documentation says: if object's pk evaluates to something else than True, django does checking if such row already exists in db and while django does it, another process may get the same session id and try it too and we get collision again. My way works rock stable because of different table design and this is the only reason why i used another package name (newsession) istead of just patching existing package. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
Even more on remote ip checking: it can be done in a flexible way when user is able to set either don't ever use it, check remote ip, check user agent name or ever both remote ip and user agent for paranoids :) I think everyone understands that it's about 2-3 more lines of 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-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
> I'm still wary of this -- again, it doesn't do anything to prevent > man-in-the-middle, and it introduces complexity and -- if we're > worried about session collisions -- introduces a whole new class of > bugs when you have a bunch of people behind a NAT or firewall who all, > from the POV of your server, have the same IP address. Well I don't agree with you here: 1. This option can be disabled by default and only enabled optionally by developer (like in php, as i said) 2. I have an ethernet connection @home and I sometimes log in to our private web apps from home. Any 'c00l hacker' is able to scan network traffic, get my session id and use it to join to my session too just because there is absolutely no checking who uses session. We added ip checking at our application level code but why don't implement this at django side as an option ? Noone says this is 100% guarantee of getting rid of man-in-the-middle, but at least it prevents from successful hacks from kiddies when using untrusted networks (ie public wi-fi, ethernet, etc). > I think we definitely need to tighten up the time between selecting a > session key and shoving the session into the DB -- I'm thinking along > the lines of using get_or_create and retrying until you get back a > True creation value from it (that way you don't have to do anything > else -- the session is already in the DB when get_or_create returns. > > But I'm still worried about the apparent fact that this is all coming > from key collisions, because what it points to is not a race condition > at the database level -- what it points to is bad randomness. Let's separate problems because there are 2 problems: 1. Somehow same ids are generated in a short period of time. So id generation needs to be improved. 2. Django allows session collisions. I am not an expert in the first problem but I definitely think that second problem must be solved in the way I suggested, instead of shortening time between checking and storing new record to db. Just imagine: you have a gun, that sometimes fires to it's holder. I suggest to change construction to make it impossible in any way, you suggest to change the way how holder should pull the trigger, hold the gun in arms etc but if we don't change the construction, whatever we do there still IS a possibility to shoot yourself :) Hope I explained well enough. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
> so it doesn't get us any real improvement in security James, there is a concept of 'fool proof'. Real hackers may do many things. But current model allows even 10 year old kids to be hackers. This is just against them. There is no ability to protect all sites with ssl and I would not like a neighbor's son could read my email because he got my session id by running simple ethereal > I'm not saying I'm against separating insert and update in the ORM, > though Have you ever looked in my code ? There are no hacks of ORM, there is just a different sessions table design where session id is not anymore a primary key but just an unique key. Primary key is a separate field and this approach allows us to use existing ORM to do things correct way where session collision is impossible at table level, so impossible by design. And again: I am not voting against improving if IDs generation, I think these problems should be solved both. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
Default django installation uses session lifetime equal to 2 weeks with no session expiration at browser close. Just calculate what should be a default strength of session id generator to successfully generate unique IDs within 2 weeks for a web app with 1 000 000 unique visitors per a day. As far as I understood, current generator was checked for duplicates on just 2 000 000 of iterations. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
Michael, I really don't know how would it be possible, I only know the following: 1. My production web server restarts a few times per day. Sometimes twice (in a really short period ie 2-3 minutes) 2. I got a report from _new_ user that he received e-mail with login and pass, clicked to link and became logged in as another user without login and pass entering. Our auth is based on putting user_id in the session so new user must have a new clean session without any data. Any other ideas how he could be logged in as another user, except of session duplicate ? 3. After that report I cleaned django_session table so all existing sessions should be immediately expired. After this I got one more report from another user who said that he used to work in his app (was logged in), then somehow he became another logged in user. I opened logs and found that these users logged in to the system at the same time. And one more thing about ip checking: ok, I agree about network sniffing (but there still is a possibility that sniffering was run after i logged in so attacker could not see my pass but he see my session id :) ). But please don't forget that session cookies may also be stolen via XSS. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
Btw, we use Debian with python 2.4 too --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
As I said, we restart our django fastcgi server a few times per a day. I think it is more related to: > Beginning with python2.4, the seed also uses os.urandom() when available, so > it starts to get safer. and our app runs under xen domU debian installation so may be there's something related to xen kernel entropy --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
Henrique Ser, you lost the fact that we are using lighttpd, not apache, but our django works as preforked fastcgi. I can only say that i will NEVER use a potentially vulnerable session implementation where any not logged in user may get superuser's permission, even if a chance for this to happen are as little as 1 by 10 000 000. "Shit happens", Forrest Gump said. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
Ivan, although reseeding still not guarantees that there may be no duplicates as INSERTing does, isn't it ? And insert needs to be done only once at session start and is performed ANYWAY at session start. The difference in my way is that insert is done when new session is created and in django's way it's done when session needs to be first saved (in the same request anyway) so what is a problem ? --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
Guys The only thing I don't understand at the moment is: everyone understands that current implementation of ORM together with current implementation of sessions table doesn't allow to force insert and throw exception if it fails. So I can state this as a special case. Every framework has limitations and exceptions, here we get one of them. So why don't just redesign the sessions table and change the session implementation a bit to make it match current abilities of current ORM ? It's so simple and even more: it's already done! IP checking stuff touched just 3 lines of code, it requires just one minute to remove it. Or 4 minutes to make it optional. We already spent much more time discussing than it took to write and debug this code to me. --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: newsessions
Malcolm, ofcourse I can rewrite it as a patch to current session module but I think you should understand that anyone who will do svn update would get broken session module because of extra field in django_session table. If it is ok, please answer and I will prepare patch in an hour (without ip checking stuff) --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
MySQL 4.1.x charset support
Hello guys
After playing with Django 0.91 I've found that it behaves not 100%
correct when MySQL 4.1 is used.
File django/core/db/backends/mysql.py contains code:
if self.connection.get_server_info() >= '4.1':
cursor.execute("SET NAMES utf8")
It means that unicode will be always forced when MySQL 4.1 is used but
this may be wrong ! For example I have a russian site which I want to
move to Django. I already have ready html templates and they are in
windows-1251 encoding and I am able to use them with my data when I run
SET NAMES cp1251 without any recoding BUT Django doesnt allow me to do
the same because unicode support is hardcoded.
I wrote a small path to fix this problem. Does anyone need it ? Where
should I post it ?
It's quite simple and just adds a new parameter to the settings file
which is used only when MySQL 4.1 is used (DATABASE_CHARSET) and by
default it is "utf8" to support backwards compatibility.
I think it should be put into upstream. Shouldnt it ?
diff
/usr/lib/python2.3/site-packages/Django-0.91-py2.3.egg/django/core/db/backends/mysql.py
/usr/lib/python2.3/site-packages/Django-0.91-py2.3.egg/jango/core/db/backends/mysql.py.orig
56c56
< from django.conf.settings import DATABASE_USER,
DATABASE_NAME, DATABASE_HOST, DATABASE_PORT, DATABASE_PASSWORD,
DATABASE_CHARSET, DEBUG
---
> from django.conf.settings import DATABASE_USER, DATABASE_NAME,
> DATABASE_HOST, DATABASE_PORT, DATABASE_PASSWORD, DEBUG
70c70
< cursor.execute("SET NAMES %s" % DATABASE_CHARSET)
---
> cursor.execute("SET NAMES utf8")
diff
/usr/lib/python2.3/site-packages/Django-0.91-py2.3.egg/django/conf/global_settings.py
/usr/lib/python2.3/site-packages/Django-0.91-py2.3.egg/django/conf/global_settings.py.orig
83d82
< DATABASE_CHARSET = 'utf8' # Used with MySQL 4.1.x and higher
--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~--~~~~--~~--~--~---
Re: MySQL 4.1.x charset support
Thanks, posted: http://code.djangoproject.com/ticket/1528 --~--~-~--~~~---~--~~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~--~~~~--~~--~--~---
Re: first() and last(), earliest() and latest()
On 02/27/2013 05:34 PM, Wim Feijen wrote:
Hi all,
We struggled to get a proper definition for a first() and last()
method vs. earliest() and latest() . I'd like to make one proposal.
After that, I really like your opinion on which syntax you prefer.
First, let me give you a lenghty introduction. We discussed several
use cases on this mailing list
<https://groups.google.com/forum/?fromgroups=#%21searchin/django-developers/get_default/django-developers/3RwDxWKPZ_A/mPtAlQ2b0DwJ>.
Then, I realized that:
.filter(last_name__startswith='b').order_by('last_name').first()
is an acceptable compromise for me to use in stead of:
.first(last_name__startswith='b').order_by('last_name')
Last weekend Aymeric explained to me that earliest can actually
accomplish the same:
.filter(last_name__startswith='b').earliest('last_name')
Then, I find "earliest" an inappropriate name, because it does not
describe functioning well.
Therefore, my proposal is, if we are going to implement the earliest
and latest method, we should definitely rename them to: first and latest.
After that, there is only one question left:
Which style do you prefer?
.filter(last_name__startswith='b').order_by('last_name').first()#
clear and long
.first(last_name__startswith='b').order_by('last_name')# first
method has filter syntax.
.filter(last_name__startswith='b').first('last_name') # first method
has order_by syntax.
So, what do you think?
Best regards,
Wim
How about first as a function? I think it's very often useful not just
for querysets but
for all kind of iterables:
def first(iterable, default=None):
try:
return next(iter(iterable))
except StopIteration:
return default
-ak
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Perception of attitude in tickets
On 05/13/2013 11:23 AM, Jacob Kaplan-Moss wrote: On Mon, May 13, 2013 at 2:12 AM, Chris Wilson wrote: >> The status WONTFIX sounds awfully rude to me. > > I've thought so, too, but every time I've tried to come up with an > alternate name I've failed. Any suggestions? WONTFIX does sound rude to me, as well. Perhaps 'onholdindefinite' can be used instead, the effective meaning is the same, just the term itself is more polite. It seems that nobody looking at it would think "I'll just wait for a while and surely it'll get fixed.". Instead, anyone needing it would think "If it is to be fixed, it's clear someone has to make a case for it." -ak -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Perception of attitude in tickets
On 05/13/2013 12:11 PM, Luke Sneeringer wrote: > On May 13, 2013, at 10:06 AM, AK wrote: > >> WONTFIX does sound rude to me, as well. Perhaps 'onholdindefinite' can >> be used instead, the effective meaning is the same, just the term itself >> is more polite. It seems that nobody looking at it would think "I'll >> just wait for a while and surely it'll get fixed.". Instead, anyone >> needing it would think "If it is to be fixed, it's clear someone has >> to make a case for it." -ak > > Note: "won't fix" is used on many bug systems, not just Django. So, in choosing to go for a euphemism, you're also (unintentionally) obfuscating, because you're subtly communicating that it's somehow different than the standard "won't fix". > > Best Regards, > Luke Sneeringer > I should have mentioned that I know it's used on other bug systems, and that I agree it's less clear. It's a tradeoff that you often have when you try to be polite: the alternatives are usually more blunt and clear. In this particular case, I don't think it's a problem because there are only two choices here - either someone cares about the ticket being fixed, or not. If not, there's no problem. If yes, the main message will not be lost: "this ticket isn't going to get fixed and you have to convince someone if you want that to happen." I agree 'onholdindefinite' is a bit awkward, I think it's a bit better than wontfix but wontfix isn't terrible either. -ak -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
Re: Perception of attitude in tickets
On 05/13/2013 01:16 PM, Anders Steinlein wrote: On Sun, May 12, 2013 at 2:06 AM, Russell Keith-Magee wrote: > > > Looking for a positive outcome here -- my question to the community, and especially those that feel that we've been unresponsive here: how do we improve the situation? > > > I've been lurking on this thread (and list in general for that matter), and thought I'd throw in my $.02 as someone interested in, but not (yet) involved in, development of Django itself. > > I very much understand the policy of having discussions on the mailing list (particularly in the view of duplicate/related tickets), but I also see (and sometimes myself feel) the frustration OP brought up. > > Why allow comments on tickets at all when discussions are meant to happen here? I understand the need to comment on the specifics of patches/doing reviews, but from a (new) user's point of view, those are just comments like any other. When some comments are welcome, but others are not, how are new user's supposed to know where to discuss what? > > How about allowing comments only from the patch author and committers? With a big fat informational text in place of the add comment section? How about adding a button/link directly to the Google Group with "open for discussion" or some such? Just throwing out some ideas here. > > Regards, > Anders > -- Perhaps a good rule would be: if you ask someone to raise the issue on mailing list, a link to the google group page must always be given in the same comment. It's reasonably easy and it's a lot more inviting to give the link vs. "There's a mailing list out there somewhere, go and find it, why don't you?" -ak -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
