@ketronixdev So just to be perfectly clear, as there seems to be some confusion, the process to submit a package update is as follows:
- Check that the package doesn't have a
MAINTAINERS.md
file on dev.getsol.us (if it has, the process becomes a bit more involved, as we have to first check with the maintainer, or find out if they are still active). In this case there is no MAINTAINERS.md
file, so we can ignore that for now.
- Check that no patch/diff to update the package has already been submitted to https://dev.getsol.us (in this case you're a-okay in this regard as well, as you're the first to submit one)
- Follow the "Building a Package", "Updating an Existing Package", and "Submitting the Package" guides to send a package update "diffusion" (i.e. basically a patch) to our dev tracker https://dev.getsol.us
- Wait for someone to take a look at the diff, and if they request changes follow their instructions
After this process has completed the update will finally be merged (usually, unless there are insurmountable problems), and the build server creates the package for the unstable repository, where it can be tested until the next sync to the stable repository, where all our users can access the updated package.
tomscharbach Perhaps you should consider offering to become part of the team as a global maintainer, working with the team rather than around it, making a multi-year commitment to Solus rather than just freelancing.
A note here: Usually the team will be looking at a history of contributions to Solus before an inclusion into the team is considered. I guess there could be exceptions of "OMG, we absolutely need to have this person on the team!", but usually we're looking at a process that starts by the person simply submitting patches of consistent quality to the dev tracker, or contributing in some other way to Solus, for an extended period of time, before a question like inclusion into the team even arises.