[Geoserver-devel] Enhancement: WFS Simple Feature Response in new more compact JSON/JSONP format

Hello there,

now the 2nd optimization of the new SpatialJSON format (Shared String Table) is merged into main. Many thanks for that :slight_smile:

I have prepared two more single-commit PRs for porting back everything to 2.22.x and 2.21.x. Before pushing these into my forked repo and issuing the PRs, I'd like to ask how to do this correctly concerning Jira tickets and, what Andrea mentioned recently, GeoServer's "Jira ticket first" approach.

Since Jira tickets are required for adding stuff to the change log, I guess having two tickets for these PRs is a good idea. After creating the Jira ticket, I know its ticket number (e. g. GEOS-12345). How do I link the the ticket with the PR? Is it just naming the PR [GEOS-12345] ... whatever? Is it crucial to name the commit behind the PR accordingly? What's technically required and what is best practice?

As recommended by Andrea I've issued a Jira ticket (GEOS-10708) for the first PR of the new community module. However, it's still unassigned and open. Will this ever be used for the change log? Get tickets "linked" to a PR closed automatically?

Sorry for asking all that but, it's a quite complex system and new to me (I'm doing this for the first time). I want to do it the right way now and as well for future contributions, but still feel kind of lost... :-p

Cheers
Carsten

--

Carsten Klein
Lead Software Engineer

DataGis GmbH

Johann-StrauĂź-Str. 26
70794 Filderstadt
GERMANY

Phone: +49 7158 9490 106
Fax: +49 7158 9490 111

E-Mail: c.klein@anonymised.com
Internet: www.datagis.com

Commercial Register: Stuttgart, HRB 225945
Management: Dr. Gunter Hahn, Markus Ruess, Carsten Klein

Klien:

You should be able to add the label: backport-2.22.x, and backport-2.21.x to your PR and a bot will prep two new pull requests for you.

When those are merged the original Jira ticket has the “fixed for” information update to indicate additional releases where the problem is fixed (2.22.0 and 2.21.4 or something).

The procedure; such as it is; is to ask on your original pull request for the fix to be backported. If it is a fix it can be backported immediately; if it is a new feature we try and wait a month (for stability), or ask on the email list for an “early backport”.

–
Jody Garnett

On Thu, 3 Nov 2022 at 00:16, Carsten Klein <c.klein@anonymised.com> wrote:

Hello there,

now the 2nd optimization of the new SpatialJSON format (Shared String
Table) is merged into main. Many thanks for that :slight_smile:

I have prepared two more single-commit PRs for porting back everything
to 2.22.x and 2.21.x. Before pushing these into my forked repo and
issuing the PRs, I’d like to ask how to do this correctly concerning
Jira tickets and, what Andrea mentioned recently, GeoServer’s “Jira
ticket first” approach.

Since Jira tickets are required for adding stuff to the change log, I
guess having two tickets for these PRs is a good idea. After creating
the Jira ticket, I know its ticket number (e. g. GEOS-12345). How do I
link the the ticket with the PR? Is it just naming the PR [GEOS-12345]
… whatever? Is it crucial to name the commit behind the PR
accordingly? What’s technically required and what is best practice?

As recommended by Andrea I’ve issued a Jira ticket (GEOS-10708) for the
first PR of the new community module. However, it’s still unassigned and
open. Will this ever be used for the change log? Get tickets “linked” to
a PR closed automatically?

Sorry for asking all that but, it’s a quite complex system and new to me
(I’m doing this for the first time). I want to do it the right way now
and as well for future contributions, but still feel kind of lost… :-p

Cheers
Carsten

–

Carsten Klein
Lead Software Engineer

DataGis GmbH

Johann-StrauĂź-Str. 26
70794 Filderstadt
GERMANY

Phone: +49 7158 9490 106
Fax: +49 7158 9490 111

E-Mail: c.klein@anonymised.com7776…
Internet: www.datagis.com

Commercial Register: Stuttgart, HRB 225945
Management: Dr. Gunter Hahn, Markus Ruess, Carsten Klein


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Comments inline:

Hello there,

now the 2nd optimization of the new SpatialJSON format (Shared String
Table) is merged into main. Many thanks for that :slight_smile:

Must be this one https://github.com/geoserver/geoserver/pull/6320

I have prepared two more single-commit PRs for porting back everything
to 2.22.x and 2.21.x. Before pushing these into my forked repo and
issuing the PRs, I’d like to ask how to do this correctly concerning
Jira tickets and, what Andrea mentioned recently, GeoServer’s “Jira
ticket first” approach.

Since Jira tickets are required for adding stuff to the change log, I
guess having two tickets for these PRs is a good idea. After creating
the Jira ticket, I know its ticket number (e. g. GEOS-12345). How do I
link the the ticket with the PR? Is it just naming the PR [GEOS-12345]
… whatever? Is it crucial to name the commit behind the PR
accordingly? What’s technically required and what is best practice?

As recommended by Andrea I’ve issued a Jira ticket (GEOS-10708) for the
first PR of the new community module. However, it’s still unassigned and
open. Will this ever be used for the change log? Get tickets “linked” to
a PR closed automatically?

Cleaning up:

  1. Changed your PR title to: [GEOS-10708] SpatialJSON Shared String Table Feature

  2. If the title has the pattern [GEOS-xxxx] when created a bot provides a link to the jira ticket, I added this by hand editing PR description

  3. Added a link to the PR in the Jira ticket; using add web link

  4. I added the backport labels for the backport bot to see, … and it failed to backport as the community modules is not backported yet.

Sorry for asking all that but, it’s a quite complex system and new to me
(I’m doing this for the first time). I want to do it the right way now
and as well for future contributions, but still feel kind of lost… :-p

Thanks for asking for help; it got a little complicated to clean up .,

···

On Thu, 3 Nov 2022 at 00:16, Carsten Klein <c.klein@anonymised.com> wrote: