The kde-sig group collectively maintains a large stack of Qt and KDE related packages in fedora. In particular, the group holds a standard best-practice of having commit access to all low-level Qt library packages. This was true until relatively recently when the situation changed with qt5-qtwebengine.
Kevin Kofler is the sole owner and package admin for qt5-qtwebengine, and he revoked kde-sig commit rights over disagreements with a kde-sig member (heliocastro, who happens to not actively contribute anymore as a result of this negative interaction).
The kde-sig has repeatedly requested 2 things:
commit rights for kde-sig group be restored
another package admin be granted (we feel a single admin as a single point of failure is unwise in general)
At a recent kde-sig meeting, we laid an ultimatum that at least the commit rights be given to follow our standard practice, or we'd have no choice but to escalate this to fesco to intervene on our behalf. Nothing happened, so here we are.
Our specific request to fesco:
a kde-sig member be granted primary ownership over the qt5-qtwebengine package
Kevin Kofler be removed as owner (assuming if ownership remained, he'd simply go back and remove rights, and we'd be right back here again soon)
In the least, if there are better alternatives to be found, the kde-sig as a group would be satisfied with any solution provided commit rights for kde-sig group were included.
I came to become the primary point of contact of the qt5-qtwebengine package because the review request had stalled. The submitter, Helio Castro, despite being active on IRC, repeatedly did not respond to pings about that review process, and also did not accept help. (There were open issues preventing the package from getting approved as is.) I ended up having to invoke the stalled review process, and he did not bother doing anything to stop the process, despite being responsive in other places (other bug reports in Bugzilla, IRC, mail, etc.). Neither a basic "you can take this over, please proceed" nor a basic "I am still alive, please leave this package to me", I really had to wait for the timeout of the stalled review process. Nor did any other KDE SIG person intervene in the process during this time frame, I was the only developer willing to complete the work. So that is why it is now my package.
qt5-qtwebengine
I had initially agreed to let the KDE SIG commit to this package because it had to always be upgraded in lockstep with the other Qt 5 packages. As of https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/a9c34c53912fc962113cf921c9aae65383570372?branch=master, this is no longer the case, it is now possible to upgrade this package on its own schedule, independently of the other Qt 5 packages. Therefore, the KDE SIG no longer needs commit access to this package. It is necessary to rebuild it when Qt is upgraded, but a simple rebuild (with no other stray changes) can be done by any provenpackager (including Rex Dieter) under the provenpackager policies and hence does not require commit access.
I have also realized that the changes done by KDE SIG people were few and far between, and only of 2 types:
In particular, when the time came to upgrade QtWebEngine to 5.8, Helio Castro had, in his Copr, imported the whole source code into git and reexported the patches from there. I told him that I was not able to merge his work into master for that reason: the issue is that this rebases all patches, even those that do not need any changes, and that the git diff algorithm is sufficiently different from plain diff so that it is not possible to diff the diffs to see what really changed. I told him how I work (rebasing patches with patch and diff -Nur) and that QtWebEngine patches should always be done that way. But when QtWebEngine 5.9 came out, Helio Castro, who was not willing to wait for me to have time to take care of it (this was before the official 5.9.0 release, mind you!), did the rebase, this time directly in dist-git master, using the same method that I already told him was not acceptable. As in soccer, two yellow cards make a red card. It is sad that instead of reacting constructively to the criticism, Helio Castro decided to leave the entire KDE SIG over it. This is his personal decision and I have no control over it.
patch
diff -Nur
There was also a change by Rex Dieter that I did not explicitly approve (and given the fallout, I do not want him to (ab)use his provenpackager privileges to make this kind of changes without my approval in the future) that caused a regression: https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/b72c3e9db869383f0d2c3c7a0375e13490e012c2?branch=master – He added macros that are not really needed, as a simple pkg-config query can be and was already used for that purpose: https://src.fedoraproject.org/rpms/qupzilla/blob/master/f/qupzilla.spec#_39 and those macros had a typo that was redefining _qt5 and breaking other Qt packages, see: https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/0d029998f5fe5294e490a1957191e584525fe459 . I am opposed to defining unnecessary RPM macros that can only break things.
pkg-config
_qt5
QtWebEngine is already a package that requires a lot of work to maintain, more than all my other packages together. I cannot afford to additionally spend time reverting other people's incorrect changes that make my work harder, so if I am not allowed to maintain this package alone, I will have to orphan it. Let me also point out that there is no Fedora policy requiring me to accept any specific comaintainer. I also strongly believe that if I get removed from this package or forced to orphan it, the quality of this package in Fedora will suffer a lot, because I have been the only one willing and/or able to really work on it so far. As I wrote, this is a very time-consuming package. Hence the decision to maintain this package alone is a technical decision in the interest of the quality of the package and of Fedora as a whole. This is nothing personal against Rex Dieter or the KDE SIG, but just a necessity to make my work on this package manageable.
I had also offered, as a compromise, to allow individual commit ACLs, as needed and on request, to people I can trust, but since the KDE SIG is insisting on a blanket group ACL, that offer is hereby rescinded.
[EDIT: Typo fix: s/I have the only one/I have been the only one/]
To be clear, kde-sig is not asking Kevin_Kofler be removed from commit access here (responding to comment "if I get removed from this package or forced to orphan it")
To be clear, with "forced to orphan it", I was referring to my previous statement:
I cannot afford to additionally spend time reverting other people's incorrect changes that make my work harder, so if I am not allowed to maintain this package alone, I will have to orphan it.
My time to spend on Fedora is limited, I want to use it productively and not to fix breakage caused by changes I did not approve.
Also note that Pagure allows anybody to fork the repository and submit pull requests. So it is not required to have commit access to contribute to the package. If the pull requests really make the package better, I will merge them. But I need to be able to say "no" if they make it worse.
See also this commit that was pushed without my approval (abusing provenpackager access, in violation of https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages#Who_is_allowed_to_modify_which_packages – a version upgrade is not "quite minor"): https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/8d10a950e255b60e8e274c674e147cefdab955c5?branch=master
.gitignore
git-cola
qt57
Therefore, if you really cannot wait for me to do a version upgrade (I will have time for the package this weekend), please submit a pull request so that I can make you fix these things before they are commited and do not have to clean them up after the fact.
Thank you for pointing out exactly why I do not want any comaintainers for this package.
To clarify, I want to see changelog entries like these: https://src.fedoraproject.org/rpms/qt5-qtwebengine/blob/8d10a950e255b60e8e274c674e147cefdab955c5/f/qt5-qtwebengine.spec#_607 if patches are modified, rebased or dropped. With the amount of patches in this package, it is vital to track what changed when.
These: https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/712fc44244e6775ea1feddf306b5885d66f4623e?branch=master https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/b729fd5578a16098fcc3c3081e3b15c4746d87c7?branch=master address the main issues I pointed out in my review of the commit. This is extra work I would rather not have had to do, at a time where I have more important things to do.
I will look into system re2 during the weekend. (I wanted to take care of the 5.9.2 upgrade as a whole then. Nobody asked me whether it was OK to jump the gun.)
Let me also point out that QtWebEngine is not a "low-level Qt library package". It is a package containing a fork of large parts of Chromium (which is an application, not a library), depends on 8 other Qt modules: https://src.fedoraproject.org/rpms/qt5-qtwebengine/blob/b729fd5578a16098fcc3c3081e3b15c4746d87c7/f/qt5-qtwebengine.spec#_126 , and is only required by the kdepim stack and 11 other applications (bibletime, calamares-webview, fcitx-libpinyin, gpsbabel-gui, kalgebra, konqueror-libs, ktp-text-ui, luminance-hdr, mediaconch-gui, otter-browser, qupzilla). And as I already pointed out, it supports building against older and newer Qt versions, and can thus be upgraded separately from the rest of Qt, which in fact I had to do because Qt 5.8 was never pushed to F25 and F26 and Qt 5.9 was not pushed to F25 and F26 in a timely manner. (QtWebEngine must be kept up to date due to security fixes, so I cannot wait forever for Qt getting upgraded.) So IMHO, QtWebEngine can and should be treated like an application-level library, not like a "low-level Qt library package".
perhaps I used the wrong terminology, but my use of "low-level" means that it is low in the stack, and that a lot of things depend on it (definitely not a leaf package).
Well, as I explained above, the package is not that "low in the stack" (i.e., in the dependency graph). It has more dependencies than reverse dependencies.
It is my understanding of the policies that I can be forced to accept a comaintainer if and only if I am not taking care of the package with due diligence, but I do not see how that is the case here. (Surely it cannot be expected from an unpaid volunteer to be available 24/7 to upgrade the package on some arbitrary schedule! I am doing what I can to keep QtWebEngine up to date, and it has been kept more up to date than Qt in our releases.) It is also my understanding that there is no policy that would force me to accept blanket commit ACLs for an entire group.
Metadata Update from @ausil: - Issue tagged with: meeting
FWIW, I support @kkofler in this wholeheartedly. I may not have agreed with him many times in the past, but he makes valid points in this case and I wouldn't like to see the package being given over to someone else just because the KDE SIG cannot be bothered to send patches for review to the primary maintainer before committing them. QtWebEngine, being Chromium-based, is a delicate package to maintain and I fully understand Kevin's reservations about giving unfettered access to people not experienced in maintaining it. Just ask @spot about the chromium package.
+1
FESCo Meeting 2017-10-13
#agreed Proposal: We add KDE SIG as a comaintainer. In general, it will require 2 KDE SIG members to approve a Pull Request. In the event that Kevin still refuses, an additional 2 may overrule him. (+1:8, -1:0, +0:0)
Metadata Update from @maxamillion: - Issue untagged with: meeting
This makes no sense whatsoever. How are you going to enforce the pull request rule if you give the KDE SIG commit access? I refuse to maintain the package under these conditions.
From the meeting log (I was unfortunately unable to attend the meeting):
<rdieter> There are several packaging improvements that have been reverted already, simply because Kevin dislikes them personally
Huh? Where have I reverted a packaging improvement?
<jforbes> rdieter: That's all well and good on principal, but the reality is nouveau is fighting an uphill battle with walls being thrown up all of the time. Waiting for a nouveau fix in the driver and not applying a bandaid is ill advised
There already exists a working patch, I have patched Mesa builds in my QtWebEngine Copr, the Nouveau maintainer refuses to apply it. Why don't you force him to apply the patch?
And the issue that I have with the workaround is that it disables OpenGL on Nouveau, hurting performance and also disabling functionality such as WebGL, and that it will keep doing so even if Nouveau/Mesa gets fixed, or if the user uses the (already existing) working Mesa build from my Copr.
<sgallagh> tyll: But he's refusing to ack ones that fix actual problems; that's a failure in the process
I haven't done that, ever. The Nouveau change wasn't actually submitted, and I'm still undecided on whether we should apply something like that. What's true is that I'd rather you force the Nouveau maintainer to apply the patch to his driver, but that does not mean I'd reject a workaround if it were actually submitted.
17:17:23 <rdieter> sgallagh: I would strongly prefer he remain as a package maintainer here, he's done very good work with it. It's just that there's no collaboration
Because the "collaboration" is not helpful and only makes my work harder, as I have already explained to great length in this issue.
So, in short, I strongly urge you to reconsider this unfair decision in your next meeting. If you insist on enforcing it, I will have no other choice but to orphan the package, as I made clear from the beginning.
For the record, these are the Mesa patches, I have been constantly rebasing them (well, the main one, because the 2 followups still apply as is) to new Mesa releases: http://copr-dist-git.fedorainfracloud.org/cgit/kkofler/qtwebengine/mesa.git/tree/0001-WIP-nouveau-add-locking.patch?id=c81234957e754d0759d3b0870e7e7d00001d1929 http://copr-dist-git.fedorainfracloud.org/cgit/kkofler/qtwebengine/mesa.git/tree/0003-nouveau-more-locking-make-sure-that-fence-work-is-al.patch?id=c81234957e754d0759d3b0870e7e7d00001d1929 http://copr-dist-git.fedorainfracloud.org/cgit/kkofler/qtwebengine/mesa.git/tree/0004-nv30-locking-fixes.patch?id=c81234957e754d0759d3b0870e7e7d00001d1929
So, as you can see, I am actually trying to solve the problem, I am not the maintainer who is not cooperative here.
Let me also point out that I care a lot about this package because I actually use it daily as part of my everyday browser (QupZilla), which is actually not the case of most of the KDE SIG (who were still mostly using Firefox last I checked).
Ok, everyone needs to step back a bit. I'm a member of the KDE-SIG and it's disappointing to read such squabbling. Just from reading the text, Rex you make generalised accusations and Kevin rebuts each of those with facts and documentation.
Kevin, you're a very valuable contributor - and you really should return to kde-sig, but that's another topic. I especially appreciate the work you've done with qt5-qtwebengine and qupzilla / soon to be Falkon. I also know you're a very passionate contributor - and while that passion makes you very good at what you do, it also get's you into trouble at times... you could use a bit of help with your people skills.
Rex, you are normally very level headed and polite. You do excellent work also - and correct me if I'm wrong but you're the KDE lead. Which among your other duties means you get to manage personalities.
Rex, Kevin I know you guys are like oil and water; but could we just chill down a bit from DEFCON 5? Kevin, it's in the best interest of the group to allow co-maintainers, if for nothing else contingency planning. Rex it's also good idea to give great deference to the principle maintainer. If Kevin believes something is a really bad idea, you should listen to him and not think - "I want to do it, and if Kevin doesn't bow to my will, I'm going to FESCo." That's not trying to collaborate, that's being confrontational.
By the same token Kevin, if Rex says we really need something and you disagree, you should have all your ducks in a row to explain to him why - and have a reason which the risk of doing it outweighs the benefit... and Rex, you need to listen.
Are we not adults?
FESCo - I know you're not babysitters - and you definitely have more important things to worry about... but I would hope you would insist both parties have real documentation to back up their claims before taking any kind of punitive action. These guys don't need FESCo, they need a mediator - and I don't believe the solution you proposed is going to fix this issue. It's not so much about technical issues than it is about personalities.
This accusation:
17:16:47 <lupinix> jforbes: when a provenpackager makes commits where kevin thinks they are wrong, kevin just reverts them, so we need a clear ownership here 17:17:00 <lupinix> rdieter just made that experience some days agi afair
is also completely baseless. The only part of rdieter's commit that I reverted was the change to .gitignore, which breaks my workflow and which is clearly controversial and against provenpackager policies. I did not revert any of rdieter's changes to the specfile. (I did add a few changelog lines documenting what he changed in the patches, but I did not undo anything he changed.)
Dear FESCo, I urge you to not only reconsider your decision, which was based on incorrect accusations of wrongdoing (please note that there is no policy justifying such a decision in the absence of any wrongdoing), but also to pronounce sanctions against the authors of such libel.
I'm also a KDE SIG member, one of those who voted for bringing up that discussion here. I know the personal things between people have been grown over years now, these were not my ambition as this is really not the place for that (but cannot be ignored completely, as the current situation with qt5-qtwebengine is also a result of this).
My ambition here is that we need a proper collaboration with respect to maintainance, qt5-qtwebengine is used by more and more KDE packages, including many applications like Kontact which are part of our default installation. So qt5-qtwebengine is not a leaf package anymore. The KDE SIG is also maintaining the rest of Qt, so we have to be able to handle rebuilds, possible fixes and so on and not all of our members are provenpackagers.
I think the current FESCo proposal is a good step, as we have more controversial topics than just rebuilds. The workaround for nouveau is such a case. I totaly agree with Kevin that this has to be fixed in mesa, but as qt5-qtwebengine is used by more and more KDE applications I'd add the workaround which disables OpenGL on nouveau. We had controversial discussions there in the past (but months ago when less applications used qt5-qtwebengine, I don't know his current position though). In such cases we want to be able to make changes ensuring a high quality KDE experience. Also in my opinion one does not own a package but is only the main contact for it, packages are owned by Fedora community.
@kkofler In that concrete case I'm indeed referencing that .gitignore story because it was just some days ago and ended up in a discussion. What makes me angry is not that commit or the change in changelog, but the way of discussion (#fedora-kde,Tuesday 10 October 2017, timezone UTC+2) :
[18:28:05] <Kevin_Kofler> The commit to .gitignore (removing older tarballs) is unacceptable, that part will be reverted. [18:28:17] <Kevin_Kofler> These make my tarballs show up as "new files" in my git-cola and break my workflow. [18:28:22] <Kevin_Kofler> .gitignore is append-only. [18:29:08] <Kevin_Kofler> And why did you remove the qt57 patch, was that fixed upstream? [18:29:56] <Kevin_Kofler> Also, system re2 is now supported out of the box, so the parts that unbundle re2 manually can be removed. [18:30:13] <Kevin_Kofler> (This upstream change is why you had to unfuzz the linux-pri patch.) [18:30:43] <Kevin_Kofler> This is something I would have done as part of upgrading the package if you had not decided to jump the gun without my approval. [18:32:32] <Kevin_Kofler> And next time, I want to make these comments in a pull request, BEFORE the commit is merged, rather than having to fix up your mistakes after the fact. [18:33:08] --> Fryy (~quassel@dslb-178-007-200-171.178.007.pools.vodafone-ip.de) has joined #fedora-kde [18:37:40] <-- HorusHorrendus1 (~horrendus@62.218.23.190) has quit (Ping timeout: 258 seconds) [18:38:46] --> HorusHorrendus (~horrendus@62.218.23.190) has joined #fedora-kde [18:40:22] <rdieter> Kevin_Kofler: qt57 was upstreamed [18:40:48] <rdieter> don't know why you insist on keeping old/obsolete/unused stuff in .gitignore, <shrug> [18:40:55] <Kevin_Kofler> Re qt57, OK. [18:40:56] -- lupinix starts to get angry when he reads such comments… words like "mistakes"… at least that gitignore thing is not a mistake but a matter of taste… [18:41:39] -- lupinix hates gitignores keeping old files, branch should be always clean and contain only required stuff, including only required stuff in such listings [18:41:51] <rdieter> part of working in a team is making compromises [18:42:13] <rdieter> lupinix: that's why I do it too [18:42:24] <Kevin_Kofler> If you look at my changelog entries, you will always see things like "rebase foo and bar patches" or "drop baz and bla patches, fixed upstream", so that people reading the commit diffs KNOW why the patch disappeared. [18:42:46] <Kevin_Kofler> Making compromises means NOT to change this sort of personal preferences in OTHER people's packages. [18:42:50] <rdieter> for me, dropping patches means exactly that... they're not needed any more [18:42:54] <Kevin_Kofler> This is MY package. [18:43:09] <rdieter> that's the fundamental disagreement , indeed [18:43:17] <Kevin_Kofler> Thank you for pointing out exactly why I do not want any comaintainers for this package. [18:43:36] <rdieter> makes it clearer to me why we can't just leave things as-is, too [18:43:36] <lupinix> that story again… i consider packages as packages of fedora community, i'm just the main contact in case of "my" packages… [18:43:37] <Kevin_Kofler> Your commit is also a violation of the provenpackager policies, I pointed that out in the FESCo ticket. [18:44:17] <Kevin_Kofler> If you keep doing that, I will have to request your provenpackager privileges being revoked. [18:44:19] <rdieter> I consider this package as part of the group, you do not [18:44:39] <Kevin_Kofler> https://fedoraproject.org/wiki/Who_is_allowed_to_modify_which_packages#Who_is_allowed_to_modify_which_packages is crystal clear
There were also other reverts, but these were not by a provenpackager but heliocastro when he had commit acces via kdesig, mixed that up… But sentences like "This is MY package." or "Thank you for pointing out exactly why I do not want any comaintainers for this package." are my main issue. That's the whole point for me.
@kkofler By the way, accusing me to libel without knowing what I'm referencing??? Seriously? Maybe I should have done that before but I did not want to post whole IRC logs in the meeting as this is a mixture of personal issues and discussion etc. See IRC log in post above.
@lupinix Thanks for those two posts, at least in my mind that reinforces my opinion of this whole situation. I must have spent my entire career in the 7 levels of hell because these conversations are nothing compared to what I've been through. This is all about personal issues and everybody needs to take a step back. As far as @kkofler wanting things in the package his way, I can understand that, because he is the main contributor and steward. I also don't have an issue with the verbiage "my package". Who cares? Have we been reduced to parsing each others sentences? People need to stop taking things so personally... that is part of the problem. That said: @kkofler - what's up with blowing your lid and lecturing people about mistakes. You were in a kde meeting, not the spanish inquisition. If you want people to respect you, show them a little respect... you could have just said... hey guys, this freaks me out when you do this and causes me grief... could you please not do that? Again, this isn't a huge issue. Instead of talking at each other, everyone needs to talk TO each other. Everybody wants the best thing for Fedora and KDE. We don't need to involve FESCo... it's embarrassing.
One last thing... could we please stop, at least within the KDE community of using the phrases "You're in violation of Fedora Policy XYZ - or I'm opening up a FESCo ticket against you, etc. It's just wrong... are we not colleagues? It sounds too much like I'm reporting you to HR, or I'm telling the principle or I'm telling mommy. I believe when phases like that are used it sounds like we're in an authoritarian organization with the FESCo police around every corner waiting to issue tickets. It's not helping - we're colleagues not adversaries. If someone is being a brat or is having a mental breakdown - just ask them to calm down and stop freaking out. This is the Fedora Community, not a prison cell block.
@gbcox +1, thanks for your comments!
@lupinix: As I wrote on IRC: Just because you and rdieter personally prefer a "clean" .gitignore does not give you the right to enforce it in random other people's packages (and I should be considered a "random other person", I left the KDE SIG a couple years ago!). This is clearly controversial, and the policy for provenpackager edits explicitly forbids making controversial, subjective changes. And .gitignore changes are also not actual changes to the packaging. And also, technically, I did not remove a single line rdieter added, I only readded my lines that he removed. :-) For all these reasons, I really don't see why you see a fault on my end (as opposed to rdieter's) there.
@gbcox: I am not the one who decided to bring this to FESCo.
The difference in .gitignore usage is mainly due to the fact that some people want to aggressively delete old tarballs from their checkouts, whereas others (like me) rarely or never do that. I especially don't want to do this in QtWebEngine, which is very huge, so refetching tarballs from the lookaside cache if I need them for whatever reason takes a nontrivial amount of time.
Quoting @lupinix:
@kkofler By the way, accusing me to libel without knowing what I'm referencing??? Seriously?
The issue is that the way you formulated your accusation, it sounded to everyone (including me) as if I had actually been reverting actual packaging changes. If you had clearly stated that you were talking about .gitignore changes, it would not have made such an impression on FESCo.
(Now, on the other hand, @rdieter actually explicitly accused me of reverting packaging improvements, and I would really like to see what he is talking about. Because none of what I reverted was a packaging improvement. The changes from Helio that I reverted were an unfinished rebase that I redid in a better way (one where one can actually see by looking at the dist-git history what changed in the patches, because the old and new patches were produced using the same algorithm) and that I completed so that it actually works. I do not see any improvement that was lost in that process. Now, if @rdieter thinks managing downstream patches in a downstream fork of the upstream git is a packaging improvement, I am sorry, but I have to disagree there, and since I was going to be the one who would be ending up having to do the rebases later, changing the patch management to something that does not fit my workflow at all was a no go, sorry.)
I had written:
I have now filed https://pagure.io/fesco/issue/1785 for that.
Thank you very much @gbcox!
AFAIU the kde sig is planning to use the PR review workflow for all other packages as well. Also I really hope that the kde sig is not using this possibility to push a certain packaging style (such as changing the .gitignore file or unnecessarily rewriting patches) to qt5-qtwebengine.
@kkofler As I explained several times, also in IRC before we raised the ticket, my issue are the following reactions on things like in the IRC log I posted and on collaboration. I'm sorry if that was not clear enough. Things like "Thank you for pointing out exactly why I do not want any comaintainers for this package." which are not acceptable for such an important package in my opinion. The .gitignore thing is a matter of taste, as I already explanied to you. Normally I would consider that so less important that I'd even not talk about it, different opinions on such things are most normal thing in the world and it is easy to accept the maintainers opinion here. The reason why I mentioned it anyway is that a similar situation (the one with Helio if i remember correctly) lead to the removal of kdesig commit access. Mistakes happen, we are all humans, but it is not useful if we discuss on commit access then everytime (and a harsh sound in discussions, Helio left "thanks" to that sound, we asked you several times to follow code of conduct)… Also note that I don't have an issue with your way of package maintainance, it is hard to oversee that you're doing a very accurate job there. You're often asking what you're doing wrong, it is clearly not your own work, it is the refusal on collaboration.
The current FESCo solution with PR review workflow is a solution for the technical part of our problem, when you have an issue with a proposed commit now, you can argue why. But we now have the chance to force changes if we really need them but don't get to a consensus with you. Note that changes like the .gitignore are not changes we really need ;) Also the situation grew over time, but we formulated that FESCo ticket months ago and gave you a chance to move to a less controversial attitude with respect to collaboration. Or as you said in your first comment here: two yellow cards make a red card.
In your first reaction on FESCo you write
That's exactly the issue! You don't want to collaborate and even try the proposed solution which focuses on collaboration, not some dictatorship against you. And if we (KDE SIG) misuse the commit access, we risk that FESCo removes it, so we are also forced to follow that process, not just you.
Link to the meeting (one of them, maybe some discussion was in #fedora-kde, can search the logs on request) where we discussed about the FESCo ticket and gave Kevin another chance https://meetbot.fedoraproject.org/fedora-meeting/2017-06-20/kde-sig.2017-06-20-15.07.log.html
For example
15:43:26 <rdieter> so, my concrete outline proposal before to Kevin was: restore acls or we'll escalate matters to fesco.
EDIT: This was also the meeting where Helio left
You're often asking what you're doing wrong, it is clearly not your own work, it is the refusal on collaboration.
But the thing is, the FESCo arbitration procedure you invoked is intended only for the case where the packager is doing something wrong. You are abusing the process.
Deciding to maintain a package alone (after several negative experiences attempting to use collaborative processes on that package) is not by itself against policies.
The departure of Helio would also have been avoided if QtWebEngine had not been open to @kde-sig in the first place, and preventing such a toxic conflict from happening in the future was also an important part of my decision. By appealing it to FESCo, you immediately created a new toxic conflict, and the policy pronounced yesterday will definitely lead to more of them.
@kde-sig
But we now have the chance to force changes if we really need them but don't get to a consensus with you.
And that is exactly what I consider unacceptable (in addition to the technical implementation, where giving you commit access allows you to push things even without the requirements being satisfied – it would have made more sense to keep only me with direct push access). If you think that there is a specific change that you need to make Fedora KDE better and if I disagree about that change, that would be the time to ask FESCo to overrule me (that one time only) (and not just do it via a KDE SIG vote via a blanket FESCo mandate obtained through either outright false or very misleadingly worded accusations).
No more comments now from my side, I explained my reasoning and I feel we start to argue in a circle.
Exactly! @kkofler is the steward of this package, he took it through the approval process. He clearly takes pride in what he has accomplished - there is nothing wrong with that at all - in fact, I believe it is what we would want every packager to do. It's unseemly for someone to come in and demand stylistic changes. By the same token however, if you notice someone doing this @kkofler don't blow your lid - as I mentioned before just ask them not to do it. Guys, this isn't hard.
Also, as I mentioned above people need to be a bit more mature and stop using the Fedora Community Guidelines as a tool to advance passive/aggressive behaviour. Stop parsing each and every sentence someone says to attempt to find something insulting. When a friend, significant other or child says something do you parse every word looking for something to be insulted about? Of course not. The guidelines are there to foster cooperation, not to create some passive/aggressive utopia. If you're concentrating on being offended you're not trying to cooperate.
@lupinix I read your thread re: Helio - and it doesn't say exactly was said to him; and just references harassment - but it also talks about threats and ultimatums given to @kkofler; which isn't cooperation. So while Helio felt he was being bullied and reacted in one way, @kkofler believed he was being unjustly bullied and behaved in another.
@kkofler you need to stop blowing you lid and spewing on people. Personally, for me it's not an issue...but others get upset and it's not cool. Take a time out.
No FESCo edict is going to fix this... Everyone needs to try to put themselves in the other persons shoes, and consider what they are feeling - again, stop talking at each other and start talking to each other.
Everyone needs to stop digging up old arguments and battles. Continually reminding yourself of past conflicts isn't the way to move past them. Start fresh and consider that everyone is trying to do the right thing.
So @kkofler I would recommend you calm down and work within the policy. I believe the intent from FESCo IS NOT to take something away from you, nor change the style in which you maintain the package. @lupinix I would hope that everyone in the kde-sig realizes you don't have carte blanche over this package. The intent was to facilitate cooperation. If this comes back to FESCo you guys have failed. Play nice.
Another critical issue has also not been taken into consideration (because I sadly forgot to point it out in the stress of preparing my doctoral thesis defense which was yesterday): The qt5-qtwebengine package in Fedora must be kept in sync with the qt5-qtwebengine-freeworld package in RPM Fusion. (The Release can be different, but the Version must match (Requires with = operator).) This is because the qt5-qtwebengine-freeworld does not duplicate the (large) data files, it only overrides the shared library. @rdieter's unapproved version bump upgraded the version in Fedora to 5.9.2 while RPM Fusion is still on 5.9.1. This translates to broken dependencies for all users.
qt5-qtwebengine-freeworld
Requires
=
This is another reason why I do not accept any comaintainers for this package.
Unfortunately, while working on the RPM Fusion package, I found (and had to fix) 2 more undocumented changes in rdieter's unapproved commit that I hadn't noticed at first (well, I noticed the first but did not notice that it was not mentioned in the changelog, I entirely missed the second): https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/cd95d3668e67743ac6b771f4132219077886d295?branch=master https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/2e960e1561425c81a27a6068fcc2ae4f27127e4d?branch=master It is vital that the RPM changelog completely lists all changes, also because they have to be synced to the RPM Fusion package.
As I had promised, I also fixed the system re2 support (QtWebEngine upstream added direct support for it in 5.9.2, so it is not necessary to run the Chromium unbundling script on it anymore): https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/b81e4c0ba70b434340c06ea7da56d8375ed439ee?branch=master https://src.fedoraproject.org/rpms/qt5-qtwebengine/c/8895dc445aab6f9ca99427f2232cb2328b5c4dc7?branch=master
I am also currently building an updated (version 5.9.2) RPM Fusion package that should fix the dependencies.
[EDIT: Well, it should, but it fails to build because the builders cannot fetch vim-filesystem from Rawhide. I will try again another time.]
vim-filesystem
As this ticket was brought up again in today's meeting: * AGREED: FESCo stands behind the decision on Issue 1781. If the parties involved do not agree, they can appeal to the council (+6,0,-0) (jforbes, 16:57:28)
We sincerely hope that things can settle into a stable working relationship here.
Metadata Update from @sgallagh: - Issue close_status updated to: Fixed
Login to comment on this ticket.