Thanks for the input and the info. I'll have a look at those issues and hopefully get them sorted before the sprint. Ben
On 12/09/2007, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > > > On 9/12/07, Ben Ford <[EMAIL PROTECTED]> wrote: > > Thanks for the responses guys. > > Russ what is your feeling about getting multi-db into the repo so that > > people can then use it? I'm happy to do the work that I mentioned above > in > > merging the branch up to date to the point of the backend refactor in > trunk, > > and after that to start exploring re-factoring the multi-db to leverage > some > > of the later changes in trunk. But I'd really like to ensure that I can > send > > the patch to someone and thence get it into the repo. > > Is the diff on #4747 the latest version of the patch that you have? If > so, I have a few reservations about applying this diff. > > Just taking the first few changes in the patch (django/test/utils.py) > as an example: > - The very first change is a multi-line import, which, while legal, > isn't good form. > - The next block of changes involve introducing an > instrumented_test_iter_render, which doesn't exist in the current > trunk. > - The next change (around line 117 of the new version) hard codes the > location of a database file in your personal home directory. > > I haven't worked through the full 200k patch, but if the first few > changes are any indication, there is still work to do before this gets > merged. > > There are two sets of changes that need to be applied: merges from > trunk, and new code. These patches need to be kept separate for commit > purposes, and each new idea should be a separate patch, committed > separately. From all appearances, the patch on #4747 is a mix of both > merge changes and new features. > > I'm happy to apply any patches that are raw merges from trunk. If you > also have some fixes/enhancements that go beyond trunk merges, I'm > happy to look at them, although they will have to meet a basic quality > standard. > > > Once we're to that > > point maybe we can re-explore the possibilities of me having commit > access > > to the branch and acting as maintainer. > > That's an issue you'll have to take up with Jacob and Adrian - they're > the ones that control access to SVN. However, as I have said many > times before, access to the repository is generally restricted to > those that have an established track record. > > Regarding using some sort of distributed version control - there is a > semi-official Mercurial repository available; it's been mentioned in > the developers list a few times. > > Yours, > Russ Magee %-) > > > > -- Regards, Ben Ford [EMAIL PROTECTED] +628111880346 --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
