Loosening the commit limit for work branches

[Milian Wolff]

On Mittwoch, 24. August 2022 15:30:06 CEST Noah Davis wrote:
> A week ago, I ran into an unexpected issue while working on a QML port
> of Spectacle. There is an undocumented pre-receive hook that sets a
> 100 commit limit for all branches of official repos, including work
> branches. The error message it gave me told me to file a sysadmin
> ticket, so I did that.

<snip>

> What does the broader KDE development community think? Should there be
> a commit limit and how large should it be? Only KDE devs can make work
> branches, so the pool of people who can make branches with large
> amounts of commits is already fairly limited.

I have also run into this but got done at around ~90ish patches and was 
notified by Nicolas in time about this limitation.

Generally, such arbitrary limitations are always a bad sign imo and we should 
ideally try to remove or increase the limit. Lots of small patches are far 
easier to work with than few mega patches.

That said, from my personal knowledge it's usually a bad sign to start mega 
rewrites or refactors in a branch - sooner or later you should hit a small 
mile stone that you can merge already. If you don't do that and pile up tons 
of patches in your work branch, you might get into rebase or merge conflict 
hell when the main branch continues to see development. I've been there and 
just started over, wasting quite a bit of time. Since then, I'm trying to look 
for small work packages that can be hoisted out of the larger work branches 
and merged early. This then allows to reduce the size of the work branch, 
without having to use large squashed mega patches.

Without any knowledge of your work on the QML port of Spectacle, I would also 
claim that there is bound to be a lot of generic work that should be possible 
to land directly in the main branch, no? You are probably splitting up the 
data representation and UI layer, which can happen early. Then you add a 
second UI implementation in tandem to the widget one, which can be opt-in 
until it's ready. Once all is done, you can remove the old widget UI. There's 
no need to wait a long time for all of this to hit the main branch and work 
only in a feature branch, no?

Cheers
-- 
Milian Wolff
mail at milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20220824/dcee011c/attachment.sig>