On Sun, Sep 26, 2010 at 6:54 AM, Russell Keith-Magee
<russ...@keith-magee.com> wrote:
> On Sun, Sep 26, 2010 at 1:24 AM, Waldemar Kornewald
> <wkornew...@gmail.com> wrote:
>> On Sep 25, 4:21 pm, Russell Keith-Magee <russ...@keith-magee.com>
>> wrote:
>>> My reason for wanting this is that I'm simply not an expert in any of
>>> these backends. I know SQL quite well, but I haven't had occasion to
>>> try out other backends in depth. I can judge the technical merits of a
>>> patch based on what I know, but I don't want to make a judgement based
>>> on incompletely knowledge. I need to rely on those that I know and
>>> trust to give me confidence that nothing has been missed.
>>
>> This is really the biggest problem. If you work in a company where
>> your lead developer or manager doesn't know enough about the
>> technology and for that reason wants to have a huge amount of analysis
>> and review how are you going to get anything done? You'd surely call
>> such a company dysfunctional.
>
> OK - I call bullshit.
>
> What you appear to be saying is that when a person in a management
> position knows that they don't have expertise in a particular area,
> the appropriate response is to find the first person that volunteers a
> solution, and accept their answer as gospel truth?
>
> I am well skilled in SQL. I am probably one of a handful of people who
> can call themselves an expert on the inner workings of Django's ORM. I
> am an expert on the mental model that Django's ORM is trying to push,
> and the sorts of architectural decisions that will and won't be
> acceptable to the core.
>
> I am not well skilled in NoSQL. I have tinkered enough to understand
> the broad issues, but I don't have particular expertise in any of the
> backends. I'm interested in adding NoSQL support to the core of
> Django. Therefore, I'm calling for people who *do* have expertise, and
> whose expertise I know I can trust, to provide direction that nothing
> important has been missed in the analysis.
>
> Calling for expertise when you know you're lacking isn't dysfunctional
> management. It's responsible management.

Agreed. However, in its *current* state, the only guaranteed
contributors you have are people who aren't trusted and the only
contributor who has decision power is you. This constellation is
dysfunctional and that's what I'm talking about.

Your calling for expertise is the right thing to do. And my whole post
said this: If your call for expertise is not successful the team stays
dysfunctional (unless you acquire the required expertise yourself) and
this means any further work on NoSQL support has a high chance of
being wasted time.

Note, I still want to get the file uploads patch into Django. I don't
intend to completely stop contributing. It's just the current
situation around the NoSQL project that I don't find very attractive.

> Also, you say a "huge" amount of analysis -- at the moment, *any*
> analysis would be a step in the right direction. I haven't seen *any*
> summary of the features that are and are not supported by various
> backends. The summary pages that I directed your attention to (for
> CSRF and session messages) were not hundred page tomes. They were
> concise, 2-3 page summaries. A similar effort, signed off by someone
> (or someones)  I trust is all I'm asking for.

I think I misread that part. Here's a little listing of what's
supported by the djangoappengine backend:
http://www.allbuttonspressed.com/projects/djangoappengine
I'm not sure if that's what you want to see or if it's too concise.

The MongoDB backend has basically the same constraints except that it
natively also supports __iexact, __istartswith, __endswith, and
__iendswith (though, not very efficiently). It also adds a field for
embedded documents.

> So far, your contributions to Django consist of two things:
>  * Maintaining the non-rel fork
>  * A large proposal to change the way file uploads work.
>
> The file uploads patch has been through several drafts, consumed a lot
> of my time, and still isn't in a trunk ready state. This doesn't lead
> me to a position of trusting that your other work is trunk ready; and
> the discussions that we've had (both on file uploads, and on earlier
> iterations of noSQL) haven't led me to a position where I feel I can
> trust that your design decisions are compatible with the general
> philosophy of Django's core.

There seems to be a communication problem (is it a mistake on my
side?). You seem to expect a cleaned up trunk-ready patch for the file
uploads feature. In my last email I thought it was clear that I
expected to get feedback on the high-level end-user API before
starting to clean up everything, improving the function/class naming,
etc. I have more fundamental questions like: Should the "tag" be based
on the path to the Form/Model/ModelAdmin class? BTW, on Thursday
Jannis Leidel has started commenting on the proposal, too (thanks a
lot!):
http://code.djangoproject.com/ticket/13960

Bye,
Waldemar

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers" group.
To post to this group, send email to django-develop...@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.

Reply via email to