Distribution Developer Manual: how to operate Arch Linux
Merge request reports
Activity
assigned to @anthraxx
added 4 commits
-
fa3efdd4...3669e524 - 3 commits from branch
master - b7942ab1 - RFC to create a distribution handbook how to operate Arch Linux
-
fa3efdd4...3669e524 - 3 commits from branch
added 1 commit
- d7c6d2dc - add section with requirement of rational for merge request rejections
UPDATE: We've updated how we manage changes, while adapting the successful methodologies from the RFC's process to lower the risk of relying on too few people and to maximize visibility and transparency. Now, we classify changes as trivial, minor, or major, with a clear explanation of what counts as a major change needing an RFC. We've made this whole process easy to follow on ADP by including a note that sometimes, a minor change might be reclassified as major, requiring an RFC. Basically, we've realized that for this RFC, the main thing to figure out is how we categorize and define changes. This step is crucial for evaluating proposals on ADP (in a way similar to RFCs) to make decisions. This means creating a detailed list of categories is part of the ongoing work, not a starting requirement, as we match up proposals on ADP with these guidelines.
added 17 commits
-
284ff462...3372bfeb - 8 commits from branch
master - 2bef0367 - RFC to create a distribution handbook how to operate Arch Linux
- 404581f6 - add section with requirement of rational for merge request rejections
- 99f127a2 - fix: correct request for comments acronym
- f5cdce93 - fix: adjust wording around "isolate" as proposed in comments
- d40b5109 - fix: switch from a list of sources to a list of topics with examples
- 1cb04cbd - fixup: make clear we reference the Fedora style, not the content
- 0e0af323 - reworked the intention and specify how changes are handled
- 3ca8bd48 - rename handbook to developer manual
- 00b818ab - fix typo
Toggle commit list-
284ff462...3372bfeb - 8 commits from branch
added 17 commits
-
00b818ab...e105b8db - 8 commits from branch
master - be245461 - RFC to create a distribution handbook how to operate Arch Linux
- 7429a74d - add section with requirement of rational for merge request rejections
- 7ad414cf - fix: correct request for comments acronym
- d821b057 - fix: adjust wording around "isolate" as proposed in comments
- ebaa0e21 - fix: switch from a list of sources to a list of topics with examples
- 0cd1a22a - fixup: make clear we reference the Fedora style, not the content
- b8e97811 - reworked the intention and specify how changes are handled
- c4aed7b8 - rename handbook to developer manual
- 6217882f - fix typo
Toggle commit list-
00b818ab...e105b8db - 8 commits from branch
- Resolved by Levente Polyak
Hello everyone, that's my first writing in archlinux's GitLab.
I see what you are looking for, but I want to remind you what you perhaps neglected about Arch Wiki's blessings... - Last reply by Levente Polyak
mentioned in issue archlinux/packaging/packages/base-devel#3 (closed)
mentioned in merge request !5 (closed)
- Resolved by Levente Polyak
Since !21 (comment 166367) was in a resolved discussion thread so it was probably missed, I'll repeat it here.
The git based workflow provides a new power that's not very common in the wiki—inaction. Merge requests can be left to rot for months and years if a reviewer/expert/moderator has no interest in processing it.
I'd like to see this somehow addressed in the RFC.
- Last reply by Levente Polyak
added 24 commits
-
958a388a...4665c321 - 23 commits from branch
master - bf8471c9 - RFC to create a developer manual how to operate Arch Linux
-
958a388a...4665c321 - 23 commits from branch
added 1 commit
- e0ed8ca5 - RFC to create a developer manual how to operate Arch Linux
added 5 commits
-
e0ed8ca5...aa5c57c4 - 4 commits from branch
master - 926922dc - RFC to create a developer manual how to operate Arch Linux
-
e0ed8ca5...aa5c57c4 - 4 commits from branch
