Git merge workflow: reverse it?
Ingo Klöcker
kloecker at kde.org
Wed Aug 26 09:32:24 BST 2020
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>
More information about the kde-core-devel
mailing list