On 10/1/07, Stefan Matthias Aust <[EMAIL PROTECTED]> wrote: > There's no 0.97 version despites all that changes to SVN trunk for > months.
Because we're not ready for a 0.97 release. The goals for the next release and the general run up to Django 1.0 are pretty well-known, even if they're not meticulously tracked with timers counting down, and no amount of "road map" documentation will get them done any faster. > The documentation clearly advertises the current trunk > version, but the book refers to 0.96. The django book project seems to > have died in Feb. The site does not explain why the missing chapters > where never written/published and what the current state is. The book isn't dead, and I'll leave further explanation to a search of the mailing-list archive. > (Important) changes to the queryset API or admin UI are not applied in > favor to some branched development which seems to be ongoing for > months. Generally, the Django team works to keep trunk as stable as possible; this means that large, destabilizing features get done in branches and then merge back in. By their nature, and by the nature of open-source development, it sometimes takes a while for this process to be completed. > No word on when it will hit the trunk. No word on when the > next Django version will be published. I'll pause for a moment here and step out of responding as a Django user, and step into responding as Django's release manager: the answer is "when it's ready". If you have a foolproof way of figuring out when that will be, you should stop writing code and start making millions of dollars selling your secret to businesses which develop software. > Or what it will contain. Bugs like #2070 are open for more than a year. Yes, but with fairly constant activity. That one is a much harder issue than it appears to be at first glance, as some of the folks who've said "oh, this'll be simple" and started to work on it will tell you. > Of ~800 open tickets, 275 need a design decision, that is need the attention > of > the core team. Yup. Personally, I look at "design decision needed" as meaning "if nobody makes a compelling argument for it, I'll come along and close it eventually". And that's essentially what happens: if a ticket sits at that stage for a long period of time with nobody coming forward and making a case for it, it's probably not something that's worth doing. > There are still 12 tickets from the last sprint (great effort, BTW) > left to check-in. The casual observer easily gets the impression that > work is sporadic, uncoordinated and not target-oriented, in one word: > chaotic. And this is compared to the normal process of software development, which is constant, rigidly-coordinated, always on-target and well-ordered? ;) > While this is no problem in it self (and please do not feel offended, > that's not my intention), it makes it difficult to build products upon > that foundation. Is it useful to invest in the old admin UI? Or should > we go for the new one? When will the query API be improved (we need > aggregations, so I have to patch it)? Will there every be schema > evolution? 1. If you intend to commit to running on a particular version of Django, yes. 2. When it's done. 3. There already is, it's called ALTER TABLE. If you mean automagic deduction of changes, probably not. If you mean some non-SQL syntax that's nonetheless equivalent, well, lots of people seem to want it but so far only Derek and a couple of others have put their code where their mouths are. > A lot of open source projects switched to a time boxed release scheme > because that builds the most trust with users. If the Eclipse > foundation (for example) publishes its mile stone road map you can be > sure they will meet the date and release on time. IMHO one of the (not > so secret) secrets of their enormous success. Eclipse is also in receipt of very generous funding from large corporate sponsors. Who wants to lay odds on whether that has a larger or smaller impact on their success than having a timeline document? > The counter-example is the trac project which tells everybody that > they're now 3 months late with 0.11 and even have missed the next > milestone, too. This tells everybody "hey, we're not able to implement > a realistic schedule and are not even able to update our web page > after we learned that" ;) Continuing with the theme: how much funding does Trac get from Fortune 500 companies? > So, I'd recommend to create a realistic road map. Release every two or > three months. 0.96 or 0.97 communicates that it's almost done. That's > obviously not the case. Just increment a single number. Tell your > users when they can expect larger refactorings. If the problem is lack > of time, try to find sponsors. The current "it's done when it's done" > state of mind makes it difficult to invest in something we do not know > whether, when and how it will evolve. "It's done when it's done" is all I can give you. "It's done even though it's not" wouldn't make any sense, and neither would automatic releases; I'll take quality over quantity any day of the week, and "released later, but finished" over "released now, but doesn't work". > One idea I was playing around in my mind was to create some kind of > "Django distribution", snapshotting the SVN version every month or so, > perhaps adding a few useful 3rd party libraries and creating a ready > to use and easily installable milestone version. That would be useful > for others too, I hope, but I do not want to fork or split the > development. However, I need some patches applied for our own work > faster than in the official version. Some Linux distributions already package from Django's trunk on a semi-regular basis; you might want to look into their offerings. > I'd like to know whether others feel the same and would like to see > (and discuss) a focused road map or whether it's just me who cannot > appreciate the creativity of chaos ;) Personally, I look on timelines and roadmaps as lies dressed up in fancy clothing. When Fred Brooks wrote his famous book on software management, nobody really had a handle on how to plan or schedule software projects. Thirty-two years later, nobody really has a handle on how to plan or schedule software projects. Throw in the nature of an open source project like Django -- where everyone is a volunteer working in their own personal time -- and it becomes impossible to lay down schedules, timelines or roadmaps with any sort of accuracy. They'd be fictions concocted for the sake of soothing middle managers, and that's not a business I'd want to get into. That said, there's a very easy way to get a handle on Django's development: watch the timeline and read the developers' mailing list. Both of them are open to the public, both have more than enough information to let you gauge where things stand and where they're going. There are also several pages on the wiki explaining goals of particular branches/changes, and some developers have even been known to make their to-do lists publicly viewable. Beyond that I don't think there's much we can do at the moment; Django is entirely a volunteer effort and the developers -- correctly, I'd say -- focus their time on getting things done rather than writing up timelines and checklists of what they're going to do. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
