On Mon, 2007-10-01 at 14:21 +0200, Stefan Matthias Aust wrote: > 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.
This sentence highlights a fairly big problem with trying to rush to conclusion. "Seems to work just fine" is only one criteria on which a patch is to be judged. Other necessary requirements security, portability, and maintainability (both simplicity and robustness). All of those latter three have been issues with various patches in #2070 in the past, as can be seen from the comments in the ticket and on django-dev about it. Given the size and intrusiveness of the patch it takes some time to review each major change. We will land it at some point and it's a shame we haven't done so previously, but the delay hasn't been because we've all been taking a nap or partying heavily. [...] > > > 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? Firstly, realise that there are obviously differences of opinion (James said "personally" in his reply, quite correctly) and practice about how we use these particularly statuses. We do tend to collapse a few separate things into single items like "design decision needed", but it's a considered trade-off and has been discussed both here and on django-dev in the past why we are doing that. Setting aside the hyperbolic language, I'd like to point out that "design decision needed" quite often means just that, too -- and I say this as one of the people who helps make those decisions and resolve those tickets. It's not just a holding place where tickets go before they die. Quite a few bug reports and enhancements requests (mostly the latter) need some serious thought before we go one way or the other. The logic being that once we make a decision, it's much easier if we are able to consistently refer to the earlier decision during any repeats of the issue. That requires us to get it mostly right when we do make the decision. We are not going to be rushed into making decisions merely to show faux-progress when we can't back it up with thinking. Of course, lower priority issues are going to languish a bit longer than more pressing needs. Somebody who wants to count open tickets instead of looking a bit deeper isn't going to like that, but since we're not catering to that audience, it's not really a big deal. The substance is in the ticket bodies, not their status or our response speed. We intentionally removed severity and priority fields from our Trac, since although they are very useful on one level, they are also highly prone to be abused or misunderstood in a system where anybody can adjust them. They added a maintenance burden that wasn't justified. This means people looking at a ticket that might still be open after a while are going to have to spend a little bit of time searching the mailing archives and other places (all of which show up in Google), but this isn't a truly onerous requirement if somebody genuinely cares about an issue. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
