Dropping support for old Python versions in Django 1.4
Łukasz Rekucki
deprecation plan of old Python versions (namely 2.4 and 2.5). The
major argument against dropping 2.4 was RHEL support. RHEL6 seems to
support Python 2.6 (dunno about CentOS), so is that still a blocker ?
As for dropping 2.5, the potential issue is that it's still quite
widely used by hosting services (would be nice to have some fresh data
about this; http://www.djangosites.org/stats/ is useful, but probably
a bit outdated).
I wanted to start this discussion before 1.3 is released, because I
think that if we decide to drop 2.4, we should give an early warning
in 1.3 release notes, so that people can switch over more smoothly.
Best regards,
Łukasz Rekucki
John Anderson
I think dropping 2.4 would be a good idea but I think 2.5 needs to be
kept around so that Django can continue to run on appengine. I don't
believe appengine has any plans of moving to 2.6+ any time soon.
VernonCole
ig 2.5 would be harmful to that implementation.
CentOS will be the same as RHEL.
On Feb 4, 11:26 am, John Anderson <son...@gmail.com> wrote:
> On Feb 4, 2011, at 12:23 PM, Łukasz Rekucki wrote:
>
> > With Django 1.3 almost out, I would like to ask, what's the current
> > deprecation plan of old Python versions (namely 2.4 and 2.5). The
> > major argument against dropping 2.4 was RHEL support. RHEL6 seems to
> > support Python 2.6 (dunno about CentOS), so is that still a blocker ?
>
> > As for dropping 2.5, the potential issue is that it's still quite
> > widely used by hosting services (would be nice to have some fresh data
Russell Keith-Magee
Sorry for taking so long to respond.
The issue of dropping supported Python versions has been raised a
number of times in recent memory, so I'm not sure another discussion
is required. The major issues involved are all well known, and core
team are well aware of them, so it really just comes down to us
composing a coherent policy and making that public.
That said: I completely agree that this is something we should do
before 1.3 final, and include in the release notes.
Yours,
Russ Magee %-)
Ben Ripkens
my name is Ben Ripkens and I'm planning to contribute to the Django
project through this years Google Summer of Code. I found the ideas page
for 2011 [1] and even though it seems not publicly available I'm curious
whether the mentioned ideas are up to date, available and whether you
are applying at all (the list is lacking mentors).
I'm especially interested in the idea called "Multiple timezone support
for datetime representation" (for which the issue is not fixed) as I had
a similar issue in my last project where the customer asked for timezone
support during the final presentation (final internship presentation,
the goal was documentation and visualization [2, 3]). I guess that this
idea is still available?
"Am I good enough?" is a question that I'm constantly asking myself with
regard to such a big and important project. I have a solid knowledge
about the general Software Engineering field, i.e. software
architecture / design, development processes, testing, object
orientation, various programming languages... [4], but I only recently
started to learn Python and Django. I'm planning to expand my knowledge
in this area in the next weeks so that I should me all expectations. Do
you have any suggestions what I should focus on during that time
(already started investigating the naive datetime implementation and
pytz)?
This should be enough for one mail :).
Cheers,
Ben
[1] http://code.djangoproject.com/wiki/SummerOfCode2011
[2]
http://code.google.com/p/opendecisionrepository/wiki/FinalInternshipPresentation
[3]
http://bripkens.de/blog/2010/12/open-decision-repository-relationship-view-preview/
[4] https://www.xing.com/profile/Ben_Ripkens (unfortunately only some
information is shown to guests)
Russell Keith-Magee
<bripke...@googlemail.com> wrote:
> Hello Django developer community,
> my name is Ben Ripkens and I'm planning to contribute to the Django
> project through this years Google Summer of Code. I found the ideas page
> for 2011 [1] and even though it seems not publicly available I'm curious
> whether the mentioned ideas are up to date, available and whether you
> are applying at all (the list is lacking mentors).
Yes, we are intending to apply; you're just a lot further along in the
process than we are :-)
Mentor organizations can't apply until the end of Feburary, and
Student applications don't start until late March.
Of course, you're free to use the time between now and then to get
your proposal into good order, and to get acquainted with the
community.
> I'm especially interested in the idea called "Multiple timezone support
> for datetime representation" (for which the issue is not fixed) as I had
> a similar issue in my last project where the customer asked for timezone
> support during the final presentation (final internship presentation,
> the goal was documentation and visualization [2, 3]). I guess that this
> idea is still available?
Yes - this project is still available. Nobody tackled it last year,
and it's still a problem that Django has.
> "Am I good enough?" is a question that I'm constantly asking myself with
> regard to such a big and important project. I have a solid knowledge
> about the general Software Engineering field, i.e. software
> architecture / design, development processes, testing, object
> orientation, various programming languages... [4], but I only recently
> started to learn Python and Django. I'm planning to expand my knowledge
> in this area in the next weeks so that I should me all expectations. Do
> you have any suggestions what I should focus on during that time
> (already started investigating the naive datetime implementation and
> pytz)?
Here are some off-the-cuff suggestions:
* Make sure you *really* grok timezones.*Really* study datetime and
pytz, and make sure you understand how all the pieces fit together,
and where the sharp edges are.
* Research the status quo. How does Django currently handle times and
dates? How does system timezone interact with database timezone and
Django's own timezone variable? Does this vary between databases? Does
it vary between operating systems?
* Come up with a solid proposal of exactly what you're planning to
do. "I'm gonna fix timezones" is a title, not a project plan. As far
as scheduling goes, If you can't explain to the granularity of
individual weeks where you'll be spending your time, then you probably
don't understand the project. And "7 weeks implementation, 3 weeks
testing, 2 weeks documentation" isn't a plan, either.
* Get familiar with the Django community. Lurk on django-users and
django-dev (mailing lists and IRC). Answer questions if you can. Read
past discussions (especially discussions around GSoC projects) and see
what has and what hasn't worked in the past; get a feel for the design
'taste' of the core team and the community as a whole.
* Try and fix a few bugs, or review the patches of others. We're
coming up on a 1.3final release, so now is a great time to fix some
little annoying bugs or help someone else get their fix into trunk.
Overall -- the best advice I can give you is to get involved. The
people who have had the most successful Django GSoC projects didn't
treat it as a once off, 12 week exercise. They got involved long
before the official start, and treated the GSoC process as a way to
really get embedded in an open source community. Some of them have
even ended up as Django core developers.
Best of luck with your GSoC application!
Yours,
Russ Magee %-)
Ramiro Morales
On Thu, Feb 10, 2011 at 4:48 AM, Ben Ripkens
<bripke...@googlemail.com> wrote:
> Hello Django developer community,
> my name is Ben Ripkens and I'm planning to contribute to the Django
> project through this years Google Summer of Code.
I'm replying because I'm the one that created that page mostly as a initial
draft by copying the GSoC '10 page and updating the deadlines.
One core developer has already pointed that he wants to refactor
that page to be more clear.
> I found the ideas page for 2011 [1] and even though it seems not publicly
> available I'm curious whether the mentioned ideas are up to date, available
Yes, the list is up to date in the sense that the projects mentioned
haven't been implemented, with the exception of the last one (Testing updates)
that has been partially completed. Also, most surely there will be new
ideas added.
> and whether you are applying at all (the list is lacking mentors).
>
Yes, we intend to apply this year. And I suspect there will be more activity
from potential mentor once we get 1.3 out the door this month.
The updated schedule for the 1.3 release and the project application period
seem to fit nicely.
> I'm especially interested in the idea called "Multiple timezone support
> for datetime representation" (for which the issue is not fixed) as I had
> a similar issue in my last project where the customer asked for timezone
> support during the final presentation (final internship presentation,
> the goal was documentation and visualization [2, 3]). I guess that this
> idea is still available?
Yes, it is.
I see Russell has created a complete reply to the rest of you email so
I will stop here because there is now way I could be more clear than him :)
--
Ramiro Morales
Łukasz Rekucki
I know that you know :). I just wanted to give the issue a kick, so it
doesn't get overlooked.
--
Łukasz Rekucki