The Solus Operating System has given me control over how I use my computer. That freedom is impossible to explain to anyone who hasn't taken back control of their digital existence.

This has made me very passionate about the Solus Project. I have looked into Solus' Open Collective fundraising process and I am really impressed by the effort both @JoshStrobl and @DataDrake have put into not just creating a stable, reliable, usable, EASY Operating System and Desktop Environment.. but the effort you've made in trying to make Solus a sustainable project through Open Collectives.

I don't have any money to invest in the Open Collective Project.. but..

I have the time and effort required to become a package maintainer.

My only issue is that I have no idea how to do that.

I have a degree in Computer Science but I've never worked in tech. I never put my degree to use. I learned C++ some but I am really not a coder.

I am extremely knowledgeable in how computers function and in using Linux. I am certain that I'll be able to do the work once I learn how.

The Packaging documentation lists the actual process of packaging and how to do it. That is something anyone interested in becoming a package maintainer would have to learn.

The purpose of this blog post is to make other people aware of ways to get involved through package maintenance as well as setting up a post for myself (and anyone else who might be interested in helping) to both ask questions and receive feedback and help future users learn how to do this as well.

It looks like it may take some time to go through the Packaging documentation and I might not get around to actually asking questions for a few days. It would really help if I understood the process of being a package maintainer rather than simply the code used in packaging something.

PS: I wasn't sure which tags should be used so I picked both "Tutorials" and "How do I.."

    I recommend starting with updating a couple of packages you use, before you become a full-fledged maintainer. Just to get the hang of the process.

    1. Find a program/library you use that doesn't already have a maintainer
      Look at the repository on the dev tracker (https://dev.getsol.us/). As an example: https://dev.getsol.us/source/element/
      See that MAINTAINERS.md file? That means someone else is already maintaining that package, which means that they should be the only one to submit updates (apart from rebuilds by the Core Team, and some other exceptions; see the contents of MAINTAINERS.md for details)
    2. Once you have found a package you want to update, follow the packaging documentation to set up the solbuild environment and prepare a patch/diff. I can also recommend the old video tutorial. At least in my case it was the last missing piece to really make me grok the whole process.
    3. Properly test your updated package!
    4. Submit your patch to the dev tracker (again, following the documentation/tutorial)
    5. Wait for feedback from the team, and then implement their suggestions/corrections
    6. Repeat

    It's also always a good idea to join the #Solus-Dev channel on IRC, and check out the topic, to see if big rebuilds or similar are going on. Not that you can't submit patches during rebuilds, but you might have to rebase them in the end, and it could be easier to simply wait a bit. Also it will probably take longer for someone to look at your patch if a lot of other stuff is going on. By the way, it might take quite some time before your patch gets reviewed; just be patient. (it also might only take a couple of minutes, you never know 🙂 )
    The #Solus-Dev channel is also the best place to ask questions about the whole packaging process.

    For packages that I usually update I'm subscribed to their Github release notifications, so I get an email when a new version gets released and can then soon after update the Solus package.

    Thanks @brent I have more on my plate than I realized so I will catch up on that thread in a day or two.

    And thank you @Staudey.

    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? As I mentioned above I will catch up on the media you shared with me in a day or two.

    I'll make sure to join the IRC channel. If I am not mistaken it can be joined through Element (Matrix), right?

    The #Solus-Dev channel is also the best place to ask questions about the whole packaging process.

    It makes sense and I understand why that is the best place to ask questions. I will join and talk there but I feel that a dedicated thread on this forum would benefit the project overall. I believe this forum has far more users and lurkers than the IRC channel and my intention is not just to learn myself, but to help others learn.

    The more people that can help contribute to the project means less work for @JoshStrobl and @DataDrake ..which means their efforts can be directed towards new features further along their roadmap. Right..?

      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.

            Like said already, the best is to start updating existing packages. This allows you to make sure your packaging environment is well configured and to smoothly learn the package submission process.
            One of the common "mistake" with newcomers is that they want to package a very complex or outdated application (which may rely on deprecated libraries or on stuffs that are not in the repository and that should be packaged first). Another mistake is that some people justpackage something without checking if there is a package request already (or waiting their package request is approved).

            Do not hestitate to check and compare your package with other packages. Examples are often better than long explanations.

            jrsilvey It makes sense and I understand why that is the best place to ask questions. I will join and talk there but I feel that a dedicated thread on this forum would benefit the project overall. I believe this forum has far more users and lurkers than the IRC channel and my intention is not just to learn myself, but to help others learn.

            Keep in mind that this community forum is meant to talk and share with the community. Of course you can share your pacakging experience here but when you have a technical question related to a package, IRC is the place to go. Also when you work on unstable, the topic of the #solus-dev channel is something that should systematically be checked to avoid running into problems. Just open your favorite IRC client on that channel and let it run in background.

              Harvey I'd be interested in trying to take over maintaining Opera. Don't want to hijack the thread, could you reach out off site through Twitter or email? I'd like to discuss it a bit more to make sure it's something I can handle.

                  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?

                  Like @Harvey I also use the Unstable repository for my main system, and do the packaging work there. I also have a clean Solus VM to test packages, especially when it's an initial inclusion, so I can catch missing rundeps and other issues that don't show up on my main system.

                  jrsilvey I'll make sure to join the IRC channel. If I am not mistaken it can be joined through Element (Matrix), right?

                  Yes, but I haven't tried it myself.

                  jrsilvey It makes sense and I understand why that is the best place to ask questions. I will join and talk there but I feel that a dedicated thread on this forum would benefit the project overall.

                  Oh definitely. I just meant that for issues/questions that arise when you start packaging/updating software, you should probably ask in #Solus-Dev; didn't mean to suggest that this thread isn't useful. Pretty much what @kyrios said.