Created attachment 444204 [details] qtfm 5.9 ebuild qtfm supports mainstream Qt5 now New HOMEPAGE : https://www.linux-apps.com/p/1131642/ New SRC_URI : https://dl.opendesktop.org/api/files/download/id/1466643163/158787-qtfm.zip ebuild in attchment
(In reply to Vincent Hardy from comment #0) > Created attachment 444204 [details] > qtfm 5.9 ebuild > > qtfm supports mainstream Qt5 now > > New HOMEPAGE : https://www.linux-apps.com/p/1131642/ That doesn't look very reliable. > New SRC_URI : > https://dl.opendesktop.org/api/files/download/id/1466643163/158787-qtfm.zip Again, I don't know who uploaded that.
There is a Google Code project[1] that got imported on Github[2] later without any further changes and a single commit after the 5.9 tag was added. [1] https://code.google.com/archive/p/qtfm/ [2] https://github.com/RomanVolak/qtfm
Dear jer, please use GLEP 66 tags for referencing bugs. GLEP 66 provides for machine parseable tags, and it would be nice if all developers honour a council-approved GLEP.
(In reply to David Seifert from comment #3) > Dear jer, please use GLEP 66 tags for referencing bugs. GLEP 66 provides for > machine parseable tags, and it would be nice if all developers honour a > council-approved GLEP. Did you actually read https://www.gentoo.org/glep/glep-0066.html#id18 ? " A standard git commit message consists of three parts, in order: a summary line, an *optional* body and an *optional* set of tags. " (emphasis added) Cont.: " If a bug is associated with a change, then it can be included in the summary line as bug #nnnnnn. " But look: " commit b4f6f083191be5038f194b2ce070b0fc7d8ad9f7 Author: Jeroen Roovers <jer@gentoo.org> Date: Sat Jan 13 12:12:54 2018 +0100 x11-misc/qtfm: Version 5.9 (bug #592194 by Vincent Hardy). Package-Manager: Portage-2.3.19, Repoman-2.3.6 " And: " Git does not enforce any standardization of the keys, and the tag format is _not_ meant for machine processing. " (original emphasis) So what are you CC'ing qa@ for? Enforcing nice suggestions?
(In reply to David Seifert from comment #3) > Dear jer, please use GLEP 66 tags for referencing bugs. GLEP 66 provides for > machine parseable tags, and it would be nice if all developers honour a > council-approved GLEP. See also bug #643040 where mgorny tried to pull the same crap. *Optional* features are now being enforced through QA threats?
(In reply to Jeroen Roovers from comment #4) > (In reply to David Seifert from comment #3) > > Dear jer, please use GLEP 66 tags for referencing bugs. GLEP 66 provides for > > machine parseable tags, and it would be nice if all developers honour a > > council-approved GLEP. > > Did you actually read https://www.gentoo.org/glep/glep-0066.html#id18 ? > > " > A standard git commit message consists of three parts, in order: a summary > line, an *optional* body and an *optional* set of tags. > " (emphasis added) In this context "optional" means that it is not present if it would be empty, and nothing more. It doesn't excuse writing incomplete commit messages. > > Cont.: > > " > If a bug is associated with a change, then it can be included in the summary > line as bug #nnnnnn. > " > > But look: > > " > commit b4f6f083191be5038f194b2ce070b0fc7d8ad9f7 > Author: Jeroen Roovers <jer@gentoo.org> > Date: Sat Jan 13 12:12:54 2018 +0100 > > x11-misc/qtfm: Version 5.9 (bug #592194 by Vincent Hardy). > > Package-Manager: Portage-2.3.19, Repoman-2.3.6 > " > > And: > > " > Git does not enforce any standardization of the keys, and the tag format is > _not_ meant for machine processing. > " (original emphasis) Which is true in general. However, the list below explicitly indicates which tags are machine processed in context of Gentoo. > > So what are you CC'ing qa@ for? Enforcing nice suggestions? 1. You don't unCC qa if you disagree with qa member. 2. I find it extremely unprofessional that you unCC me and then insult me immediately afterwards.
(In reply to Michał Górny from comment #6) > 2. I find it extremely unprofessional that you unCC me and then insult me > immediately afterwards. I didn't un-CC *you*. I un-CC'd QA. Funny how you mixed those up. The rest of your contribution to this bug report, which I resolved by doing actual work, is entirely off-topic on this bug report. I'll leave "you" CC-d as you apparently want to focus more on the Qt4 deprecation related qtfm version bump.
(In reply to Michał Górny from comment #6) > > So what are you CC'ing qa@ for? Enforcing nice suggestions? > > 2. I find it extremely unprofessional that you unCC me and then insult me > immediately afterwards. Also note that I vehemently disagree that there was an insult. I asked soap@ why QA was CC'd, and summarised that it might be because the conclusion of his complaint about my commit message is that I left out some nice commit tags and that QA would want to enforce using those nice commit tags. How is that an insult?
(In reply to Jeroen Roovers from comment #8) > (In reply to Michał Górny from comment #6) > > > So what are you CC'ing qa@ for? Enforcing nice suggestions? > > > > 2. I find it extremely unprofessional that you unCC me and then insult me > > immediately afterwards. > > Also note that I vehemently disagree that there was an insult. I asked soap@ > why QA was CC'd, and summarised that it might be because the conclusion of > his complaint about my commit message is that I left out some nice commit > tags and that QA would want to enforce using those nice commit tags. How is > that an insult? Although I find it surprising that there is so much conflict surrounding the format of a commit message, if a member of QA invokes qa, please contact the project lead of QA for either a team vote or at least an explanation. QA lead is empowered though GLEP 48 to perform certain actions, and also the one responsible towards the rest of the community for action performed in the name of QA, and as such the necessary first step of escalation.
(In reply to Kristian Fiskerstrand from comment #9) > if a member of QA invokes qa You want people to first check whether the person they want to call the police on, is in fact a policeman, and take action based on that knowledge. No wonder mgorny thinks "qa@" == "he".
(In reply to Jeroen Roovers from comment #10) > (In reply to Kristian Fiskerstrand from comment #9) > > if a member of QA invokes qa > > You want people to first check whether the person they want to call the > police on, is in fact a policeman, and take action based on that knowledge. > No wonder mgorny thinks "qa@" == "he". I would really appreciate if you ceased your insinuations and unfounded aggression against me. I merely stated that you unCC-ed all the parties who could have noticed your insulting comment before leaving it. That said, I'm done here. If you really believe the best thing you can do for Gentoo is offload your aggression into Bugzilla, then please attack somebody else. I came here only to correct the factual mistakes in your comment and help you understand the document that I've written. If you do not wish to learn and prefer to attack the people who are trying to help you, that is not a thing I can change. And that is certainly not a thing that I wish to be suffering for.
(In reply to Michał Górny from comment #11) > noticed your insulting comment What insulting comment?
