On 30 loka, 14:54, Florian Apolloner <f.apollo...@gmail.com> wrote: > +1, debugging is just hard on travis (although I assume I could download > their vm and test locally, but usually local stuff works :( ). We could > choose a lightweight route and just enable travis for sqlite to get pull > requests tested [Which would be pretty useless for eg postgres patches]. > But using Jenkins __and__ Travis-CI to test all combinations on both > systems will consume more time than we have.
If PR-testing is easy and reliable (as in doesn't take much time from our committers to maintain) then SQLite testing of pull requests on py2 + py3 would be a good addition. Even a smaller test set of smoketests would be good as a filter for obviously broken stuff. One less thing to do when reviewing a patch... Another option for better CI is "django-next" branch in git. On commit patches are first pushed to django-next. CI tests django-next as it does master, 1.5 and 1.4. We could then merge django-next to master when things are looking good there (or revert if things are looking really bad). In addition to having one more safety net for master, the django-next branch could also work as testing ground for more experimental patches. I am not at all sure django-next is a good idea. I have zero experience about "-next" branches. All I know is that some very successful projects are using -next branches (Git and Linux for example). - Anssi -- 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 django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
