2012/2/29 Dr. Trigon <dr.trigon@surfeu.ch>

I think this is a somewhat BIG DECISION and you should wait more than
"a few days"! E.g. I myself noticed this just by accident.
You may misunderstand me, this relies to starting the survey, not to deprecating any version! We have just started to talk about this. The survey page is the current proposal, and everybody will notice it when gets a nice colour warning on the screen. :-)

The survey page is for those who are not members of this list. We can directly talk about it here and that page is a help in our decision which should be made on this mailing list as the primary forum of developers. (My call for edit it aimed editing the mboxes on top.)
 

Additionally I do not think it is appropriate to change the code
(wikipedia.py, config.py, ...) just to add a notice for such a "short
term survey" (as you planed it). Either you add this notice permanently
(which would make sense since the support for all earlier version is up
to be dropped forever) or you have to do this survey for much longer
time... (in earlier mails something around august was mentioned - I
think this is much more sensitive - in my oppinion you could even wait
till august '13 ;)
Well, I have never spoken about the actual date of ceasing support for old versions. When I told this two/few months I meant it as a time for reading opinions on survey page, making a decision and creating a roadmap. Possibly with different deadlines for old versions depending on number of users. The transitial time will begin then. Is that OK like this?
A key in user-config.py is useful for users who are annoyed by reading about the survey at each run. After we made our decison and published it on MW, we may write another warning that disregards this suppresssurvey key and it will be reasonable to leave permanently. (In the way as @deprecated does now.)

Having read your notes on toolserver, I think the warning should appear only for version < 2.7.1, and not for 2.7.1 itself as it is widely used (if we already know it has to remain, a survey is unneccessary).

I would agree with the first statement! We should not waste time in
actively remove code that handles older python versions.
I think cleaner code is always a programmer's preference and not waste of time (read the quotation here), but let's talk about it. What about the Python 2.3 stuff in wikipedia.py? Any unneccessary old rubbish will make debugging harder. You may persuade me to leave it untouched, but from the point the decision is made I would like to write new code freely, either it works in ancient versions or not. (My favourite topic is "this if A else that" which is very practical. The magic we do sometimes with 2-element lists indexed by a logical value is marvellous, but much harder to read and uses a reversed logic having 'False' branch before 'True'. Or why not use a dictionary compehension if appropriate?)

I tell you my secret purpose: after disconnecting 2.4 and 2.5 modules from our space station, I would like to bring the code as close to 3.x as possible. Someday we will face the task to switch to 3.x (trunk is not likely to survive this) and we may make it easier if from now on we try to keep this in mind when coding.
 
Also because
other might still want to use older python versions (we do not support
those anymore does NOT mean we activley have to prevent their usage!).
I like Xqt's idea to make a snapshot of the current version ("current" means the time we will determine) that will run forever.
 

If you want to be that radical, I assume you should change to use the
rewrite branch - since as I am aware there a more radical approach is
implemented already (with cleaner code and and and).
There are two reasons I am a bit averse to it: as far as I know it needs installing and I like the purity of trunk to simply copy it, and the last news I read on this list was that rewrite did not read XML dump that is very important for me, what about this? Sure, one day I will have to change, but here I don't speak about my personal needs -- as far as trunk is supported, its code management is our common interest.

--
Bináris