<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">I'm afraid I'm relatively new to Git -
I have mostly used SVN with GDAL and GeoTools.<br>
<br>
I created a fork off github.com/qgis/qgis onto my
github.com/dwadler/qgis environment. <br>
<br>
The branch is set to master.<br>
<br>
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.<br>
<br>
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?<br>
<br>
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.<br>
<br>
For testing, wouldn't QGIS need a live connection to a DB2
database?<br>
<br>
Please excuse the novice questions.<br>
<br>
David<br>
<br>
<br>
On 1/25/2016 6:14 PM, Nyall Dawson wrote:<br>
</div>
<blockquote
cite="mid:CAB28Ash6sfUm9KKsGuK0b-eEoKhS2od4azFwcb6VD-T60o0KeA@mail.gmail.com"
type="cite">
<div dir="ltr">
<p dir="ltr">Hi David, (and cc'ing back in qgis-dev)</p>
<p dir="ltr">When you open a pull request against the main QGIS
master repo, the automated test suite (<a
moz-do-not-send="true"
href="https://travis-ci.org/qgis/QGIS"><a class="moz-txt-link-freetext" href="https://travis-ci.org/qgis/QGIS">https://travis-ci.org/qgis/QGIS</a></a>)
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.</p>
<p>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.</p>
<p>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.</p>
<p>Here's some other provider tests which are good models to
copy from:</p>
<p><a moz-do-not-send="true"
href="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_shapefile.py</a><br>
</p>
<p><a moz-do-not-send="true"
href="https://github.com/qgis/QGIS/blob/master/tests/src/python/test_provider_spatialite.py">https://github.com/qgis/QGIS/blob/master/tests/src/python/test_provider_spatialite.py</a><br>
</p>
<p>(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 <a
moz-do-not-send="true"
href="https://github.com/qgis/QGIS/tree/master/tests/testdata/provider"><a class="moz-txt-link-freetext" href="https://github.com/qgis/QGIS/tree/master/tests/testdata/provider">https://github.com/qgis/QGIS/tree/master/tests/testdata/provider</a></a>
for what's expected in the test files, eg <a
moz-do-not-send="true"
href="https://github.com/qgis/QGIS/blob/master/tests/testdata/provider/testdata_mssql.sql"><a class="moz-txt-link-freetext" href="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</a></a>.</p>
<p>Hope that helps!</p>
<p>Nyall</p>
<p><br>
</p>
<p dir="ltr"><br>
</p>
<p dir="ltr">On 26 Jan 2016 10:05, "David Adler" <<a
moz-do-not-send="true"
href="mailto:dadler@adtechgeospatial.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:dadler@adtechgeospatial.com">dadler@adtechgeospatial.com</a></a>>
wrote:<br>
><br>
> I'm not clear on what the "automated CI" is or how one
runs is.<br>
><br>
> We did a fork and pull to our fork to do the development.<br>
><br>
> 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.<br>
><br>
><br>
> On 1/25/2016 4:24 PM, Nyall Dawson wrote:<br>
>><br>
>><br>
>> On 26 Jan 2016 07:57, "David Adler" <<a
moz-do-not-send="true"
href="mailto:dadler@adtechgeospatial.com" target="_blank"><a class="moz-txt-link-abbreviated" href="mailto:dadler@adtechgeospatial.com">dadler@adtechgeospatial.com</a></a>>
wrote:<br>
>> ><br>
>> > 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.<br>
>> ><br>
>> > We have implemented and tested much of this
based on an existing database provider.<br>
>> ><br>
>> > What is the mechanism to have this reviewed and
approved?<br>
>><br>
>> Open a pull request on github, and let the automated
CI run its checks over the code.<br>
>><br>
>> Tips to get things reviewed/merged faster:<br>
>> - Make sure all your API additions are correctly
documented<br>
>> - 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.<br>
>><br>
>> Nyall<br>
>><br>
>> ><br>
>> ><br>
>> ><br>
>> > ---<br>
>> > This email has been checked for viruses by Avast
antivirus software.<br>
>> > <a moz-do-not-send="true"
href="https://www.avast.com/antivirus" target="_blank">https://www.avast.com/antivirus</a><br>
>> ><br>
>> > _______________________________________________<br>
>> > Qgis-developer mailing list<br>
>> > <a moz-do-not-send="true"
href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
>> > List info: <a moz-do-not-send="true"
href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
>> > Unsubscribe: <a moz-do-not-send="true"
href="http://lists.osgeo.org/mailman/listinfo/qgis-developer"
target="_blank">http://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
><br>
><br>
> This email has been sent from a virus-free computer
protected by Avast. <br>
> <a moz-do-not-send="true" href="http://www.avast.com"
target="_blank">www.avast.com</a></p>
</div>
</blockquote>
<br>
<table style="border-top: 1px solid #aaabb6; margin-top: 30px;">
<tr>
<td style="width: 105px; padding-top: 15px;">
<a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank"><img src="https://ipmcdn.avast.com/images/logo-avast-v1.png" style="width: 90px; height:33px;"/></a>
</td>
<td style="width: 470px; padding-top: 20px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">This email has been sent from a virus-free computer protected by Avast. <br /><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank" style="color: #4453ea;">www.avast.com</a>
</td>
</tr>
</table>
</body>
</html>