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

[Albert Astals Cid]

El diumenge, 6 de març de 2022, a les 20:16:31 (CET), Neal Gompa va escriure:
> 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.

The KDE Patchset collection is not tied to Plasma, so we're not going to pollute its git history with Plasma related things. 

What you really want is Plasma developers to say "you need at least commit X from qt5.git", that would make sense, it's what we do with all our dependencies, establish a minimum version that works (sometimes a minimum version that kind-of-works and a really recommended higher version that really-works).

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

That makes sense, you're not shipping the expected library version, you get bugs. 

The problem is (and here I don't honestly know) if that that minimum expected version is properly communicated or not. 

Have you raised that concern with the Plasma release team?

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

Fair enough, the more testers the more bugs discovered and hopefully fixed :)

Cheers,
  Albert