Django 1.4 roadmap
Marcob
first and foremost, thank you for Django, which is a wonderful
project.
I realize that this is a volunteer-based project, but I was wondering
if you have any updates regarding the wiki page for the 1.4 roadmap?
(https://code.djangoproject.com/wiki/Version1.4Roadmap)
I'm big on providing feedback as I feel it contributes to the health
of valuable projects like Django.
Thank you in advance.
Ciao.
Marco.
--
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
Marcob
> Dear Django Core Developers,
> I'm big on providing feedback as I feel it contributes to the health
> of valuable projects like Django.
Ops... I really hope I didn't hurt anyone's feelings :-)
Ciao.
Marco.
Aymeric Augustin
> I realize that this is a volunteer-based project, but I was wondering
> if you have any updates regarding the wiki page for the 1.4 roadmap?
> (https://code.djangoproject.com/wiki/Version1.4Roadmap)
Hi Marco,
Unlike previous releases, Django 1.4 didn't get a formal roadmap. So it will contain the features currently listed in the release notes [1], plus those that will be added before the release.
Best regards,
--
Aymeric Augustin.
Marcob
<aymeric.augus...@polytechnique.org> wrote:
> On 24 nov. 2011, at 16:53, Marcob wrote:
>
> > I realize that this is a volunteer-based project, but I was wondering
> > if you have any updates regarding the wiki page for the 1.4 roadmap?
> > (https://code.djangoproject.com/wiki/Version1.4Roadmap)
>
> Hi Marco,
>
> Unlike previous releases, Django 1.4 didn't get a formal roadmap. So it will contain the features currently listed in the release notes [1], plus those that will be added before the release.
Aymeric, thanks a lot!
Btw this is ok for "what", but for just a really rough idea of "when"
a roadmap would be great.
You need a date to be late :-)
Ciao.
Marco.
Russell Keith-Magee
Hi Marco,
I can't disagree. We've been really bad at managing the 1.4 cycle.
Members of the core team have stood up at two DjangoCons (EU and US
this year) an expressed an interested in "faster" release cycles...
and then we've managed to completely fail in delivering on that idea.
I'd say we're certainly overdue for cutting an alpha and starting the
release machinery rolling. What we're missing at this point is someone
on the core team with the spare resources to manage the release
process.
Unfortunately, this is one of those areas where Django falls victim to
being a volunteer project. None of the core team are paid to work on
Django, so there's no workforce that we can compel to deliver on a
timeline, and punishing volunteers isn't an especially a productive
activity.
So -- what we need is for someone in the core team who is able to find
the resources in their schedule to commit to shepherding a release.
Speaking for myself, I know that this almost certainly isn't going to
be me -- my work life has got a lot more complicated since the 1.3
release.
Any practical suggestions on how we can improve on this situation will
be gratefully accepted.
Yours,
Russ Magee %-)
ptone
On Nov 28, 4:40 am, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> Any practical suggestions on how we can improve on this situation will
> be gratefully accepted.
Core has grown, but it seems to me there is a fair amount of cultural
and procedural knowledge that more veteran core members have not yet
transferred, due to understandable lack of personal bandwidth. Being
able to commit to Django-the-codebase does not confer the same
knowledge required to cut a release of Django-the-project.
Perhaps if James Bennet could do a brain dump, in outline form, of the
procedural steps of release on a wiki page to augment the more public
focused: https://docs.djangoproject.com/en/dev/internals/release-process/
Determine if there is someone newer to core (or unfamiliar with the
release process) who is interested in being mentored in the process.
Open a call for current core devs to comment on what in-progress
features they want to champion into 1.4 and get a rough self imposed
due date. If those cluster nicely, use a soft average of those dates
as the target release date for the alpha.
Explicitly determine which core-dev will take ownership of which
remaining release blockers.
I have a few tickets I have in progress, and all I can do from my
position, is do my best to prioritize them, and get the top ones
wrapped up, rather than have all remain uncompleted.
-Preston
Adrian Holovaty
<rus...@keith-magee.com> wrote:
> So -- what we need is for someone in the core team who is able to find
> the resources in their schedule to commit to shepherding a release.
> Speaking for myself, I know that this almost certainly isn't going to
> be me -- my work life has got a lot more complicated since the 1.3
> release.
And that someone will be me. See my post here:
http://www.holovaty.com/writing/back-to-django/
I plan on starting this next week. Is there a list somewhere of what
needs to get done? If not, I can make it, but obviously it'd be great
if that already existed.
Adrian
Aymeric Augustin
> And that someone will be me. See my post here:
> http://www.holovaty.com/writing/back-to-django/
Awesome!
> Is there a list somewhere of what needs to get done?
> If not, I can make it, but obviously it'd be great if that already existed.
I don't know how much you've followed the 1.4 development cycle, so please forgive me if I'm stating the obvious.
No TODO list exists that I know of. However, a bunch of features have already been added. It'd be interesting if you reviewed the release notes and ensured nothing hurts your feelings.
Then, if you're comfortable with this scope, I think we should start the release process as soon as possible. That's what the community expects. At least three core devs, including myself, have expressed their motivation to work on this release. We were just missing someone with enough experience to oversee the process.
Best regards,
--
Aymeric.
Marcob
> On Mon, Nov 28, 2011 at 6:40 AM, Russell Keith-Magee
>
> > So -- what we need is for someone in the core team who is able to find
> > the resources in their schedule to commit to shepherding a release.
> > Speaking for myself, I know that this almost certainly isn't going to
> > be me -- my work life has got a lot more complicated since the 1.3
> > release.
>
> And that someone will be me. See my post here:http://www.holovaty.com/writing/back-to-django/
Wow! Great news!
If only I had been shut up a week more ;-)
Kiril Vladimirov
- Release version 1.4.
- Move to Git/GitHub. I
Luke Plant
> And that someone will be me. See my post here:
> http://www.holovaty.com/writing/back-to-django/
Great stuff!
> I plan on starting this next week. Is there a list somewhere of what
> needs to get done? If not, I can make it, but obviously it'd be great
> if that already existed.
1) Release blockers:
https://code.djangoproject.com/query?status=!closed&severity=Release+blocker&order=priority
2) Broken tests:
http://ci.djangoproject.com/builds
It looks like tests are failing on Oracle and spatialite. I guess any
failing tests need to be added to the release blockers.
3) We don't have a fully documented release process. It seems that only
James Bennett knows exactly what our release process is. Ideally we
would get this not only fully documented but fully automated, perhaps
even with the script checked in to trunk so that any of the core
developers can do a release - whether for alpha/beta/RC/final.
There was a bunch of triage work to do with unreviewed tickets, but
Aymeric polished most of it off recently.
Since we never had a list of features that we were committing to adding
for 1.4, I don't see any reason why we can't release an alpha as soon as
the release blockers are dealt with. I think we've ended up with a
fairly nice set of improvements despite the lack of explicit direction.
https://docs.djangoproject.com/en/dev/releases/1.4/
Regarding the great Python 3 work that Vinay has done, I think this
should be deferred until after the 1.4 release, which will give the core
devs time to get up to speed with how things are going to work going
forward.
Regards,
Luke
--
Noise proves nothing. Often a hen who has merely laid an egg
cackles as if she laid an asteroid.
-- Mark Twain
Luke Plant || http://lukeplant.me.uk/
Jannis Leidel
> On 28/11/11 20:33, Adrian Holovaty wrote:
>
>> I plan on starting this next week. Is there a list somewhere of what
>> needs to get done? If not, I can make it, but obviously it'd be great
>> if that already existed.
>
> 3) We don't have a fully documented release process. It seems that only
> James Bennett knows exactly what our release process is. Ideally we
> would get this not only fully documented but fully automated, perhaps
> even with the script checked in to trunk so that any of the core
> developers can do a release - whether for alpha/beta/RC/final.
Syncing the translations with Transifex hasn't been documented yet, too,
and requires a bit of manual labor, so shouldn't be scripted. But I can
certainly provide the details for that part of the release process docs
when needed.
> Regarding the great Python 3 work that Vinay has done, I think this
> should be deferred until after the 1.4 release, which will give the core
> devs time to get up to speed with how things are going to work going
> forward.
Definitely, we've never intended to ship Python 3 support in 1.4 and I
would even say that targeting 1.5 is a very eager goal giving the amount
of code and non-code work is required to be done for a full port (e.g.
docs, dependencies, etc).
Jannis
Russell Keith-Magee
> On 28/11/11 20:33, Adrian Holovaty wrote:
>
>> And that someone will be me. See my post here:
>> http://www.holovaty.com/writing/back-to-django/
>
> Great stuff!
>
>> I plan on starting this next week. Is there a list somewhere of what
>> needs to get done? If not, I can make it, but obviously it'd be great
>> if that already existed.
>
> 1) Release blockers:
>
> https://code.djangoproject.com/query?status=!closed&severity=Release+blocker&order=priority
>
> 2) Broken tests:
>
> http://ci.djangoproject.com/builds
>
> It looks like tests are failing on Oracle and spatialite. I guess any
> failing tests need to be added to the release blockers.
>
> 3) We don't have a fully documented release process. It seems that only
> James Bennett knows exactly what our release process is.
Partially true. James has documented the release process, although the
link that I had to that document has gone stale. I can't remember if
there was anything particularly sensitive on that release document --
if there was, that might explain why it wasn't in public circulation
and on our wiki or in our docs.
However, the document isn't especially complex -- it's mostly a list
of things to make sure are up to date (like manifest files and version
numbers).
The bigger issue with releases is the bus factor on release keys -- we
sign our releases tarballs, and we don't have a very high bus factor
on the release keys.
> Ideally we
> would get this not only fully documented but fully automated, perhaps
> even with the script checked in to trunk so that any of the core
> developers can do a release - whether for alpha/beta/RC/final.
Absolutely no disagreement here for the mechanical building parts --
it makes perfect sense that a 'releasable' tarball would be an output
of a successful CI run.
However, there are many parts of the build process that can't be
automated -- signing packages, writing blog entries and so on.
> There was a bunch of triage work to do with unreviewed tickets, but
> Aymeric polished most of it off recently.
This has always been one of the biggest tasks for a release --
clearing the decks for 1.3 took me a couple of weeks of spare time --
so Aymeric (and everyone else who volunteered) gets plenty of gold
stars from me for doing this work :-)
> Since we never had a list of features that we were committing to adding
> for 1.4, I don't see any reason why we can't release an alpha as soon as
> the release blockers are dealt with. I think we've ended up with a
> fairly nice set of improvements despite the lack of explicit direction.
>
> https://docs.djangoproject.com/en/dev/releases/1.4/
Agreed. There will always be extra features that we can add (app
refactor, anyone?) but I think we're well past the point where an
alpha is called for.
> Regarding the great Python 3 work that Vinay has done, I think this
> should be deferred until after the 1.4 release, which will give the core
> devs time to get up to speed with how things are going to work going
> forward.
Agreed. No need to either rush the Py3 work, or delay the 1.4 release
any further.
Yours,
Russ Magee %-)
Luke Plant
> Definitely, we've never intended to ship Python 3 support in 1.4 and I
> would even say that targeting 1.5 is a very eager goal giving the amount
> of code and non-code work is required to be done for a full port (e.g.
> docs, dependencies, etc).
I think "experimental Python 3 support" might be nice for 1.5 i.e. use
at own risk, please file bugs etc.
Jannis Leidel
> On 29/11/11 12:23, Jannis Leidel wrote:
>
>> Definitely, we've never intended to ship Python 3 support in 1.4 and I
>> would even say that targeting 1.5 is a very eager goal giving the amount
>> of code and non-code work is required to be done for a full port (e.g.
>> docs, dependencies, etc).
>
> I think "experimental Python 3 support" might be nice for 1.5 i.e. use
> at own risk, please file bugs etc.
I suppose that's for us to decide when the 1.5 release is near completion :)
Jannis
Tomek Paczkowski
Tom Christie
> Since we never had a list of features that we were committing to adding
> for 1.4, I don't see any reason why we can't release an alpha as soon as
> the release blockers are dealt with.
Agreed. There will always be extra features that we can add (app
refactor, anyone?) but I think we're well past the point where an
alpha is called for.
Gert Van Gool
> What happend to "SVN is least common denominator"?
>
> You received this message because you are subscribed to the Google Groups
> "Django developers" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/django-developers/-/5DgmsJ17_8oJ.
> To post to this group, send email to django-d...@googlegroups.com.
> To unsubscribe from this group, send email to
> django-develop...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/django-developers?hl=en.
>
@Thomas, GitHub provides an svn bridge: see
https://github.com/blog/626-announcing-svn-support,
https://github.com/blog/644-subversion-write-support and
https://github.com/blog/966-improved-subversion-client-support
-- Gert
Mobile: +32 498725202
Twitter: @gvangool
Web: http://gertvangool.be
Ian Kelly
> 2) Broken tests:
>
> http://ci.djangoproject.com/builds
>
> It looks like tests are failing on Oracle and spatialite. I guess any
> failing tests need to be added to the release blockers.
I'll make a note to go through the Oracle failures soon. Things have
a tendency to break over time in the Oracle tests when I'm not
watching, mainly because people hard-wire their tests to check for
specific primary keys, not realizing that the oracle backend doesn't
do sequence resets in the same way and isn't guaranteed to see the
same primary keys.
Cheers,
Ian
Aymeric Augustin
2) Broken tests:
http://ci.djangoproject.com/builds
It looks like tests are failing on Oracle and spatialite. I guess any
failing tests need to be added to the release blockers.
Aymeric.
Adrian Holovaty
> On 28/11/11 20:33, Adrian Holovaty wrote:
>> I plan on starting this next week. Is there a list somewhere of what
>> needs to get done? If not, I can make it, but obviously it'd be great
>> if that already existed.
>
> 1) Release blockers:
>
> https://code.djangoproject.com/query?status=!closed&severity=Release+blocker&order=priority
I took care of four of those blockers today:
Autoescaping variable input in template tags
https://code.djangoproject.com/ticket/10912
Select Filter (its "to" box) has 0 height if in a collapsed fieldset
https://code.djangoproject.com/ticket/17218
Admin should hide password hash field by default
https://code.djangoproject.com/ticket/16845
Regression introduced by r16739 -- `ManyRelatedManager.add()` doesn't
commit to database
https://code.djangoproject.com/ticket/16818
We have six remaining blockers. Here's the status (from my
perspective) on the ones I looked at:
_destroy_test_db exposes the production database to possibly
destructive actions from the unit tests
https://code.djangoproject.com/ticket/10868
STATUS: Waiting for a patch.
Improved Auth Password Hashing
https://code.djangoproject.com/ticket/15367
STATUS: Didn't get a chance to play with the patch/branch yet, but it
sounds promising from the comments. I'm happy to help write
documentation on it (which is one of the remaining issues).
https://code.djangoproject.com/ticket/16563
STATUS: This is a weird one, and I'm not sure what the best solution
is. It would benefit from some more eyes.
The other three, I haven't looked at yet...
Adrian