qt-advanced-docking-system: support Conan 2

[jcar87]

Based on #18794

Migrate qt-advanced-docking-system with Conan 2 support

Additionally tested on Linux:
linux-build.log

[valgur]

Please fix your CI system instead of opening a new PR.

[valgur]

Nice workaround!

[valgur]

These probably should have included a .replace("\\", "/") as well, though.

[jcar87]

Please fix your CI system instead of opening a new PR.

Not sure what you mean by anything being wrong with our CI here - if there's any issues please let us know and we can look into it.

@uilianries and I have spent quite some time reviewing the PR in order to get this through the finish line, based on your initial contribution which we are thankful for. The most recent revision of #18794 was built on CI and it failed on Windows, and it was also not building correctly on Linux, which is what we are addressing here - please be mindful that we are trying to help and these type of hostilities are counterproductive.

Please remember to abide by the code of conduct https://github.com/conan-io/conan-center-index?tab=coc-ov-file#readme

Try to be polite, CCI maintainers and contributors are really willing to help and we enjoy it.

[uilianries]

As the CI still does not support Qt6 + Linux (yet), I built locally based the commit cf56969. Here are the result for static and shared, all looking good. A few warnings from the compiler, but all built artifacts are present in the package folder.

qt-adv-4.3.1-linux-shared.log
qt-adv-4.3.1-linux-static.log

[valgur]

Well, it's hard to be productive in the first place with the blanket ban on CI time due to the arbitrary limit on the number of (existing, not new) open PRs.

[jcar87]

Well, it's hard to be productive in the first place with the blanket ban on CI time due to the arbitrary limit on the number of (existing, not new) open PRs.

We have two rather limited resources: our CI system and our time as reviewers. So we want to ensure that we give all contributors a fair chance at having their pull requests go through CI and through a team review.
We adopted a similar measure as the homebrew maintainers: Homebrew/actions#337 - with the very same motivation: avoid any contributor overwhelming our CI systems (which has happened in the past), and our availability as reviewers. What we ask of contributors with a large numbers of PRs is to help us prioritize - that is, leave the ones open that you think are more beneficial to you (and/or the community) - so that we can direct our attention and focus on them. Otherwise, there is absolutely no problem, but we will proceed as resources allow - we will (and have) run the PRs on CI once we get to them. We did consider placing a rule to automatically close any PR beyond a limit (and may do so in the future), but we felt that it's only fair to do so once we go through all pending PRs.

Either way - we are appreciative of your efforts and contributions to Conan Center, but there is no excuse for mistreating our reviewers.

[valgur]

What we ask of contributors with a large numbers of PRs is to help us prioritize - that is, leave the ones open that you think are more beneficial to you (and/or the community) - so that we can direct our attention and focus on them.

That sounds perfectly reasonable and acceptable in theory, but I can't recall a single instance where this has worked on CCI for PRs I have been involved in, regardless of the interest being from multiple users or not. I'm struggling to see much of real prioritization at all, except for low-hanging version bump PRs.

[jcar87]

What we ask of contributors with a large numbers of PRs is to help us prioritize - that is, leave the ones open that you think are more beneficial to you (and/or the community) - so that we can direct our attention and focus on them.

That sounds perfectly reasonable and acceptable in theory, but I can't recall a single instance where this has worked on CCI for PRs I have been involved in, regardless of the interest being from multiple users or not. I'm struggling to see much of real prioritization at all, except for low-hanging version bump PRs.

We have a high number of PRs and issues across all repositories. Recently we have been paying a lot more attention to issues reported in this repository and are currently undergoing a big effort of prioritising bugfixes and features, and moving the focus away from new versions being added unless there's more requests.

We understand we are not perfect, we have never been, and this is a work in progress - and we feel your pain and frustration, and do so from other users. However, we will not tolerate abuse under any circumstance

That sounds perfectly reasonable and acceptable in theory,

Help us get there - we want to get there. Antagonising the team at every turn is not going to help you, us, or the community that we want to serve.