You can widen the scope of the existing issue. JIRA tickets have two purposes - to coordinate investigation and resolution of an issue and to communicate user-facing changes in release notes. We do not require one issue / one pull request / one commit and you should break these up into the units which feel natural.
Thanks for investigating pagination! I know how much work goes into fully supporting provider features, especially when maintaining backwards compatibility. On Wed, Apr 19, 2017 at 09:33:56PM +0100, John McDonnell wrote: > Hi, > > With the CloudStack provider, I have a defect I was about to start > work on JCLOUDS-1127, it's very similar to another defect I worked on > last week JCLOUDS-1128, whereby when requesting a list of CloudStack > Projects or Accounts, JClouds currently doesn't support > pagination(page or pagesize) in the parameters for the API calls. > > When I fixed 1128 last week I just added in the missing parameters and > that was that, but as I'm doing the same thing again, I'm starting to > ask myself the question of is there a better way? > > Currently only 12 of the ListXXXOptions classes in > org.jclouds.cloudstack.options[1] support pagination. If I look at > the CloudStack documentation against the remaining ListXXXOption > classes in this package I can see there are numerous other Option > classes missing pagination parameters, that could be enhanced with > pagination as the CloudStack APIs support this. > > So my long winded question is, (and apologies for the route taken), > should I raise another JIRA ticket for all of these, or is it > acceptable in this community to edit the existing JIRA ticket that's > still open(JCLOUDS-1127) - which I am the reporter on? > > [1]: > https://github.com/jclouds/jclouds/blob/master/apis/cloudstack/src/main/java/org/jclouds/cloudstack/options/ > > Regards > > John -- Andrew Gaul http://gaul.org/
