Loosening the commit limit for work branches

Milian Wolff mail at milianw.de
Wed Aug 24 19:58:47 BST 2022


On Mittwoch, 24. August 2022 18:57:12 CEST Noah Davis wrote:
> I didn't want to leave the master branch in a semi-broken state or
> present what I had come up with in an MR until I could present it as
> an improvement. It took a while to figure out what I wanted and
> whether some of what I wanted was even achievable. I haven't been
> working alone, so some people such as Marco and Nate are aware of the
> current state of the branch and have been testing it periodically. I'm
> aiming for a 22.12 release, so I intend to finish the patch over the
> next month (it's already getting close), leaving 2 or 3 months for
> additional testing after the merge.

I see, these are very valid reasons. Eventually though the situation should 
settle down, at which point some squashing is going to be required anyways to 
ensure that the commit history stays atomic. I.e. no single commit should 
yield a semi-broken state, as that would totally destroy `git bisect` and 
similar workflows. Anyhow, enough of this, as it's really not the point of 
this thread as you are writing below :)

> I don't want this discussion to turn into whether or not only my
> reasons for wanting a higher commit limit/no limit are right, but I
> recognize it is important to question my reasons since those are a
> factor in the discussion.

I totally agree with that. And just to make it clear again: I'm only trying to 
shine a light on how one could potentially handle such discussions 
differently. In the end it's you who does the work, and that counts infinitely 
more so don't let me deter you from your goals here! And as I said previously, 
I'm totally in favor of raising the commit limit, if possible.

Cheers

-- 
Milian Wolff
http://milianw.de




More information about the kde-devel mailing list