Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
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? Thanks, Fabian > Cheers, > Albert
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
On Sunday, 6 March 2022 15:26:21 PST Neal Gompa wrote: > 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. You don't need a tag, you need a branch. The state that you need to have a well-functioning KDE Plasma build is all the patches that exist at the moment you ask that question. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel DPG Cloud Engineering
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
El dilluns, 7 de març de 2022, a les 0:26:21 (CET), Neal Gompa va escriure: > Realistically, KDE wouldn't have the patchset collection if it weren't for > Plasma. Not true. Albert
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
On Sun, Mar 6, 2022 at 5:01 PM Albert Astals Cid 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 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 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 > > > > > > 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 > > > > > > > > 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, t
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
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 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 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 > > > > > 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 > > > > > > > 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 check
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
On Sun, Mar 6, 2022 at 2:14 PM Albert Astals Cid wrote: > > El diumenge, 6 de març de 2022, a les 20:10:38 (CET), Albert Astals Cid va > escriure: > > where N is the number of packages on top, so for qtlocation is r0 and for > > qtwayland is r40. > > packages on top -> patches on top > > I re-read that email like 10 times and still had a huge mistake like this, > sorry :/ > > No worries, I figured out what you meant. :) -- 真実はいつも一つ！/ Always, there's only one truth!
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
On Sun, Mar 6, 2022 at 2:10 PM Albert Astals Cid 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 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 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 > > > > > > 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
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
El diumenge, 6 de març de 2022, a les 20:10:38 (CET), Albert Astals Cid va escriure: > where N is the number of packages on top, so for qtlocation is r0 and for > qtwayland is r40. packages on top -> patches on top I re-read that email like 10 times and still had a huge mistake like this, sorry :/
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
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 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 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 > > > > > 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
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
On Sunday, 6 March 2022 19:32:57 CET, Neal Gompa wrote: 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. Can we scale back the language please? I get that you're not happy, but calling the work of volunteers a terrible mess most likely won't motivate them any further and it isn't respectful at all. Furthermore, wearing my packager hat, I really disagree. I'm quite happy that I don't have to hunt Qt patches myself. Regards, Heiko
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
On Sun, Mar 6, 2022 at 12:56 PM Albert Astals Cid 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 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 > > > > 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, 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. > > 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]. 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!
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
On Mon, Mar 7, 2022 at 4:13 AM Neal Gompa wrote: > On Sun, Mar 6, 2022 at 9:52 AM Fabian Vogt 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... > If you clone the repositories then run the following command you will pull down to your local system a backup copy of the branch made by our hooks at the exact moment before it was force pushed. git fetch origin +refs/backups/*:refs/backups/* The ref refs/backups/branch-kde/5.15-1646350085 (in the case of qtbase) can then be used to do any analysis you were looking to do. (the number at the end will differ from repository to repository, but each one is guaranteed to exist) Cheers, Ben > > > -- > 真実はいつも一つ！/ Always, there's only one truth! >
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
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 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 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"? > 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. Albert [1] https://invent.kde.org/qt/qt/qt5/-/tree/kde/5.15
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
On Sun, Mar 6, 2022 at 11:00 AM Albert Astals Cid 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 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. Also, the refusal to tag checkpoints has also made this difficult, but it was manageable until this point. 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. This whole situation has been pretty bad and I've been very unhappy about it and said as much in other venues. -- 真実はいつも一つ！/ Always, there's only one truth!
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
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 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. Albert > > >
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
El diumenge, 6 de març de 2022, a les 15:51:55 (CET), Fabian Vogt va escriure: > 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? I sincerely don't understand what you want. Best Regards, Albert > > Thanks, > Fabian > > > Cheers, > > Albert > > >
Re: The KDE Patchset Collection has been rebased on top of Qt 5.15.3
On Sun, Mar 6, 2022 at 9:52 AM Fabian Vogt 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... -- 真実はいつも一つ！/ Always, there's only one truth!
The KDE Patchset Collection has been rebased on top of Qt 5.15.3
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. Cheers, Albert
