Hi Matthias, Thankyou for your quick response! No rush on the sponsorship, I am more interested in doing things right, rather than doing them fast.
I have already implemented a few of your notes (changelog and package granularity). I will take the time to look through the debhelper 14 release notes properly some time over the coming days. I do have a question regarding native vs. quilt. I intend this project to be exclusively Debian and will not be supporting any cross-platform activities. It’s a conscious choice. With that in mind, when I read the Docs, native sounded like the correct format. Is there any benefit to using quilt in the case where the package is intended to be exclusively Debian? I am happy to switch, but it feels like switching to quilt with a separate repository for my project/package would add some complexity without benefit. Could you maybe give me some insight here please? Kind Regards, Luke -----Ursprüngliche Nachricht----- Von: Matthias Geiger <[email protected]> Gesendet: Mittwoch, 15. Juli 2026 16:42 An: Luke Ian Turner <[email protected]>; [email protected] Betreff: Re: RFS: nmbs/1.0.0~1 [ITP] -- confidentiality label binding tools On Wed, 15 Jul 2026 08:58, Luke Ian Turner <[email protected]> wrote: > >Good Morning, > >Before submitting an RFS to the BTS, I am reaching out to the GNOME team in >search of a Sponsor for my package. The primary GUI is a Nautilus Extension. >Any further Desktop functionality will also be targeted at the GNOME Desktop >Environment. > >The tools add normalised support for "confidentiality labels". A few >screenshots at the top of the GitHub Repo show quickly what the tool >does (note the Classification column etc.) >https://github.com/liturner/nmbs > >Below is my drafted RFS (not yet submitted). If I do not receive a response >within a week or so I will go the BTS route. > >Thank you for your consideration in any case and have a great day! > >Kind Regards, >Luke > Hi Luke, thanks for you work. After a very quick glance at this package, wouldn't it make sense to split the nautilus extension into its own package? cf. nautilus-nextcloud. A few more notes: - d/changelog: Should only contain "Initial release (Closes: #XXXXX)" for the first release. - d/control: you can already switch to debhelper 14, see man debhelper-compat-upgrade-checklist - The debian packaging itself should life separately from the main git repo IMO, i.e. on Debian salsa gitlab. - The source format should be 3.0 quilt, as this is not a Debian-specific package - you should add a upstream/metadata file - Likewise for a watch file - Documentation should got into a separate -doc package I haven't had time to look more in-depth on this though. This could be just maintained as-is, though IMO could be moved to the GNOME Extras team, too. Note that I won't have time to sponsor anything until end of this month. best, werdahias
