[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Git merge workflow: reverse it?
From:       Boudewijn Rempt <boud () valdyas ! org>
Date:       2020-08-26 9:21:49
Message-ID: 3870527.Lt9SDvczpP () boud-thinkpad-t470p
[Download RAW message or body]

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


[prev in list] [next in list] [prev in thread] [next in thread]