Add gitlab workflow to Untranslatable Pages

Authored by tymond on Apr 22 2019, 11:29 PM.



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.

Diff Detail

R1012 Documentation Website
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
tymond created this revision.Apr 22 2019, 11:29 PM
Restricted Application added a project: Krita: Manual. · View Herald TranscriptApr 22 2019, 11:29 PM
Restricted Application added a reviewer: Krita: Manual. · View Herald Transcript
tymond requested review of this revision.Apr 22 2019, 11:29 PM

Hi @tymond Can I request you to run the image through pngquant and optipng, it would reduce it to 23 KB.

Many thanks in advance for fixing these minor typos.


Typo: a developer -> developer
Typo: in official -> in the official


Typo: procees -> proceed


Typo: in Approved -> in the Approved


Typo: exists -> exist


This can be - code yourself to master, if you have developer access, or ...


Can - "Read and test extensively all MRs you approve or merge!" be "Read and test extensively all MRs before you approve or merge!"


Will this sound good if it is "If you need to only fix previous commits,"

rempt added a subscriber: rempt.Apr 23 2019, 6:37 AM
rempt added inline comments.

Add 'will' before 'be informed'

s/make contact/contact/


s/contact krita developers/contact a krita developer/g

tymond updated this revision to Diff 56791.Apr 23 2019, 6:50 AM

Fixed typos (thanks for pointing them out!).
Optimized png image.

tymond updated this revision to Diff 56792.Apr 23 2019, 6:53 AM
tymond marked 8 inline comments as done.

Fixed one more typo.

tymond marked an inline comment as done.Apr 23 2019, 6:56 AM
tymond updated this revision to Diff 56797.Apr 23 2019, 7:45 AM

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 :)

rempt accepted this revision.Apr 23 2019, 10:13 AM
This revision is now accepted and ready to land.Apr 23 2019, 10:13 AM
alvinhochun added inline comments.

IMO it should be acceptable to force-push to a branch on the main repo if:

  1. it's a personal branch (i.e. branch name starts with person_name/); and
  2. only one person (i.e. you) are working on it.

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 <>"

Then write a commit message or copy paste the summary here.
And ensure the commit message ends with
Differential Revision:

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 :)

tymond added inline comments.Apr 23 2019, 12:27 PM

All branches are protected, so there is no option to force-push to main repo.

tymond updated this revision to Diff 56816.Apr 23 2019, 12:43 PM

Added git commands.

tymond marked 2 inline comments as done.Apr 23 2019, 12:45 PM
alvinhochun added inline comments.Apr 23 2019, 1:08 PM

s/access https/https access/




IMO just write "stage all changes".


I suggest to strongly recommend using a personal forked repo over pushing to the official repo for creating merge requests.


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?

some suggestios


Can this be - "This page is still work in progress and might get updated later"

Also till when do we need this flag?


for access through https


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,


Once you are done, login to the KDE gitlab instance and got to ...


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.


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.."


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?


is it base or basic?


fit the Krita git history -> fit in the Krita's git histoy


there are two spaces between should and state.

can this be -
Commit messages should clearly and concisely state what changes you made with that particular commit and why


follow the KDE commit guidelines

tymond marked 16 inline comments as done.Apr 23 2019, 2:23 PM
tymond added inline comments.

I removed it... not sure if the current version is the last one, but it looks pretty final now.


I changed it to:

#. Set up a new remote which points to the official repository, so you'll be able to update your master branch.

tymond marked 4 inline comments as done.Apr 23 2019, 2:24 PM
tymond updated this revision to Diff 56827.Apr 23 2019, 2:40 PM

Fixed issues mentioned in comments above.

This revision was automatically updated to reflect the committed changes.