Git merge workflow: reverse it?

[Ingo Klöcker]

On Mittwoch, 26. August 2020 09:59:16 CEST Boudewijn Rempt wrote:
> On Tuesday, 25 August 2020 23:44:02 CEST you wrote:
> > Or you can merge stable to master and be sure you won't forget anything.
> > Of course if master changed a lot you can't (easily) do that. But we
> > have a lot of repos that don't change very often and merging stable to
> > master works very well with them.
> 
> ...
> 
> > The problem is we don't always have a maintainer. A lot of apps are
> > community-maintained and if we wouldn't merge stable to master before a
> > new release we would reintroduce fixed bugs quite often.
> 
> Basically, what you're saying is that KDE releases a lot of software that
> just basically never changes, and apart from some translation work is
> actually unmaintained.

No. "Doesn't change very often" doesn't mean unmaintained. It could also mean 
feature-complete (at least from the point of view of the maintainer). The only 
significant work that still happens is bug fixing.

> I don't think that those projects, or rather repositories, since if there's
> no work being done, it's hard to see that as a project, should shape
> policy.

I agree to a certain point because unless the bug is really critical the 
maintainer could choose to fix the bug only in master.

> If a repo can get by with just merging stable to master, I don't think it's
> seeing meaningful development -- why should it even be released?

Because some bugs were fixed?

Boud, please don't look with your Krita glasses on other projects. A small 
application like Spectacle or something even smaller like the recently 
proposed markdownpart certainly has very different requirements on project 
management and software engineering than a large application like Krita. In 
particular, a small, more or less feature-complete application doesn't require 
large scale refactoring which would make merging stable to master a painful 
process.

I can see that for Krita merging stable to master isn't a viable workflow.

In my opinion, there can't be a one-size-fits-all git merge workflow/policy. 
Apparently, Krita does already deviate from the current "KDE-wide" "fix in 
stable and merge stable to master" policy that is challenged in this thread. 
In my opinion, the decision which policy (of maybe two sensible policies we 
can agree on) to use for a project should be left to the ones who are doing 
the work, i.e. for small, largely one-developer (== maintainer) projects it 
should be left to their maintainer. As for the release managers, they should 
simply take what's there. Merging stable to master shouldn't be part of their 
job, in my opinion.

Regards,
Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20200826/0fef7be9/attachment.sig>