On Oct 10, 12:51 pm, Russell Keith-Magee <freakboy3...@gmail.com> wrote:
> It isn't just a matter of core developers not having enough time to > review a specific patch - it's that there is a lot more design work > required. [snip] > In the case of #3591, there is still a lot of design work required. > That design discussion needs to happen before we know if we're going > to be in a position to commit code. For example, if the only way to > implement the feature well is to introduce major backwards > incompatibilities in the way applications are loaded, we may need to > defer the implementation until v2.0 when we are in a position to break > backwards compatibility. Fair enough, and I'm not disputing that more work needs to be done on the feature. I'm willing to commit time and effort to it, but not without *some* involvement from a committer. The changes for this will get into different parts of Django, and so a design review is not something that can be done quickly. And if it's not a priority for the core devs, then why should they spend what is potentially a fair bit of time on something they don't much care about? I respect that, and likewise don't see much sense in committing my time and effort unless it's mutually agreed to be worth spending the time on. > I will admit that we (the core) haven't done a great job officially > communicating 'state changes' like the start of the feature discussion > phase. When you're in the middle of things, the need to put out blog > posts etc isn't always apparent. This is something that we as a > community (and the core team in particular) need to improve on. > > For the record, the Django release cycle is documented here: > > http://docs.djangoproject.com/en/dev/internals/release-process/#relea... > > Given that almost 3 months has past since the release of v1.1, it's > safe to assume that we're nearing the end of the proposal phase. As I said, I've just been off the list for a while for various reasons, so I'm not complaining about anything. > It's a little more complicated than simply not having enough time > (although that is certainly an issue). As I said earlier, getting on > the list for v1.2 doesn't mean that the core will commit to working on > a problem. It means that we're happy with the design that has been > proposed (or that any pending design decisions can be easily > resolved), and if a patch is ready in time it will get committed. Yes, even if a design has been proposed, you won't get to "we're happy with the design" unless some non-trivial time is spent on looking at it. It's a bit chicken and egg ;-) > Although the feature discussion phase is the normal time for doing > design work, if a feature is big enough, it's reasonable to expect > that the design process may run on for a while. If that means that we > need to discuss the feature during time that would ordinarily be > 'development phase', then so be it. The caveat on this is that > features that we have committed to will take priority, so you might > not always get immediate feedback. Fair enough, but doing a lot of work without some guiding input from the core devs risks being rejected because it isn't what they were expecting and requires more time to think about than they are willing to spend. > Looking at #3591 in particular - another big part of the problem is > that the ticket tries to solve a theoretical problem that, in > practice, doesn't really exist - that of namespace collisions in > applications. I fully acknowledge that Django can't currently support > two applications with the same name - but my experience is that this > simply isn't an issue in practice. If you want to get support for the > ticket, part of your task is to convince someone in the core that it > is a common problem that needs to be fixed. (As a side note - if you > want to kickstart that design process now, feel free - but start a new > thread :-) I don't know that it *is* a big problem, out there. I know it *was* a problem for me when I started looking into it and made my patch, but it isn't a problem for me any more. I do know that every now and again a new person adds themselves to the cc: for the ticket, indicating some interest in the outcome, but it's obviously not thousands or even hundreds of people. However, it does remain a wart, in the face of all that's been said about reusable apps. > Those following the activity on django-dev for the last 6 months will > have noticed the change in stance - prior to v1.1 being released, > proposals were met with "wait until v1.1 is released"; after the > release, there has been a lot of discussion about the specifics of > particular features. This is also reflected in the traffic on the list > - there were 181 messages to django-dev in June, and 458 in September. > Again, this is something we could have advertised better. Yes, and I've acknowledged that perhaps it's just that I wasn't able to follow the list more closely in recent months. > "We'll begin voting on features for 1.2 very soon (today or tomorrow)". Well, "begin voting" doesn't say anything about how long the polling stations stay open :-) > We are still open to new suggestions - Jacob's message was more of a > "last call". However, at this late stage, new proposals will need to > be essentially prêt-à-porter if they are going to be serious > candidates for consideration. Well, that's clearly not so in this case (the "prêt-à-porter" status, I mean). Thanks for the detailed response, Vinay Sajip --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
