January 14, 2011
The DjangoCon Europe 2011 organizing committee, chaired by Remco Wendt, has just announced that DjangoCon Europe 2011 will be held in Amsterdam, the Netherlands, from June 6-10 2011. The conference itself will take place on June 6-8, the sprint days will be June 9-10. Though the word was already put out on twitter, the announcement is now available on the official site, http://www.djangocon.eu.
The conference venue is a former warehouse, part of the old port of Amsterdam. The sprint location is a place called "De Waag" which is an old castle in the very heart of Amsterdam, and is famous for housing the Amsterdam Guild of Surgeons during the 17th century.
The sprint location will be open for us 48-hours non stop, meaning literally that we can sprint until we drop.
Hope to see you in Amsterdam in June!
January 5, 2011
The first major task in ensuring a timely Django 1.3 release has been completed: the backlog of unreviewed tickets has been cleared. As of the time of writing, every ticket in Django's ticket tracker has undergone at least an initial review.
As a result, we can now give our first report on progress towards the 1.3 release. At the time of writing, there are 20 tickets known to be release blockers; for an up-to-date list, check this Trac query.
To be considered a release blocker, a ticket must describe a problem that:
- is a regression in behavior from Django 1.2; or
- demonstrates a design flow or bug in a feature added in Django 1.3; or
- reveals a problem in Django's packaging or release procedures; or
- can cause catastrophic and unintentional loss of data under easily reproducible circumstances.
Everything else is nice-to-have, but will not prevent us from releasing Django 1.3 on schedule.
The good news is that most of the release blocking tickets are relatively minor issues. They are either regressions that have occurred due to inadequate test coverage, or relatively minor oversights in features added in 1.3. As a result, we appear to be on schedule for an on-time release (i.e., release candidate in the week of January 24, Final in the week of January 31)
Once the release blocking tickets have been addressed, attention will turn to tickets that are Ready For Checkin. Ideally, there will be no Ready for Checkin bug fixes when we make the final 1.3 release -- all tickets in the Ready For Checkin queue will hopefully either be checked in, bumped back to Accepted because the proposed patch is flawed, or represent a feature than needs to wait for the 1.4 release cycle. We will reassess the Zero-RFC goal as we get closer to the release candidate deadline.
It's important to note that a ticket marked Milestone 1.3 is not automatically guaranteed to be part of the 1.3 release. If you have a ticket that is on Milestone 1.3 and you want to see it actually get committed to 1.3, then you need to get it reviewed by someone so it can progress to Ready For Checkin. If it isn't Ready For Checkin, it won't be checked in!
There's plenty to do if you want to help out:
- Write a patch for a release blocking bug
- Review someone else's 1.3 Milestone ticket
- Write a patch for a 1.3 Milestone ticket (and get someone else to review it)
- Proof read the documentation for errors, omissions, and typos
- Run your own sites against trunk and report any regressions or problems
- Try using new features and report any problems you encounter
The more help we get, the better the 1.3 release will be.