Bug#979188: RFS: git-subrepo/0.4.3-1 [ITP] -- Alternative to git-submodule(1) and git-subtree(1)
Hi Samo,
On Mon, Jan 04, 2021 at 11:16:04PM +0100, Samo Pogačnik wrote:
> Dne 04.01.2021 (pon) ob 22:11 +0100 je Daniel Gröber napisal(a):
> > I saw you submitted an RFS for git-subrepo a while back. I was wondering
> > what happened with that. It's not clear from what's in the BTS why it
> > didn't get uploaded, did you just not get a response from anyone?
> there was simply no response to my RFS and 'mentors' upload got automatically
> deleted about a month ago (after almost a year).
Ah, I see. I didn't know mentors.d.net garbage collects packages
automatically.
> I have no extra preferences for maintaining the package because i am very
> inexperienced regarding debian packaging. Otherwise i am willing to help...
It's up to you, if you don't feel up to it I'm happy to do it. It's just
always nice to have someone else that can jump in with package
updates. Bus-factor and all.
> Maybe i could not get more attention because of the 'native' type of my
> package which it self uses 'git subrepo' instead of the preferred 'quilt'
> approach (i really do not like managing series of patches, ...).
I would hope people would have simply complained about that if it was in
fact the problem. Seems to me there just aren't that many DDs actively
watching the mentors list or maybe people do reviews mostly off-list?
Had I seen the RFS I would have definitely complained about the weird repo
structure in the review ;)
I think people in Debian are trying to move to git-buildpackage (see also
DEP-14[1]) as the main way to manage packageing in git, and since it comes
with it's own way of importing upstream releases and such using git-subrepo
for the packaging is unlikely to go over well.
[1]: https://dep-team.pages.debian.net/deps/dep14/
I plan on using gbp-pq to manage patches as regular git commits. That seems
reasonably more comfortable than plain quilt, which I agree is a PITA.
> I even had the idea that git-subrepo is an excelent tool to enhance and
> maybe simplify debian packaging using git, but again i am too
> inexperienced to provide valid proposals covering all aspects of debian
> packaging.
Honestly I don't think it's worth swimming against the gbp stream at this
point. Personally I'd rather have one(ish) way of doing Debian packaging in
git so I can just jump into any package with debcheckout and be immediately
productive, instead of having to learn each maintainer's weird conventions
and tools fist.
One can always improve gbp if it doesn't optimally cover a particular
workflow yet.
> You are of course welcome to inspect my github project:
> https://github.com/spog/git-subrepo-debian
I had a look of course when I started packaging, but decided to start fresh
with gbp since I prefer forking the debian packaging from the upstream git
repo as it makes inspecting the history and git-bisect'ing across upstream
and debian revisions more streamlined.
--Daniel
Reply to: