<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>Yes, this was very informative, thank you! The rest of my question are Debian specific. I joined their new maintainers list, so I will dig further. </div><div><br></div><div>On Wed, Jul 14, 2021, at 10:23, Eric Garver wrote:<br></div><blockquote type="cite" id="qt" style=""><div>On Tue, Jul 13, 2021 at 08:31:53PM -0400, Damien Calloway wrote:<br></div><div>> Hello !<br></div><div>> <br></div><div>> <br></div><div>> I am seriously considering adopting an orphaned Debian package called Qtile.<br></div><div>> (Yeah, I know, some people adopt children, some people adopt pets.....)<br></div><div>> <br></div><div>> Have any of you maintained any packages for a distro before ? What is the<br></div><div>> time commitment and workflow for that ?<br></div><div><br></div><div>Disclaimer: I'm the firewalld maintainer. So I'm fortunate enough to<br></div><div>influence "upstream" and the package in RHEL/Fedora.<br></div><div><br></div><div>I maintain a few packages in RHEL and Fedora. Mostly firewalld.<br></div><div><br></div><div>Time commitment depends heavily on the package. If the package is very<br></div><div>active and popular it can be fairly time consuming. You may backport<br></div><div>fixes weekly. If it's not very active, then you may only rebase the<br></div><div>package a couple times a year.<br></div><div><br></div><div>Workflow depends on the distribution. Even though RHEL and Fedora are<br></div><div>RPM based the workflow is very different. I have never packaged anything<br></div><div>for Debian. I have done a few packages for pkgsrc and that's very, very<br></div><div>different than deb/rpm.<br></div><div><br></div><div>For RPM (Fedora) it's basically:<br></div><div><br></div><div> 1. clone the package repository<br></div><div> 2. update the RPM spec file (e.g. add patches)<br></div><div> 3. build/test locally<br></div><div> 4. push the package update to the repository<br></div><div> 5. submit the new build to "testing". It will propagate to "stable"<br></div><div> once enough users have +1'd it.<br></div><div><br></div><div>You can also submit package updates via pull requests. That way the<br></div><div>current/active maintainer can review/approve them. This may be a good<br></div><div>way to get your feet wet and see if you like it.<br></div><div><br></div><div>Additionally, you're basically a liaison between the distribution's<br></div><div>users and the upstream project. Distro users will report bugs and you'll<br></div><div>have to find the upstream bug fix or propagate the bug report to<br></div><div>upstream. This includes a first level of triage.<br></div><div><br></div><div>> As I see it, once the current version of the app is packaged, I only have to<br></div><div>> watch for updates to the app and any messages about people who cannot build<br></div><div>> it on their machines. Is that correct ?<br></div><div><br></div><div>Bug fix updates are usually easy/trivial. Feature releases are more<br></div><div>work. You may hit build issues, test failures, dependency changes, etc.<br></div><div>The bigger the package the more common these scenarios are.<br></div><div><br></div><div>Distribution users don't typically build the package on their machine.<br></div><div>They just install the binary deb/rpm.<br></div><div><br></div><div>Hope that helps.<br></div><div>Eric.<br></div><div>_______________________________________________<br></div><div>colug-432 mailing list<br></div><div><a href="mailto:colug-432@colug.net">colug-432@colug.net</a><br></div><div><a href="http://lists.colug.net/mailman/listinfo/colug-432">http://lists.colug.net/mailman/listinfo/colug-432</a><br></div><div><br></div></blockquote></body></html>