Thomas Deutschmann <whissi@gentoo.org> has taken over responsibility at https://bugs.gentoo.org/668036#c4 as Gentoo developer and security expert (label) 1. He starts with his evaluation: "But don't overrate these vulnerabilities: Yes, ..." But the Mozilla foundation with a bunch of high paid security experts comes to another conclusion: updating thunderbird-60.2.1 is "critical". See at: https://www.mozilla.org/en-US/security/advisories/mfsa2018-25/ 2. Thomas Deutschmanns first sentence was: "We are working on this." This short statement is ok if no further communication is needed for a Gentoo developer to deliver a new ebuild: As user I think there is not much needed but a few edits of some version variables. But a week long nothing happened. I had a look on most recent developer git overlays: no activity there. Therefore I searched for other ebuilds at zugaina. I found one, but I had difficulties (forgotten mozconfig eclass in the way in my local overlay). I needed some hours to find my error. When successfully emerging the thunderbird-60.2.1 ebuild from the foreign github overlay, I reported back to the bug 668036 what I found in the build log: "Please update MOZ_LIGHTNING_VER in the ebuild from 6.2 to 6.2.2.1" Thomas Deutschmann answered at https://bugs.gentoo.org/668036#c8 "And Lightning is the reason why we haven't pushed a new ebuild yet: ..." This doesn't feel good in the follow up of his first sentence. (The procedure feels like from a corporation to me the customer)
Hi Ulenrich and thank you for the report, As you know Gentoo is an open-source project, and people here spend as much time as they can afford. I understand your frustration, but sometimes things just get stuck a bit. For the case you reported I beleieve Thomas wanted to implement the most sane solution he could find (an use flag masking is not the best solution as you can see). I believe that the solution will be found soonish. The Comrel team handles community conflicts, from what you referenced I have not found a conflict signs of any kind and, hence, as I can conclude we can do nothing here (and neither we should).
@Mikle, I am pretty sure you didn't get what I want: As an enthusiast Gentoo user since 10 years I don't want to be handled like a customer of a corporation. I don't expect a Gentoo developer to be an expert programmer who can deliver perfect patches. If Thomas cannot program/find a needed patch he should tell and NOT shortly answer: "We are working on this." We have a community. I think he needs some guidance about it. About the security aspect: I, myself have seen in the Debian project some cases where famous Debian developpers thought they can provide better than upstream developers: For example Debian had used quiet some time self developed entropy functions for randomness. Years later was found these had no entropy at all. Thus: If a heavy million dollar Mozilla organization claims an update is critical: It is critical !!! Therefore: A masked USE through means of the profiles whould have been a possibility to provide the needed update of thunderbird-60.2.1 in this case.
I don't want no public fight against Thomas. On the contrary I really appreciate his work! I used this comrel bug, because someone should talk to him about in private.
I don't understand what you're upset about. Is it his "evaluation" (bug 668036#c4)? Is it that it's not fixed within a week? Is it that he didn't explain himself but just said "We are working on this."? I don't know why you would be upset by any of this. You say you don't want to be treated like a customer of a corporation, so don't treat him like a vendor that isn't providing you the quality of service you desire.
As to why your suggested solution of use.masking a flag is maybe not the best plan, see the confusion caused by what I'm imagining is a similar solution in Ubuntu: https://askubuntu.com/questions/1084059/latest-update-to-thunderbird-60-2-1-on-18-04-lightning-calendar-missing
I am not upset but (a little) unhappy about handled like a customer. If you cann't see what I mean, then please forget about it and turn this bug solved finally.
(In reply to Ulenrich from comment #6) > I am not upset but > (a little) unhappy about handled like a customer. > > If you cann't see what I mean, then please forget about it > and turn this bug solved finally. Look, I'm probably one of the most sympathetic comrel members to complaints of bad behavior, but I'm not seeing any here. I'm legitimately trying to understand what the problem is. You seem to be unhappy because someone doing free work hasn't done what you want or done it quickly enough. That's not a good basis for a complaint. I don't know what else to tell you. If you've used Gentoo for 10 years you should know that's not really how free software development works. Thomas does a lot of work in Gentoo. As a result, he has assumed various responsibilities and as a result he gets to decide how to do the work.
(In reply to Ulenrich from comment #2) > I don't want to be handled like a customer of a corporation. I do not see you were handled like that. > > I don't expect a Gentoo developer to be an expert programmer who can deliver > perfect patches. If Thomas cannot program/find a needed patch he should tell > and NOT shortly answer: > "We are working on this." > We have a community. I think he needs some guidance about it. Please do not claim what a developer can or can not do, it is very unproffesional way, if you claim you are 10 years experienced gentoo user you must understand this. > > About the security aspect: > I, myself have seen in the Debian project some cases where famous Debian > developpers thought they can provide better than upstream developers: For > example Debian had used quiet some time self developed entropy functions for > randomness. Years later was found these had no entropy at all. > > Thus: > If a heavy million dollar Mozilla organization claims an update is critical: > It is critical !!! Sorry, but this statement serves for nothing, we do not discuss debian here. Let me ephasize that Comrel handles behaviour problems, I do not see the one with Whissi, so this bug stays invalid. Please take a look at the Comrel Project page about when we should be involved [1] [1] - https://wiki.gentoo.org/wiki/Project:ComRel
