Hi David, Ideally you should work as follows: - Fork the qgis repo on github - in your fork create a feature branch (you can also work in _your_ master, but feature branche are much more clean) - keep _your_ branch up to date with QGIS master (this will save you a lot of headaches when merging) - when done make a pull request [1] on QGIS master (base fork: qgis/QGIS, base: master) with your own branch (head fork: dadler/QGIS, compare: your_feature_branch). if you don't see all four fields, click on compare across forks.
this pull request will get travis involved automatically hope it helps ciao Marco [1] https://github.com/qgis/QGIS/compare?expand=1 On 26.01.2016 23:43, David Adler wrote: > 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" >> <<mailto:[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" >> <<mailto:[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] >> <mailto:[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 <http://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 > -- Marco Bernasocchi OPENGIS.ch - berna.io - 27summits.ch _______________________________________________ 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
