2016-01-26 23:43 GMT+01:00 David Adler <[email protected]>:
> I'm afraid I'm relatively new to Git - I have mostly used SVN with GDAL > and GeoTools. > > I created a fork off github.com/qgis/qgis onto my github.com/dwadler/qgis > environment. > > The branch is set to master. > > When I clicked on New Pull Request, it said they were the same and didn't > do anything. Your note stated that this will kick off the automated test > suite. > > Should I be doing a git clone to my development system, creating a new > branch, putting the new/modified code in it, commit and push back to > github? Then do the pull? > Yes, exactly. 1. clone QGIS master into your own git repo 2. create a branch for example 'db2-provider' 3. checkout your branch 'db2-provider' 4. add your code to 'db2-provider' 5. commit and push to 'db2-provider' 6. make the pull request from 'db2-provider' to QGIS master > > I didn't think I could do a push to github - wouldn't this attempt to > update the QGIS master? It isn't clear how Travis gets in the loop. > Whenever you make a pull request from your branch to qgis master, Travis starts compiling and runs the test suite. > > For testing, wouldn't QGIS need a live connection to a DB2 database? > Yes, you can have a look to Tavis scripts, for example, here is how the postgres test DB is prepared: https://github.com/qgis/QGIS/blob/master/ci/travis/linux/before_script.sh Kind regards. -- Alessandro Pasotti w3: www.itopen.it 2016-01-26 23:43 GMT+01:00 David Adler <[email protected]>: > I'm afraid I'm relatively new to Git - I have mostly used SVN with GDAL > and GeoTools. > > I created a fork off github.com/qgis/qgis onto my github.com/dwadler/qgis > environment. > > The branch is set to master. > > When I clicked on New Pull Request, it said they were the same and didn't > do anything. Your note stated that this will kick off the automated test > suite. > > Should I be doing a git clone to my development system, creating a new > branch, putting the new/modified code in it, commit and push back to > github? Then do the pull? > > I didn't think I could do a push to github - wouldn't this attempt to > update the QGIS master? It isn't clear how Travis gets in the loop. > > For testing, wouldn't QGIS need a live connection to a DB2 database? > > Please excuse the novice questions. > > David > > > > On 1/25/2016 6:14 PM, Nyall Dawson wrote: > > Hi David, (and cc'ing back in qgis-dev) > > When you open a pull request against the main QGIS master repo, the > automated test suite ( <https://travis-ci.org/qgis/QGIS> > https://travis-ci.org/qgis/QGIS) will kick in and run a test build and > run all the existing unit tests to avoid regressions. It will also run some > "meta" tests, checking code quality and adherence to the code standards. > > So that's the first step - open your PR against QGIS master (not against > your fork), and see how this goes. Then you basically keep revising your > branch and pushing to github and for each new push Travis will retest until > you get a green light. > > The next step is adding new tests to cover your work. Without tests it > *will* break in some future QGIS release, so that's why testing is > mandatory for something like this. The provider test also runs a bunch of > complex cases against each provider to ensure that they correctly handle a > bunch of corner cases, so it will help ensure that your provider is well > behaved and stable. > > Here's some other provider tests which are good models to copy from: > > > https://github.com/qgis/QGIS/blob/master/tests/src/python/test_provider_shapefile.py > > > https://github.com/qgis/QGIS/blob/master/tests/src/python/test_provider_spatialite.py > > (Note that both also implement additional tests specific to that provider, > eg testRepack for shapefiles). The ms-sql provider test is a good example > of a minimal test, which only implements the things required for the > generic provider test (although you could also omit the > enableCompiler/disableComplier methods if you haven't implemented an > expression compiler for db2 yet). Then you'll also need to include relevant > test data - see > <https://github.com/qgis/QGIS/tree/master/tests/testdata/provider> > https://github.com/qgis/QGIS/tree/master/tests/testdata/provider for > what's expected in the test files, eg > <https://github.com/qgis/QGIS/blob/master/tests/testdata/provider/testdata_mssql.sql> > https://github.com/qgis/QGIS/blob/master/tests/testdata/provider/testdata_mssql.sql > . > > Hope that helps! > > Nyall > > > > On 26 Jan 2016 10:05, "David Adler" < <[email protected]> > [email protected]> wrote: > > > > I'm not clear on what the "automated CI" is or how one runs is. > > > > We did a fork and pull to our fork to do the development. > > > > I'm still a bit hazy on setting up and running the tests. Does a > database need to be operational in order to run the tests? > test_provider_mssql.py doesn't look like it does much. > > > > > > On 1/25/2016 4:24 PM, Nyall Dawson wrote: > >> > >> > >> On 26 Jan 2016 07:57, "David Adler" < <[email protected]> > [email protected]> wrote: > >> > > >> > We would like to add a DB2 provider to QGIS so that QGIS users can > access spatial tables on DB2 for LUW and DB2 for z/OS. > >> > > >> > We have implemented and tested much of this based on an existing > database provider. > >> > > >> > What is the mechanism to have this reviewed and approved? > >> > >> Open a pull request on github, and let the automated CI run its checks > over the code. > >> > >> Tips to get things reviewed/merged faster: > >> - Make sure all your API additions are correctly documented > >> - Include unit tests. At a minimum a new vector provider needs a test > which inherits from ProviderTestCase. See > tests/src/python/test_provider_mssql.py for an example. This ensures that > the provider behaves consistently with what QGIS expects from a vector data > provider. > >> > >> Nyall > >> > >> > > >> > > >> > > >> > --- > >> > This email has been checked for viruses by Avast antivirus software. > >> > https://www.avast.com/antivirus > >> > > >> > _______________________________________________ > >> > Qgis-developer mailing list > >> > [email protected] > >> > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > >> > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer > > > > > > This email has been sent from a virus-free computer protected by Avast. > > www.avast.com > > > > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > This > email has been sent from a virus-free computer protected by Avast. > www.avast.com > <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> > > _______________________________________________ > Qgis-developer mailing list > [email protected] > List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer > Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer > -- Alessandro Pasotti w3: www.itopen.it
_______________________________________________ Qgis-developer mailing list [email protected] List info: http://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: http://lists.osgeo.org/mailman/listinfo/qgis-developer
