With the switch to sudo-rs, v26.06 and edge installs do not have
doas by default. Along with this, we installed doas on old installs
with doas-sudo-shim, so the call to sudo also works there. Therefore,
recommending and calling sudo is the correct option here.
Signed-off-by: Aster Boese <asterboese@mailbox.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8873>
The lack of rationales for device categorization has lead to a lot of
discussions, misunderstandings, and frustrations, as of why the
requirements are the way they are. Even though it's always good to
keep improving and exploring ways to change our processes, having
rationales can help to explain the "why"s that do not really get
addressed by the "how"s of the actual requirements. Hopefully, this
will lead to less discussions and misunderstandings around the
specific requirements.
Closes https://gitlab.postmarketos.org/postmarketOS/postmarketos/-/work_items/146
Signed-off-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8595>
Don't describe how MRs to stable branches are done here, link to the
other page instead. Otherwise the approval rules should be the same as
for stable branches from now on.
Signed-off-by: Oliver Smith <ollieparanoid@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8812>
* Describe relevant changes, especially that we may make non-backport
changes if there is a patch release for a package that meanwhile has a
higher version in main already (e.g. a kernel in main is on linux
7.x.y while stable is on 6.18.z).
* Directly pushing to a stable branch should only be done during initial
branch bringup, otherwise we shall always make MRs that go through CI.
* Update formatting and title of the page.
Signed-off-by: Oliver Smith <ollieparanoid@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8812>
Adjust the timeline docs and release infrastructure template to have
numbers before the phases. This makes clearer where the next phase
begins in the long infrastructure issue template.
Signed-off-by: Oliver Smith <ollieparanoid@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8815>
It is quite massive, and therefore let's put the simpler things
first. If things keep growing, at some point it would make sense to
move it out to a subpage.
Signed-off-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8508>
"2021-11" is completely unnecessary at this point, and adding that the
kernel must be upgraded regularly is redundant with the requirement of
3 kernel releases and a lot less objective. So keep the objective
wording and remove the one very up for interpretation.
Signed-off-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8505>
It is extremely tedious to keep track of what the name of a particular
option was for every kernel release and when they were added. To keep
kconfigcheck maintainable, let's ease the burden on people adding new
options for community categories or other categories only required by
close-to-mainline kernel packages and only have them look back a
reasonable number of kernel versions.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8407>
Add firmware packaging guidelines to the documentation. The goal behind
this was to make it so that it is very clear which packaging method is
preferred for which cases to avoid fragmentation and inconsistency in
pmaports packaging.
Co-authored-by: Pablo Correa Gómez <pabloyoyoista@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8161>
In the case that the compilation is broken, it is not possible to wait
until a patch is merged upstream to fix it. We want to be able to patch
the kernels temporarily while also ensuring the fixes make it upstream.
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8072>
Start the documentation for generic device packages and document how to
handle device-specific services. This is a question that came up in the
review of PMCR-0009 (new main device category).
Signed-off-by: Oliver Smith <ollieparanoid@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/8122>
See the meeting notes from the 2026-01-19:
(https://docs.postmarketos.org/policies-and-processes/governance/team-meetings/meeting-notes.html)
> Discussed pmaports!7770, possibly limiting the wait period for maintainer
> approval from 2 weeks to 1 week.
>
> We discussed to keep 2 weeks and make an issue template for “had to merge
> without maintainer review”, the new process will then be that the template
> gets filled out if a MR has to be merged without maintainer review after
> two weeks. The maintainer can then either say that they plan to review
> future merge requests, or indicate that they don’t want to maintain the
> thing anymore, or just not respond (which implies that they don’t want
> to maintain anymore). That way we should be able to get the listed
> maintainers to reflect reality better.
>
> Everyone reading this, please make sure you are not listed as maintainer
> for packages that you don’t plan to do reviews for anymore :)
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7770>
