Loosening the commit limit for work branches

[Noah Davis]

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 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.

On Wed, Aug 24, 2022 at 6:42 PM Milian Wolff <mail at milianw.de> wrote:
>
> On Mittwoch, 24. August 2022 17:26:33 CEST Noah Davis wrote:
> > On Wed, Aug 24, 2022 at 5:12 PM Milian Wolff <mail at milianw.de> wrote:
> > > 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?
> >
> > The UI is already fairly well separated from the backend simply
> > because Spectacle already has a CLI. I simply went through a lot of
> > iterations over the past few months in collaboration with Marco while
> > trying to come up with the right UI/UX. The branch contains a lot of
> > new UI related code that uses Qt Quick/QML. It would be useful for me
> > to keep track of these changes so that if anything breaks in the
> > process, I can more easily figure out which change did it and ask
> > questions if I wasn't the one who made the change.
>
> Right, as I said I only worked on assumptions in my statement above.
>
> What prevents you though from merging the partial state of the Qt Quick/QML UI
> into the main branch? If you say the code history as it is now is useful, it
> should be useful in the future too - and as such could be merged more
> regularly? You don't have to enable the new UI for now in the main branch?
>
> --
> Milian Wolff
> mail at milianw.de
> http://milianw.de