Hi, I maintain the IBM DB2 Django backend (ibm_db_django) project(http://code.google.com/p/ibm-db/). We have been maintaining this extension since Django-1.0 and have always kept it up-to-date. The http://code.google.com/p/ibm-db/ project also provides a Python DBI compliant driver, based on which the Django back-end is built. (For the record, in the past some of our customers have requested for Django to include the DB2 backend in core, which didnt happen). I really like Russell's idea to introduce officially recognized extensions. If that is the outcome of this thread, I would like to add the DB2 extension as officially recognized and will help in setting infrastructure for this if I can. I would prefer the automated test environment for recognized extensions so that any core Django commit will get expose if it cause any problem in some specific backend, In this way committer can raise a ticket against specific backend if any changes required in that.
Thanks, Rahul Priyadarshi On Saturday, March 9, 2013 10:19:30 AM UTC+5:30, Russell Keith-Magee wrote: > > > On Fri, Mar 8, 2013 at 11:23 AM, <ry...@ryanhiebert.com <javascript:>>wrote: > >> from thread "Moving database backends out of the core" >> >> On Mar 7, 2013, at 5:13 PM, Russell Keith-Magee >> <rus...@keith-magee.com<javascript:>> >> wrote: >> >> > There is, however, a possible middle ground, following the example set >> by Flask: we introduce to Django a list of "officially recognised" >> extensions. These extensions are still maintained as external projects, but >> the core team promise to include these projects as part of the testing >> regimen for a release. If the MSSQL backend were recognised like this, we >> would run the full Django test suite against the MSSQL backend, and if that >> testing revealed a bug in the test suite which was identified as being due >> to a change in Django's codebase, that bug would be a release blocker (Bugs >> in the backend itself would still be the backend's responsibility, and not >> release blocking on Django) >> > >> > Looking outside database backends, this could also apply to >> high-profile projects like haystack, django-registration, and so on. This >> would also serve to highlight projects in our community that are 'defacto >> standards', or good examples of reusability, without needing to expand the >> core team or the size of contrib, and show that the core project is >> explicitly interested in the broader ecosystem. >> >> I think this is a great idea. The backend testing makes sense to me (run >> Django's tests). How does testing sanctioned apps work, though? You run >> _their_ tests, and if they are caused by bugs in Django then they are >> release blockers? >> > > Caveat: I haven't given a huge amount of thought to this beyond the basic > idea, so this is all my initial thoughts. > > I can see three options: > > 1) We run the tests. This requires that we come up with a standard for > describing how test environments work. This could be as simple as requiring > that python setup.py test works, and produces output in a known format. > Requiring the use of tox, or Jenkins/Travis configs would be another option. > > 2) We leave running the tests up to individual projects, but require them > to expose test results in a standard way. No idea how this would be > specified, other than possibly a HTTP API endpoint. > > 3) We make it completely manual. This is something that only needs to > happen around release time, so as long as it's relatively easy to run the > full suite of tests manually, it may be possible to manually maintain a > database of "working/not working". > > Option 3 might be the easiest way to get going - after all, you can always > add automation infrastructure later. > > I really like the idea, and would like to help if I can. I imagine the leg >> work will be mostly in setting up the testing infrastructure, although the >> difficult part will be setting guidelines for and choosing apps that should >> be in this group. > > > Agreed that this is more a policy/procedures issue than a technical issue. > I'm not sure what the best approach is for this - I'm open to suggestions. > > As for how to get this ball rolling -- well, I suppose there's two tasks > that could be addressed immediately: > > * A list of candidate packages -- even if it's not the final approved > list, we need somewhere to start > > * A first cut at a site to host this information. > > My local Django Users Group (in Perth, Western Australia) had some > interesting discussions about this sort of packaging project at our last > meeting; I'm hoping to start knocking together some code at our next > meeting. As soon as we've got something to show off, I'll be sure to do so. > > Yours, > Russ Magee %-) > -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To post to this group, send email to django-developers@googlegroups.com. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
