James, thanks for your details answer. Let me put it right here: I'm not complaining about the lack of dedication or progress in the development of Django. It's more about visibility and marketing.
2007/10/1, James Bennett <[EMAIL PROTECTED]>: > 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. It might be very obvious to you what is missing before 0.97 can be released because you're deeply involved with the development and exactly know it. However, I cannot easily find the answer on the web site. Searching the mailing archive shouldn't be the only way to get such kind of information - if that would answer the question at all. Actually, I'm trying to follow the users mailing list for a couple of weeks now (and I'm overwhelmed with information so I have to skip most of the stuff) and couldn't answer the question what is planned for 0.97. > The book isn't dead, and I'll leave further explanation to a search of > the mailing-list archive. This is what I heard on this list, however I raised that issue because it was the first question I was asked after my manager browsed a little bit, found the book, noticed the dates and came to the conclusion that if nothing changed since Jannuary, something ought to be wrong. > 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. Well, open source development is (or at least shouldn't be) not that different to closed source development. When hacking something, you should have an idea on what to achieve and when to achieve it or at least for the progress towards the goal. Document that progress and do not make it a secret. That is what I ask for. > 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. As a software developer my self, I can understand the "when it's ready" mantra, but IMHO that's not an acceptable answer. I mentioned the Eclipse project and how they managed to setup an trustworthy release process. Not only IMHO, time based releases are better than feature driven once, see for example http://video.google.de/videoplay?docid=-5503858974016723264 > > 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. Well, the provided patch seems to work just fine. I understand that something like this must be carefully applied because it might break a lot of applications if done wrong because nearly everybody works on the SVN trunk. However, if there were more stable releases, not everybody would probably work on trunk and you could be more riskaccepting, having on the other hand more people to check out the code, getting quicker to a stable code base. (In theory, this sound so easy, in practice, it's of course more difficult ;) > > 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. Well, do the people who write those tickets know that they are supposed to "defend" their tickets at the "developers court"? :) Right now, it seems they are stalled. Would it help to distinguish bugs and feature requests? > > 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? ;) In an Morcoockish world view, neither true order or perfect chaos are good :) If we assume, that a typical (open source) developer is a worshiper of chaos, management is a faithful believer in the order. I'm just striving for some balance here... > > Will there every be schema evolution? > 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. Unfortune IMHO, because migrations and semi-automatic deployment (capistrano or how it's called) are compelling reasons for Rails. I saw that there's a new project split from the Django SVN at http://code.google.com/p/deseb/ which I bookmarked for further study. Is this the one by the Derek you mentioned? > 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? Their success of course does not original from a single timeline document, but being reliable certainly helps to attract corporations. > Continuing with the theme: how much funding does Trac get from Fortune > 500 companies? The question should be: What should Trac do to get more attention and therefore eventually funding. IMHO it's one of the nicest web based issues trackers and project management solutions out there. It has a clean and easy to use UI, although installation is too difficult for my taste. It definitely deserves more attention. However, such attention can be easily lost by avoidable bad self-marketing. > Some Linux distributions already package from Django's trunk on a > semi-regular basis; you might want to look into their offerings. It's not that I cannot check out SVN and re-submit it to our own VCS, but it just feels unstable. > 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. I have a different opinion: A road map is a statement of intent, a priorization of features and a commitment. Note, that I didn't say time line. Saying, for example, that automagical schema evolution is not part of the road map is for example an important information. This helps to decide whether to invest into the framework or not. While I really appreciate Fred Brooks book cause it contains a lot of truth, it shouldn't be used as a "proof" that software projects cannot be planned at all but as a guide line of what is realistic and doable. > 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. This is what I can understand but on the other hand should it be of interest to make Django a viable solution for more than developers who like what they can now, no questions asked :) > 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. While I agree that developer time should not be wasted and the volunteer work should be highly respected, I do not believe that nobody has a plan on what to do next. This plan has to be coordinated and should follow the "Django vision" of what fits into the project and what not. It is my impression that currently, this vision is shared by the developers but it is not written down. A road map would be a manifested vision (if that's a word)... Regards, -- Stefan Matthias Aust --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
