On Sun, Mar 6, 2022 at 5:01 PM Albert Astals Cid <aa...@kde.org> wrote: > > 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 <aa...@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 <aa...@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 <aa...@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 > > > > > > > > <fab...@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). >
Realistically, KDE wouldn't have the patchset collection if it weren't for Plasma. Pretending otherwise does a disservice to everyone. In any case, I just want a git tag that Plasma developers indicate that we should *at least* have for a well-functioning KDE Plasma build. For example, I'd expect a 5.15.3.kde.1 tag with the new rebase, and then Plasma developers say "use at least 5.15.3.kde.1 for a good KDE Plasma experience". Maybe there will be 5.15.3.kde.2 and then 5.15.3.kde.3, etc. and when KDE Plasma 5.25 rolls around, they'll say "use 5.15.3.kde.N for a good experience" where "N" is the patch release number that they expect things to work well. > > > > > 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 :) > For what it's worth, the bugs we see fixed by patches in the KDE Qt 5.15 patch collection are pretty balanced across the modules these days. It's not just QtWayland. :) -- 真実はいつも一つ！/ Always, there's only one truth!
