[Git][debian-gis-team/libapache2-mod-tile][master] 4 commits: fixed another spelling error (upstream pr #175)

[Sebastiaan Couwenberg]

On 8/25/20 7:13 PM, Felix Delattre wrote:
> On 8/25/20 4:47 PM, Sebastiaan Couwenberg wrote:
>> On 8/25/20 6:16 PM, Felix Delattre wrote:
>>> This is modifying a bit the patches you wrote, so I would like to ask you to give it a quick look if the approach is ok, before I push it to the repo.
>>>
>>> https://salsa.debian.org/xamanu/libapache2-mod-tile/-/commit/3b40acaaa145f944b0597938bd39521f532b102c
>>
>> That's not the repo where the team maintained packaging lives.
> 
> Yes, it is a staging step before, to make sure I'm not overriding anybody's value work without asking.

Changes can be reverted easily.

> Or would you have prefered I submitted this one?

Pushing patch queue branch is pretty harmless.

>> I'm not a fan of the noise that git adds to its patches, and hence
>> prefer plain quilt with the configuration documented in the team policy:
>>
>>  https://debian-gis-team.pages.debian.net/policy/policy.html#quilt
>>
>> There are a few packages in the team that use gbp-pq, but not all
>> contributors use it, so patches tend to get refreshed with quilt.
>>
>> Instead of using a different tool to refresh the patches, time is better
>> spent on forwarding patches upstream where appropriate and marking the
>> patches accordingly.
> 
> For me gpb-pg makes it much easier to contribute and track upstream, as this is also handled through git and I'm definitively involved to making everything (that makes sense) from our patches to be offered and hopefully accepted by upstream.
> 
> I really would prefer to handle it with gpb-pq for this package. And I also respect, of course, if you tell me, that I should not.
> 
> Are you ok, if I follow the some maintainers way, instead the strictly documented one on this here?

You're the primary caretaker of the package based on the Uploaders, so
it's up to you.

The quilt workflow has the benefit that it also works with plain source
packages not managed with git-buildpackage. You should be comfortable
with the quilt workflow in addition to gbp-pg if you need to work on
more packages in the archive like (reverse) dependencies not maintained
within the team.

The same goes for dch vs gbp-dch, the former works for more use cases
than the latter, hence the preference for plain dch. It also makes it
much easier to choose which changes need to be included in d/changelog
and which ones to have in VCS history only.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1