Git merge workflow: reverse it?

[Boudewijn Rempt]

On Wednesday, 26 August 2020 10:32:24 CEST Ingo Klöcker wrote:

> Boud, please don't look with your Krita glasses on other projects. 

Well, this goes two ways, and when people argue for a certain workflow as the KDE workflow, then I'll have to note that that workflow only is fine for repositories that don't see much work. It is not best practice; it's make-do.

It's the same with the retirement of createtarball in favor of releaseme: the releaseme workflow of creating a tarball from a branch and only then tagging is wrong for actively maintained projects. 

It's the same with keeping translations in svn instead of in the project repository.

While we can recognize they make life simpler for people tasked making regular releases of a whole bunch of repositories that change very little, we'll also have to recognize that these policies deviate from what is seen as best practice in the rest of the world.

> In my opinion, there can't be a one-size-fits-all git merge workflow/policy.

Sure -- but I feel that not everyone in this thread actually realizes that -- that there are people who think that all of KDE does one thing, and that it's the best way of doing things for all the variety in KDE.

My idea of a normal development and release workflow is:

* An MR either for master or stable
* A new MR for the other branch, or cherry-picking if simple enough
* When releasing setting a tag
* Which generates a tarball from the repo -- for which reason the repo should include the translations
* Copying the resulting tarball from invent to files.kde.org -- preferably with a KDE generated signature so I don't have to do that myself.
* Start the binary builds (although, ideally, that would also be done automatically on the setting of a tag...)

-- 
https://www.krita.org