The KDE Patchset Collection has been rebased on top of Qt 5.15.3

Sun Mar 6 19:16:31 GMT 2022

On Sun, Mar 6, 2022 at 2:10 PM Albert Astals Cid <aacid at kde.org> wrote:
>
> El diumenge, 6 de març de 2022, a les 19:32:57 (CET), Neal Gompa va escriure:
> > On Sun, Mar 6, 2022 at 12:56 PM Albert Astals Cid <aacid at kde.org> wrote:
> > >
> > > El diumenge, 6 de març de 2022, a les 17:36:26 (CET), Neal Gompa va escriure:
> > > > On Sun, Mar 6, 2022 at 11:00 AM Albert Astals Cid <aacid at kde.org> wrote:
> > > > >
> > > > > El diumenge, 6 de març de 2022, a les 16:12:37 (CET), Neal Gompa va escriure:
> > > > > > On Sun, Mar 6, 2022 at 9:52 AM Fabian Vogt <fabian at ritter-vogt.de> wrote:
> > > > > > >
> > > > > > > Moin,
> > > > > > >
> > > > > > > Am Freitag, 4. M�rz 2022, 01:35:14 CET schrieb Albert Astals Cid:
> > > > > > > > The KDE Patchset Collection has been rebased on top of Qt 5.15.3
> > > > > > > >
> > > > > > > > Some patches have been droped, some are still needed since we carry patches newer than 1 year old.
> > > > > > > >
> > > > > > > > Since this are rebases (to clearly show which patches are "ours", i.e. those on top of the v5.15.3-lts-lgpl tag)
> > > > > > > > the kde/5.15 branches have been force-pushed to, don't get scared when fetching tells you that a force-update happened.
> > > > > > >
> > > > > > > With the rebase, the connection between the 5.15.2 and 5.15.3 states has been
> > > > > > > lost, which broke all branches (and thus MRs) based on that, and the
> > > > > > > non-linearity of the history makes it hard to get an accurate list of changes
> > > > > > > (added, removed and changed commits). GC might eventually also break links to
> > > > > > > particular commits on the old branch.
> > > > > > >
> > > > > > > Would it be possible to just cherry-pick the patches from upstream's 5.15 which
> > > > > > > were missing from kde/5.15 instead? I imagine that wouldn't be too hard, and
> > > > > > > grant a better overview.
> > > > > > >
> > > > > > > If not, could you please publish a full list of changes caused by the rebase of
> > > > > > > affected repositories?
> > > > > > >
> > > > > >
> > > > > > It should have been done as kde/5.15.2 and kde/5.15.3 branches, but
> > > > > > here we are...
> > > > >
> > > > > Why?
> > > > >
> > > > > You don't get to act all "you're doing it all wrong" without giving an actual single reason.
> > > > >
> > > >
> > > > Because it's impossible for us to figure out the changes since you
> > > > rebased and mangled the history. If something needs to be debugged,
> > > > it's a lot harder to do.
> > >
> > > There are no changes in the patch set before and after the rebase (commit dc01793b3b194302a0174921cc30bfc15c985bf4 in [1]), the same patches remain on top (except the ones that are part of Qt 5.15.3 are not patches on top anymore, they are just part of Qt 5.15.3 thanks to the magic of git rebase detecting the patches that are no longer needed)
> > >
> > > > Also, the refusal to tag checkpoints has also made this difficult, but
> > > > it was manageable until this point.
> > >
> > > You're going to need to use terms i can understand, what's a checkpoint?
> > >
> > > > Especially when KDE developers say
> > > > that Fedora is broken because we don't have the KDE Qt patchset. It's
> > > > incredibly unhelpful and we can't figure out what we're working with.
> > >
> > > I still don't understand what is the problem, what do you mean "what we're working with" ? You just need to package the tip of the kde/5.15 branches, what else is there to "work with"?
> > >
> >
> > And that changes over time, and because there are no Git tags for
> > anyone to depend on
>
> So you want us to tag every single commit we make? How does that help you?
>
> Because every single commit is better than the one before [in theory, mistakes happen, but they will continue to happen whether we tag all the commits or not].
>
> Or are you saying something like "I don't like that you update the patchset almost daily. I would prefer that you only update it on alternating Wednesdays"?
>
> That seems a worse solution to me since we would have lots of patches landing at the same time, so if a regression were to happen it'd be harder to figure out which patch caused it.
>

No, what I'd like to see is a tag release to go along with a Plasma
release, so that I have some degree of confidence about what Qt
version+patches is expected to be used alongside KDE Plasma. That
doesn't mean tagging after every patch, but tagging after there's a
significant point that KDE developers would like to ensure downstreams
have it to simplify Plasma maintenance.

> But still, if you prefer to have lots of patches landing at the same time you can always do that "only update the patchset every X days" on your side, no?
>

We currently sync them monthly (more or less). It just gets weird when
it mismatches with what Plasma developers expect.

> > , it's *really* difficult to coordinate. We get
> > blamed regularly for having broken things in KDE Plasma because it
> > turns out we need some missing patch that's important for KDE Plasma
> > to work properly. But there's no way for us to know that until we go
> > back and find out.
>
> That seems like a communication problem from the KDE Plasma developers not saying which commit they expect you to carry, you should raise it with them.
>
> I guess that's also maybe partly-self inflicted pain on your side for defaulting to Plasma Wayland when it has been communicated (to my knowledge, please accept my apologies if that's not the case, I'm not really involved in day-to-day Plasma) that it's not yet 100% on par with Plasma X11 yet.
>

I'm aware it's not 100% on par, but I was heavily communicating with
the Plasma developers during the process of moving to Plasma Wayland
by default so that it would work well. However, I firmly believe that
Plasma Wayland wouldn't have gotten as good as it has without the work
between us and KDE developers over the past year and a half.

The reality is now, Plasma X11 is now more quirky than Plasma Wayland
and the Wayland experience is very good, even if there are some
feature gaps for Plasma on Wayland still.

> >
> > > > This whole situation has been pretty bad and I've been very unhappy
> > > > about it and said as much in other venues.
> > >
> > > You have been complaining in the wrong places to the wrong people, I'm one of the people most involved with the patchset and this is the first time i hear any complain from you.
> > >
> >
> > Not true. I complained in the thread on kde-devel[1] last June. In
> > particular I suggested a tag versioning convention[2].
>
> You suggested having a versioning convention for the package names, which is a problem that distributions have, we don't have any problem because we don't have packages.
>
> Yes, your convention seems reasonable to me, it's similar to what archlinux is doing, their packages are named 5.15.3+kde+rN where N is the number of packages on top, so for qtlocation is r0 and for qtwayland is r40.
>
> Cheers,
>   Albert
>
> >
> > This whole thing has been a terrible mess and it's extremely
> > frustrating. It's caused problems for the development of the last
> > couple of Fedora releases, too.
> >
> > [1]: https://mail.kde.org/pipermail/kde-devel/2021-June/000498.html
> > [2]: https://mail.kde.org/pipermail/kde-devel/2021-June/000508.html
> >
> >
> >
> > --
> > 真実はいつも一つ！/ Always, there's only one truth!
> >
>
>
>
>

-- 
真実はいつも一つ！/ Always, there's only one truth!