jrsilvey It would really help if I understood the process of being a package maintainer rather than simply the code used in packaging something.
I am not entirely sure I understand the question. So I will be more scattershot in my answer.
Starting out:
I agree with Staudey start updating out of date packages that have no dedicated maintainer.
I started with kid3 (now maintainer) on 20th February 2019 I use it multiple times a week. But wanted to keep using the package tooling regularly to keep it fresh. So I started working on everything I could. Patching gourmet to fix an issue, updating mgba, klavaro (now maintainer), dreamchess, uget, lynx etc.
Eventually I started updating opera-stable because it constantly is putting out new releases. (I don't even use opera outside of testing) Eventually I was asked to become its maintainer and now I am kinda stuck maintaining it... 82 updates later because I do not want leave users high and dry. Happy for someone to take it over so long as they use it.
Process of becoming a maintainer:
All new additions to the repository require a dedicated maintainer. If a package request has been accepted you do not need to ask permission, just do the work and submit it. But if someone has announced their intention to maintain the package give them a chance first.
An accepted package requests task is not kept open forever, they are usually closed after 30 days if no one has stepped up to become the maintainer. This does not mean it is no longer accepted for inclusion, unless otherwise stated in that task.
Do I have to update things straight away?
No, unless it is a security problem or major breakage. You are however expected to keep it reasonably up to date.
You might want to hold back an update due to the new release being too buggy, skip a release due to there being no relevant Linux changes or because it is an insignificant release, such as one that only fixes a typo (it happens). This is largely left to your discretion.
How do I keep track of new releases
I use all of these methods:
- github / gitlab can email you for new releases. This however is not reliable.
- RSS feeds from upstream blogs or sourceforge releases. This however is not reliable or rather some projects are not reliable and edit prior blog posts meaning you get no notification or they skip announcements all together.
- https://repology.org - This however is not reliable.
- https://gitpunch.com - This however never worked for me
- Manually checking.
jrsilvey I've built things from source before but it is always a hit or miss thing. If I am going to maintain packages do you think it's best to maintain a VM (or my other laptop?) and do the package maintenance from there? In case I screw something up?
You will need to build your packages against the unstable repository which means you're going to need to test them on systems that are using the unstable repo. If you are not willing to do that on your system then yes, use a VM.
Personally I run my main system and work laptop on unstable and have done so for 4+ years, its not a big deal. An packaging takes place inside a clean chroot environment. There has very rarely been any issues and most the time I've known in advance things were likely to break (Confirming issues exist).
If you are going to be running unstable you NEED to be in Solus's #solus-dev to check the topic to make sure it does not tell you DO NOT UPDATE or x upgrade in progress etc. Update when it tells you not to and you will have breakages.
