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>
Currently, even if dint fails for some reason, the documentation
generation continues on. This is not good as it hides problems until
someone manually discovers them. Fix this by checking the exit code of
dint and raising an exception if it isn't zero.
To facilitate this, also replace call() with run() since it's a more
modern and more flexible API.
Signed-off-by: Stefan Hansson <newbyte@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7982>
Keeping it in the docs under a new section to reduce the risk of
confusion about its disappearance. It's also still relevant if you
target older branches where it hasn't been removed.
Signed-off-by: Stefan Hansson <newbyte@postmarketos.org>
Part-of: <https://gitlab.postmarketos.org/postmarketOS/pmaports/-/merge_requests/7822>
