commit d116b2a7d690b9a9717b7b97b8c67eda503756e3 Author: Alon Bar-Lev <alonbl@gentoo.org> AuthorDate: 2019-07-02 18:48:35 +0200 Commit: Alon Bar-Lev <alonbl@gentoo.org> CommitDate: 2019-07-02 18:49:59 +0200 dev-libs/crypto++: add explicit cpu_flags_x86 flag Closes: https://bugs.gentoo.org/show_bug.cgi?id=689162 Signed-off-by: Alon Bar-Lev <alonbl@gentoo.org> Package-Manager: Portage-2.3.66, Repoman-2.3.11 diff --git a/dev-libs/crypto++/metadata.xml b/dev-libs/crypto++/metadata.xml index 3227b3be7c78..4ceb05b8abe2 100644 --- a/dev-libs/crypto++/metadata.xml +++ b/dev-libs/crypto++/metadata.xml @@ -13,0 +14 @@ + <flag name="cpu_flags_x86_sha">Enable support for Intel's SHA instruction set (SHA-NI)</flag> --- Since this flag has been added after the committer has been explicitly informed that this is PMS violation (see [1], [2]) and he has been explicitly unwilling to do things properly, I would like to request QA to vote on 1 week ban. [1] https://bugs.gentoo.org/688872 [2] https://bugs.gentoo.org/688858
I asked you a question[1] you have not answered only to continue an complain... Maybe ban yourself as your cooperation spirit is far from being positive. [1] https://bugs.gentoo.org/show_bug.cgi?id=688858#c4
(In reply to Alon Bar-Lev from comment #1) > I asked you a question[1] you have not answered only to continue an > complain... Maybe ban yourself as your cooperation spirit is far from being > positive. > > [1] https://bugs.gentoo.org/show_bug.cgi?id=688858#c4 You have been asked to fix the QA bug. How you do it is up to you. Given the fact that cpuid2cpuflags hasn't been updated, I would 1. remove the functionality 2. add it globally (via ML input) 3. add the flag in cpuid2cpuflags 4. add it back in the ebuild It is not the responsibility of others to update cpuid2cpuflags if you added it to the tree.
Beats me why you reply here for a question in other bug that waiting for your response. In current method user may enjoy the functionality per manually adding this flag. Anyway, just because the actual name of the flag is so important to you I will add temp- prefix to the USE flag for people to be able to use functionality until you find a time to update the cpuid2cpuflags instead wasting time of opening bugs to remove functionality for users.
(In reply to Alon Bar-Lev from comment #3) > Beats me why you reply here for a question in other bug that waiting for > your response. > > In current method user may enjoy the functionality per manually adding this > flag. > > Anyway, just because the actual name of the flag is so important to you I > will add temp- prefix to the USE flag for people to be able to use > functionality until you find a time to update the cpuid2cpuflags instead > wasting time of opening bugs to remove functionality for users. No, it is up to you to ensure a smooth UX for users. How will users know how to enable it? dig through all local USE flags and on the off chance notice it? It is your duty to update cpuid2cpuflags and provide for a smooth experience for users.
I'm sorry, I presumed that was a rhetorical question since you finish saying that you've already selected a solution. Not to say that none of those three options are satisfactory, and the sole fact that you actively oppose doing the *trivial* work of submitting a patch for review to add the new global flag makes me wonder if you really want to continue being a Gentoo developer. After all, you seem entirely opposed to working with others, and intent on adding work for others to do.
(FTR, I would have had no problem updating cpuid2cpuflags if you followed the policy in the first place and submitted the global flag patch in the first place)
So you intentionally waste everyone time just to prove your point and not update cpuid2cpuflags? You want users to wait for features just to show everyone whose the boss? I do not get it. Anyway, I renamed the USE to allow use to use this functionality until you finally update cpuid2cpuflags or add the flag as global updating all profiles if required.
If you do not send in a proposal for the global USE flag, we will(In reply to Alon Bar-Lev from comment #7) > So you intentionally waste everyone time just to prove your point and not > update cpuid2cpuflags? You want users to wait for features just to show > everyone whose the boss? I do not get it. > > Anyway, I renamed the USE to allow use to use this functionality until you > finally update cpuid2cpuflags or add the flag as global updating all > profiles if required. Why can you not just send the email? What is wrong about co-operating with others? Again, you violated PMS, so it is up to you to rectify it.
Nothing was violated, users may specify local USE by full name regardless of the USE expand as always.
(In reply to Alon Bar-Lev from comment #9) > Nothing was violated, users may specify local USE by full name regardless of > the USE expand as always. mgorny has specifically told you why your cpu_flags_x86 local addition violates PMS, yet you continue to argue around well-established facts.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=57980c409d0770cf99b2b9ab89e1b02220c5a4fa commit 57980c409d0770cf99b2b9ab89e1b02220c5a4fa Author: Alon Bar-Lev <alonbl@gentoo.org> AuthorDate: 2019-07-08 13:21:25 +0000 Commit: Alon Bar-Lev <alonbl@gentoo.org> CommitDate: 2019-07-08 13:31:14 +0000 dev-libs/crypto++: USE cpu_flags_x86_sha->preview-cpu_flags_x86_sha A temporary solution until cpu_flags_x86_sha available. Closes: https://bugs.gentoo.org/show_bug.cgi?id=689476 Signed-off-by: Alon Bar-Lev <alonbl@gentoo.org> Package-Manager: Portage-2.3.66, Repoman-2.3.11 dev-libs/crypto++/crypto++-8.2.0-r2.ebuild | 4 ++-- dev-libs/crypto++/metadata.xml | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
I looked at dev guide again, did not find a reference, anyway, as I wrote, I renamed the USE flag to local one, adding preview- prefix. Next step is just to remove functionality which will not serve anyone.
Please do not close QA bugs until they are resolved, and especially do not close QA bugs where a request to issue disciplinary action against yourself was stated. Furthermore, I would like to extend the reasoning for that request to double argument that not only deliberately violate policy but you also stubbornly apply workarounds to the policy just to avoid doing things right and force others to do your work for you, and harm users in the process.
(In reply to Alon Bar-Lev from comment #12) > I looked at dev guide again, did not find a reference, anyway, as I wrote, I > renamed the USE flag to local one, adding preview- prefix. > > Next step is just to remove functionality which will not serve anyone. I will give you a week to send the proposed USE flag to the ML.
> I will give you a week to send the proposed USE flag to the ML. what? local USE? OK, removed.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a1cd4b52d4fcb499ea4416c17dd2638e2362b70e commit a1cd4b52d4fcb499ea4416c17dd2638e2362b70e Author: Alon Bar-Lev <alonbl@gentoo.org> AuthorDate: 2019-07-08 13:41:47 +0000 Commit: Alon Bar-Lev <alonbl@gentoo.org> CommitDate: 2019-07-08 13:42:53 +0000 dev-libs/crypto++: remove preview-cpu_flags_x86_sha Bug: https://bugs.gentoo.org/show_bug.cgi?id=689476 Signed-off-by: Alon Bar-Lev <alonbl@gentoo.org> Package-Manager: Portage-2.3.66, Repoman-2.3.11 dev-libs/crypto++/crypto++-8.2.0-r2.ebuild | 4 ++-- dev-libs/crypto++/metadata.xml | 1 - 2 files changed, 2 insertions(+), 3 deletions(-)
(In reply to Alon Bar-Lev from comment #15) > > I will give you a week to send the proposed USE flag to the ML. > > what? local USE? > > OK, removed. cpu_flags_x86_sha
(In reply to David Seifert from comment #17) > (In reply to Alon Bar-Lev from comment #15) > > > I will give you a week to send the proposed USE flag to the ML. > > > > what? local USE? > > > > OK, removed. > > cpu_flags_x86_sha I do not see any flag at this name any more. When there will be I will update my packages to use it, until then people will not be able to leverage this. Cheers.
(In reply to Alon Bar-Lev from comment #18) > (In reply to David Seifert from comment #17) > > (In reply to Alon Bar-Lev from comment #15) > > > > I will give you a week to send the proposed USE flag to the ML. > > > > > > what? local USE? > > > > > > OK, removed. > > > > cpu_flags_x86_sha > > I do not see any flag at this name any more. When there will be I will > update my packages to use it, until then people will not be able to leverage > this. > > Cheers. Alright, just because you did not want to send one simple email.
(In reply to David Seifert from comment #19) > (In reply to Alon Bar-Lev from comment #18) > > (In reply to David Seifert from comment #17) > > > (In reply to Alon Bar-Lev from comment #15) > > > > > I will give you a week to send the proposed USE flag to the ML. > > > > > > > > what? local USE? > > > > > > > > OK, removed. > > > > > > cpu_flags_x86_sha > > > > I do not see any flag at this name any more. When there will be I will > > update my packages to use it, until then people will not be able to leverage > > this. > > > > Cheers. > > Alright, just because you did not want to send one simple email. You give me week? seriously? thank you! I ask question, explaining what/how I've done and you are threatening to ban? This instead of just doit approach on behalf of the flags maintainer and finalize the work? I choose do nothing in this atmosphere. Have a very nice day.
There is no such thing as 'flags maintainer'. Everyone is responsible for his own actions. You choose not to take responsibility, and instead go on rage-removal quest that's harmful to everyone around you. I sustain my request to remove commit access for a week, with possibility of requesting full commit access removal if you persist with this destructive attitude.
(In reply to Alon Bar-Lev from comment #20) > (In reply to David Seifert from comment #19) > > (In reply to Alon Bar-Lev from comment #18) > > > (In reply to David Seifert from comment #17) > > > > (In reply to Alon Bar-Lev from comment #15) > > > > > > I will give you a week to send the proposed USE flag to the ML. > > > > > > > > > > what? local USE? > > > > > > > > > > OK, removed. > > > > > > > > cpu_flags_x86_sha > > > > > > I do not see any flag at this name any more. When there will be I will > > > update my packages to use it, until then people will not be able to leverage > > > this. > > > > > > Cheers. > > > > Alright, just because you did not want to send one simple email. > > You give me week? seriously? thank you! > I ask question, explaining what/how I've done and you are threatening to > ban? This instead of just doit approach on behalf of the flags maintainer > and finalize the work? I choose do nothing in this atmosphere. > > Have a very nice day. What ominous "flags maintainer"? Do you think we have a person dedicated to maintaining global flags? This is the responsibility of all Gentoo developers. I asked you nicely to send an email to the ML, requesting addition of 'cpu_flags_x86_sha', which would easily pass. The amount of energy you invested in renaming all the local flags is more than writing a simple email. You clearly prefer to work against QA than work with QA. Instead of working to try and improve the user experience for our user base you 1. Added a PMS-violating construct that requires obscure digging through local USE flags 2. Didn't care about amending cpuid2cpuflags. Even worse, given this optional step, mgorny volunteered to add it if you sent an email to the ML. 3. Trying everything to work against our requests for maintaining a consistent global definition of USE_EXPAND flags. For the last time, I request you send a simple email to the ML within a week, otherwise we will have to consider a 1-week ban.
@mgorny: we have been in this loop in the past, you like banning people, that great, not everyone agree with your approach. app-portage/cpuid2cpuflags/metadata.xml: --- <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"> <pkgmetadata> <maintainer type="person"> <email>mgorny@gentoo.org</email> <name>Michał Górny</name> </maintainer> <upstream> <remote-id type="github">mgorny/cpuid2cpuflags</remote-id> </upstream> </pkgmetadata> ---
(In reply to Alon Bar-Lev from comment #23) > @mgorny: we have been in this loop in the past, you like banning people, > that great, not everyone agree with your approach. > > app-portage/cpuid2cpuflags/metadata.xml: > --- > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"> > <pkgmetadata> > <maintainer type="person"> > <email>mgorny@gentoo.org</email> > <name>Michał Górny</name> > </maintainer> > <upstream> > <remote-id type="github">mgorny/cpuid2cpuflags</remote-id> > </upstream> > </pkgmetadata> > --- That is a package (which mgorny would have amended for you). That has nothing to do with maintaining USE_EXPAND to remain consistent.
(In reply to Alon Bar-Lev from comment #23) > @mgorny: we have been in this loop in the past, you like banning people, > that great, not everyone agree with your approach. > > app-portage/cpuid2cpuflags/metadata.xml: > --- > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"> > <pkgmetadata> > <maintainer type="person"> > <email>mgorny@gentoo.org</email> > <name>Michał Górny</name> > </maintainer> > <upstream> > <remote-id type="github">mgorny/cpuid2cpuflags</remote-id> > </upstream> > </pkgmetadata> > --- We are still waiting for a short email (see mgorny's email for AVX512F and F16C).
So a week has passed, and alonbl did nothing to fix this, besides vandalising the package. Therefore, I would like to formally request a vote on issuing 1 week ban.
@QA Team Please vote on this. I vote yes.
(In reply to David Seifert from comment #27) > @QA Team > Please vote on this. > > I vote yes. Yes
Arguably commit d116b2a7d690 (introducing cpu_flags_x86) could still have been taken as a honest mistake, and correcting it would have been easy, as outlined in comment #2. However, commits 57980c409d07 (renaming to preview-&) and a1cd4b52d4fc (disabling the flag) let us look like prats. Don't do that. (In reply to David Seifert from comment #27) > @QA Team > Please vote on this. I abstain from the vote.
I vote yes. (CC-ing remaining members who did not vote)
I abstain. I do not think Alon was right about adding local USE flag, but i am not sure if he should be banned for that.
(In reply to Sergey Popov from comment #31) > I abstain. I do not think Alon was right about adding local USE flag, but i > am not sure if he should be banned for that. The ban is not for 'adding local USE flag' but for refusing to fix it, and for causing user-visible mayhem just to avoid fixing it.
(In reply to Michał Górny from comment #32) > (In reply to Sergey Popov from comment #31) > > I abstain. I do not think Alon was right about adding local USE flag, but i > > am not sure if he should be banned for that. > > The ban is not for 'adding local USE flag' but for refusing to fix it, and > for causing user-visible mayhem just to avoid fixing it. Sorry, i was not very active lately and it seems that i have missed some really bad shitstorm. I re-read alias e-mails and realized that i voted too early without knowing full background - he did it with multiple packages even when said not to continue doing that. Anyway, it's already done, so please continue counting my vote as 'abstain'
(In reply to David Seifert from comment #27) > @QA Team > Please vote on this. > Yes.
The ban was never actually issued, and in any case it'd have expired by now. Closing.
