On Thu, Apr 28, 2011 at 3:18 AM, legutierr <leguti...@gmail.com> wrote: > + 100 on this (oh, wait, do I not get that many votes? +10 then). > > Waldemar and Thomas (and the rest of the people contributing to django- > nonrel) have worked very hard to advance Django and expand its use > into new spheres. It would be great to see their work recognized by > the core team, and to begin to see the relevant parts integrated into > trunk. > > Obviously this is only going to get done if one of the core developers > has the time and desire to work with Waldemar and Thomas. As someone > who uses with Django every day and has committed to the platform on a > commercial basis, and as an infrequent contributor, I very much hope > that someone on the core team decides to take them under their wing.
I don't think you'll get much argument from the core team that, in principle, having the infrastructure in place to support NoSQL data stores would be a good thing. Waldemar et al have clearly put a lot of effort into their branch. However, the devil is in the details. Fundamentally, there are two problems standing in the way of this project. The first is resources. I can't speak for any other members of the core team, but looking at my calendar for the next couple of months, I can tell that I'm not going to have as much time to dedicate to Django as I have over the last couple of years. The second is knowing the size of the job that is being proposed. At the moment, this is a completely unknown quantity. I haven't used the django-nonrel branch, and I'm not aware of anyone that I know and trust that has. Django-nonrel has been developed completely independently of django-trunk, with it's own mailing lists, it's own development team, and so on, so Django's core team hasn't had any exposure to the design and development process that has lead to the code that is there. To be completely frank, from my perspective, the code is an unknown quantity at this point. It *might* be fine -- but it might not, on anything from a scale from "needs minor work" to "needs to be rebuilt". I simply don't know, and any process that will lead to me knowing requires me to spend a non-trivial amount of time reviewing the code and it's branch. This is one area where the wiki page could help -- providing a 1000ft view of how the branch does what it does. The current wiki content is a good start, but it needs a lot more detail -- at the moment, it's contains a lot of brief feature descriptions, but not a lot detail on how or why those features work they way they do. So how do we move forward? The assertion has been made that what is needed next is attention from the core. I'd like to propose something different. The core team is already a bottleneck in the whole Django process. The proposed body of work is of unknown size and scope, and will require a non-trivial amount of time to establish scope. This has the potential to consume the limited resources of the core and exacerbate the bottleneck that already exists. >From my perspective, what is needed next isn't attention from the core -- it's attention from the *community*. Personally, the best way to convince me that something is ready for core is when there is broad community support saying it is ready for core. Show me an active discussion on django-dev, involving people that are known to the Django community, arguing the merits of your patch. Show me the discussion that validates why your approach is a better than the alternatives (in particular, better than the approach that has been proposed by one core developer and reviewed by another). Once there's community consensus that the approach is good, *then* the code will be ready for serious review from the core. And because the community has already vouched for the code, there is a much lower risk involved. In reality, this is exactly what we ask of *any* proposal for trunk, but on a slightly larger scale. It isn't the core team's responsibility to review every patch submitted to Trac -- if it were, we simply wouldn't be able to keep up. So, if you propose a small patch, we ask that you get someone independent to review it. I don't think it's too much of a stretch of the imagination to suggest that if you are proposing a big patch, you need to get more independent review. And, for the record, I've asked Waldemar for exactly this in the past [1]. So -- certainly, lets try and get this into trunk. But the first step isn't to monopolize the attention of a core developer for an unknown period of time. Django is a community, not just a core team. That community needs to be involved in the process, especially when we're talking about a change as big as introducing support for non-relational stores. [1] http://groups.google.com/group/django-developers/browse_thread/thread/9208f63b2fb14acc Yours, Russ Magee %-) -- 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.
