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 _______________________________________________ Pkg-grass-devel mailing list [email protected] https://alioth-lists.debian.net/cgi-bin/mailman/listinfo/pkg-grass-devel
