I've just posted over in django-dev that I'm intersted in taking over maintenance of this branch ... I'm not to skilled with subversion... but I'm going to go ahead and give it a shot, and attempt over the next two weeks ( out of town for a few days on vacation ) to merge the changes to the trunk into this branch.
Once I get what I think is a proper merge of the newest code... I'll inquire about the next step of how to it committed ... wish me luck :) On May 2, 10:41 am, brutimus <[EMAIL PROTECTED]> wrote: > I've also seen a lot of demand for the multi-db support; however, I do > understand the time that this would take to get updated, stabilized, > and worked into trunk. I have several apps I would like to work on > where I need to pull data from a couple legacy databases > (datawarehouse type dbs), but this proves difficult. To this point, > I've been a little hesitant to run the multi-db branch, but I may have > to look at it and see how that works out. > > If anyone who is capable puts time into getting the multi-db branch up > to par and added into trunk, I know many people would be very > thankful. > > Thanks, Sean > > On May 2, 12:22 am, Brian Luft <[EMAIL PROTECTED]> wrote: > > > Hi Russ, > > > Thanks for the detailed response and I agree with all of your > > sentiments. You're doing a great job and you are a tremendous asset > > to this list. Keep up the great work. > > > Having been a committer to other framework projects, I understand the > > constant pressure to integrate feature X,Y, and Z. I'm totally on > > board with the direction the core devs are taking and have faith that > > the future will see some exciting new developments. > > > I'm open to any or all solutions to this problem. If I can use a > > compact pattern or drop in a metaclass somewhere that will enable this > > functionality then I can certainly live with that. No need to put in > > man hours maintaining a branch if the solution is a simple tweak to an > > existing setup. > > > You're right - "unfortunate" is a value judgement and I really meant > > it would be unfortunate if lack of a feature drove people away. Of > > course that happens anyway (what no ajax support? what no clunky > > templating engine? i pass...) - you know the story. It is very > > fortunate that we have a solid framework being driven by talented, > > dedicated people I can tell you that much :) > > > Cheers > > -Brian > > > On May 1, 9:37 pm, "Russell Keith-Magee" <[EMAIL PROTECTED]> > > wrote: > > > > On 5/2/07, Brian Luft <[EMAIL PROTECTED]> wrote: > > > > > Although I've successfully used the multi-db branch experimentally, it > > > > looks to be getting more and more out of date with the django trunk. > > > ... > > > > Just for the sake of lively discussion, I would go so far as to say > > > > that only being able to access a singledatabaseper project is an > > > > unfortunate limitation and could be a deal-breaker for those > > > > evaluating Django for their own use. I'm sure there are many > > > > .. > > > > Limitation; sure. Unfortunate - that's a value judgement. > > > > The recent Rails/Twitter kurfuffle demonstrates that multi-db support > > > can be very significant for a certain users. However, my time (and the > > > time of the other devs, for that matter) is very limited, and our own > > > itches will always take priority. I have many other features that I > > > want to see in Django before multi-db (aggregate clauses, schema > > > evolution, and model inheritance to name just 3). Multi-db just isn't > > > a priority for any of the ways that I use Django, so there isn't much > > > incentive for me to spend my time on it. > > > > The fact that a branch exists demonstrates that the core devs are > > > willing to entertain the idea of multi-db as a feature. However, it > > > needs somebody to step up to the plate and finish the job. Ultimately, > > > this means submitting a branch in a condition suitable for merge back > > > into the trunk. What does this mean in practice? > > > > - A branch that is up to date with trunk > > > - Evidence that the branch has been used by real users, and bugs have > > > been found and fixed > > > - The existence of test cases that integrate with existing test framework. > > > - Offering to look after the feature for the medium term. > > > > Once you can convince the core devs that these conditions are met, you > > > should find the merge back happens pretty quickly - and voila! > > > multi-db in the trunk. > > > > Now, before we are flooded with "give me SVN access and I'll do it!" > > > requests. We aren't going to give SVN access to just anybody that > > > stands up. We have been down this path, and so far, it seems to be the > > > single easiest way to make sure you never hear from someone ever again > > > (witness themultiplecontributors that have offered to finish > > > schema-evolution). Before you get SVN access, we want to see a track > > > record of contributing first. > > > > Getting started doesn't require access to SVN. If you are interested > > > in multi-db, start working and submit patches. If you demonstrate that > > > you are in for the long haul, you will get SVN access for that branch > > > to make your life a little easier. > > > > So - if you want multi-db (or any other feature, for that matter), have > > > at it! > > > > Yours, > > > Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
