This patch adds the description of how one should
use labels to control the flow of merge requests.
This patch also contains information how should
one prepare commits before merging with master.
Details
- Reviewers
rempt - Group Reviewers
Krita: Manual - Commits
- R1012:0860955a8415: Add gitlab workflow to untranslatable pages
R1012:ded67f24118a: Add gitlab workflow to untranslatable pages
Diff Detail
- Repository
- R1012 Krita.org Documentation Website
- Branch
- tiar/gitlab-page (branched from draft)
- Lint
No Linters Available - Unit
No Unit Test Coverage - Build Status
Buildable 11138 Build 11156: arc lint + arc unit
Hi @tymond Can I request you to run the image through pngquant and optipng, it would reduce it to 23 KB.
untranslatable_pages/intro_hacking_krita.rst | ||
---|---|---|
266 | This can be - code yourself to master, if you have developer access, or ... | |
269 | Can - "Read and test extensively all MRs you approve or merge!" be "Read and test extensively all MRs before you approve or merge!" | |
289 | Will this sound good if it is "If you need to only fix previous commits," |
Added more information about force-push.
Changed the look of labels.
Added note to watch out what MR is one trying to make.
Hi, @tymond!
The text looks very nice, detailed and precise! :) I don't see any problems in it. If we find any problems/inconsistencies, we can always adjust it on the fly :)
untranslatable_pages/intro_hacking_krita.rst | ||
---|---|---|
212 | IMO it should be acceptable to force-push to a branch on the main repo if:
Otherwise, if we are to disallow force-pushing on the main repo even for personal branches, we should change the text in the above section to just ask everyone to create merge requests from their personal fork and not push any WIP on the main repo. We should also make sure it is disallowed in GitLab by making all branches "protected" by default. |
@kamathraghavendra and @rempt: Be sure to push this :)
It can go into the master branch, as the untranslatable pages shouldn't be a bother to translators.
To push it, either use arcanist:
arc patch D20759 arc land
or use git --author
git apply <path/to/>D20759.diff make html #just in case for errors git add . git commit --author="Agata Cacko <tamtamy.tymona@gmail.com>"
Then write a commit message or copy paste the summary here.
And ensure the commit message ends with
Differential Revision: https://phabricator.kde.org/D20759
There are some other things that I'm still working on, so please don't push until I say that's all....
Okay, if you're still working on it, be sure to include your copyright into the header, I think :)
untranslatable_pages/intro_hacking_krita.rst | ||
---|---|---|
212 | All branches are protected, so there is no option to force-push to main repo. |
untranslatable_pages/intro_hacking_krita.rst | ||
---|---|---|
159 | s/access https/https access/ | |
163 | s/ssh/https/ | |
164 | I suggest to strongly recommend using a personal forked repo over pushing to the official repo for creating merge requests. | |
181 | I want to suggest adding --ff-only but assuming the reader won't be committing to their master branch then it shouldn't be needed? | |
186 | IMO just write "stage all changes". |
some suggestios
untranslatable_pages/intro_hacking_krita.rst | ||
---|---|---|
150 | Can this be - "This page is still work in progress and might get updated later" Also till when do we need this flag? | |
157–158 | Set up new remote which points to the official repository and then you will be able to update your master branch. this is just a suggestion, | |
159 | for access through https | |
159 | Once you are done, login to the KDE gitlab instance and got to ... | |
160 | Write a detailed description about the changes that you are proposing with your merge request. If it is a change in the user interface it would be good if you can provide screenshots through attachments. | |
162–239 | Does notified sound good instead of informed, since it will trigger a notification via mail? "and will try to review your" can be "and they will try to review your.." | |
190 | We can also suggest the delete current fork and refork strategy, if gitlab gives a button in the merge request page to delete the fork once the merge request is accepted, like github does? | |
196 | is it base or basic? | |
223 | fit the Krita git history -> fit in the Krita's git histoy | |
225 | there are two spaces between should and state. can this be - | |
227 | follow the KDE commit guidelines |