On Sun, Sep 26, 2010 at 6:40 PM, Waldemar Kornewald <[email protected]> wrote: > On Sun, Sep 26, 2010 at 6:54 AM, Russell Keith-Magee > <[email protected]> wrote: >> 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 "Supported and Unsupported features" section is pretty close to what I would like to see. If each of the candidate storage engines had a similar summary from the perspective of a query-refactor compatible backend, we'd be well on the way. If you can get review from others in the community, that would be even better. >> 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 I don't know if there's a communication problem. I've told you my position. At the moment, when I see your file uploads proposal, I see a time sink. There is still a lot of design work required. We've already been through a couple of iterations, and I don't feel like we're really getting any closer to a final solution. My Django time is all volunteered. I need to use it maximize utility of that time. Time that I spend helping you finesse a design is time that I don't spend fixing bugs, committing features, or working on designs from others. I have made a judgement call that continuing to work on your file uploads proposal isn't an effective use of my time at present considering the time it will take to get the design finished, and the potential benefits of the change when it is introduced. In principle, I like the idea of having better support for external file stores. But I'm not the only core team member (or, for that matter, member of the Django community) that can provide feedback. If Jannis can help you get your design closer to being trunk-ready, then that's great. 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
