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