💡 [REQUEST] - Nondzu/Mistral-7B-codealpaca-lora

Model introduction
https://huggingface.co/Nondzu/Mistral-7B-codealpaca-lora
Model URL
https://huggingface.co/Nondzu/Mistral-7B-codealpaca-lora
Data type
float16
Additional instructions (Optional)
require  48GB VRAM to run  in full precision
Author

[X] Yes
[ ] No

Security

[X] I confirm

Integrity

[X] I confirm

Hi @Nondzu  I am able to get the following results using direct prompting (e.g., without using instructions).

Let me know if you are hoping to get a instruction-prompted version evaluated. If so please indicate the prompt structure and how it is supposed to be parsed. :P

@ganler I am not sure why your results has that many difference.
Also when I did test for original Mistral model i got higher output
<img width="276" alt="image" src="https://github.com/evalplus/evalplus/assets/20000097/0d5d655a-6a9e-4239-8b6c-a9d52a006410">
here is link to my code generate_one_completion that I use to run evalPlus test https://huggingface.co/Nondzu/Mistral-7B-codealpaca-lora/blob/main/run-humaneval.py
But I have 24Vram GPU so I use 8bit mode. When I try use a codegen/generate.py script I got OOM and had the same result what you got.
Do you have log from the generation ?

I can see the following differences from https://huggingface.co/Nondzu/Mistral-7B-codealpaca-lora/blob/main/run-humaneval.py#L23
In EvalPlus' codegen:

do_sample=False for greedy decoding
top_p=0.95 following the codex paper
top_k is unset
temperature=0 for greedy decoding
We use a larger max_new_tokens (i.e., 512)
skip_special_tokens is unset by default
We use float16 instead of 8-bit on A100@80G

I will try to sync your configs for 6 and do a re-try.

Notably I am also using https://github.com/evalplus/evalplus/blob/master/tools/sanitize.py to fix some trivial syntax errors.

I can see the following differences from https://huggingface.co/Nondzu/Mistral-7B-codealpaca-lora/blob/main/run-humaneval.py#L23
In EvalPlus' codegen:

do_sample=False for greedy decoding
top_p=0.95 following the codex paper
top_k is unset
temperature=0 for greedy decoding
We use a larger max_new_tokens (i.e., 512)
skip_special_tokens is unset by default
We use float16 instead of 8-bit on A100@80G

I will try to sync your configs for 6 and do a re-try.

This is what I achieved after the revision.

Well yes and no ;)
I want to run other test to make sure what exactly difference is between mine implementation of generate_one_completion   and generate.py code.
@ganler Do you use the same HFTorchDecoder like to original Mistral model ?

@Nondzu You can check it out here: https://github.com/evalplus/evalplus/commit/d66e2f8a8562f309bfcabe3122fc6fe7cced8b6f
git clone https://github.com/evalplus/evalplus.git
cd evalplus
export PYTHONPATH=$PWD
python codegen/generate.py --model mistral-7b-codealpaca --bs 1 --temperature 0 --n_samples 1 --resume --root /scratch/humanevalp --greedy

I think I know why. Some of the output samples produced by your model can include </s>. By removing such now I get:

Updated to our leaderboard. Congratulations!

This might also explain why the Mistral scores I achieved is a little bit smaller than what they reported officially. ;P

I have updated this to our code cleaner!

@ganler Many thanks for your work!


Game Settings Panel Implementation

Description
Implement a settings panel with audio controls, difficulty selection, and background customization options.
Requirements

[ ] Make sure to update the game state context provider of you implementation game-hook.tsx
[ ] Create sound volume slider with proper icons and 10-step indicator
[ ] Implement music volume slider with note icons and 10-step indicator
[ ] Add difficulty selection buttons:

Beginner (default)
Experienced
Professional

[ ] Add background customization option
[ ] Implement proper state management for settings
[ ] Add close button functionality

Can I take care of this issue?

Please can I work on this?

I am a Full Stack Developer with a strong background in blockchain and extensive experience in Next.js/React, TypeScript, and Rust. I’ve made over 49 contributions to over 17 projects in the OnlyDust ecosystem, solving complex issues and delivering efficient, scalable solutions.
I can handle this task.
ETA is 3days.

Hello, I’d love to work on this issue as I have strong experience with front-end development. Please assign this to me, and I’ll deliver an efficient and secure PR within 12-24 hours.

Can I handle this task?

I am new to open source.
To address this issue, I would implement the Game Settings Panel by adding sliders for volume control of sound and music with appropriate icons and 10-step indicators. Add buttons for difficulty selection, such as Beginner, Experienced, Professional, and an option to change the background. Update the gamestate context provider to manage state changes. The panel should close without any hitch.

I would like to work on this issue

Let me handle this issue!

Could I take a shot at this?

Hi, I’m Santiago Villarreal Arley, a proactive and communicative developer with experience in building modular front-end components and scalable Web3 solutions. I’ve contributed to projects where I delivered user-friendly interfaces and maintained efficient state management.
To tackle this issue:
Implement a settings panel with sliders for sound and music volume (10-step indicators, icons included).
Add difficulty selection buttons (Beginner, Experienced, Professional) with Beginner as default.
Include background customization options with proper state management integrated into the game state context provider (game-hook.tsx).
Ensure smooth functionality for the close button and an intuitive UI.
ETA: 12-48 hours. Feel free to reach out via Telegram

Can I attempt this issue?

Could I be assigned to this?


This solution does not work behind a proxy

It should be noted on this page that this solution will not work behind a web proxy. There is no supported way to install the helm stable repository behind a proxy. The connection will time out since helm is not proxy aware or have the ability to make it so.

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 597ba957-9501-5919-73a0-6d47b1ca2c6d
Version Independent ID: 6345fa19-b3f2-ffd6-f526-908f845b51f6
Content: Use your TLS certificates for ingress - Azure Kubernetes Service
Content Source: articles/aks/ingress-own-tls.md
Service: container-service
GitHub Login: @mlearned
Microsoft Alias: mlearned

@jamesorlando
Thanks for the feedback! I have assigned the issue to content author to check and update the document as appropriate.

@zr-msft @mlearned
Can you please check and add your comments on this doc update request as applicable.

Thank you @jamesorlando for the feedback!
I've updated the article to address your feedback and the changes should be available soon.


State that sign-in for a user having user level MFA vs MFA through conditional policies will not work

When a user MFA is set using the "user level MFA" from https://account.activedirectory.windowsazure.com/UserManagement/MultifactorVerification.aspx?BrandContextID=O365 versus conditional access policies MFA in the AAD (from the azure portal), the user cannot login to the machine. He needs to disable the user level MFA from the link above for it to work.
Also state that if a sign-in is done through a Windows 10 PC that doesn't use strong authentication, it will not satisfy a conditional access policy that requires MFA to sign-in and need to bypass the strong authentication requirement by adding the Azure Windows VM Sign-in as an Excluded cloud application on the policy

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: c946fe0f-e18d-2529-2fbf-bce04759fbca
Version Independent ID: 885a61d1-6096-5aa0-fe8d-f1ec8d55e542
Content: Sign in to Windows virtual machine in Azure using Azure Active Directory (Preview)
Content Source: articles/active-directory/devices/howto-vm-sign-in-azure-ad-windows.md
Service: active-directory
Sub-service: devices
GitHub Login: @MicrosoftGuyJFlo
Microsoft Alias: joflore

@DOMZE Thanks for the feedback !  I have assigned this issue to content author to investigate and update the document as appropriate.


Hybrid - Launch - App is reloaded everytime that it´s backgrounded and opened again.

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Version Number: 9.0.65-0
Reproducible in staging?: Y
Reproducible in production?: N
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: N
Logs: https://stackoverflow.com/c/expensify/questions/4856
Issue reported by: Applause-Internal team
Action Performed:

Open the Expensify app.
Open any chat.
Background the app.
Reopen the app.
Verify that the app doesn´t load again and that you remain on the opened chat.
Navigate to a different section. (For Example: Search)
Background the app.
Reopen the app.
Verify that the app is not loaded again and that you remain on the opened section.

Expected Result:
App shouldn´t be reloaded everytime that is backgrounded and reloaded and the user should remain on the same chat or section that before it was backgrounded.
Actual Result:
The app is reloaded everytime that is backgrounded and reopened and the user returns to inbox instead of remaining on the opened chat or section.
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

[ ] Android: Standalone
[x] Android: HybridApp
[ ] Android: mWeb Chrome
[ ] iOS: Standalone
[ ] iOS: HybridApp
[ ] iOS: mWeb Safari
[ ] MacOS: Chrome / Safari
[ ] MacOS: Desktop

Screenshots/Videos
https://github.com/user-attachments/assets/3d853be2-afcf-4127-8467-bcdccfe4c643
View all open jobs on GitHub

ok, I could reproduce on 9.0.65-1

I wonder if this is the offending  PR, @Julesssss @war-in

I wonder if this is the offending PR, @Julesssss @war-in

if yes, then I think it doesn't make sense to block the NewDot deployment, given that it needs to be fixed in the OldApp repository.

More context here.
TLDR: It seems that the root cause is from the OldApp code, so it might not make sense to deploy the App deployment.

I'd prefer to fix this, it should be as simple as changing the Activity launch type. I will test a build

PR for fix: https://github.com/Expensify/Mobile-Expensify/pull/13296

Alright, so we just need an App bump for this to be testable by QA.

CP'd build in progress https://github.com/Expensify/App/actions/runs/11975270560

Reopening for QA verification: https://github.com/Expensify/App/issues/52874

https://expensify.slack.com/archives/C9YU7BX5M/p1732291578881379

Fix has been tested - https://expensify.slack.com/archives/C9YU7BX5M/p1732293554743679?thread_ts=1732291578.881379&cid=C9YU7BX5M
removing blocker label.

Keeping closed - this one was handled internal


Quick question: Do not quite understand simple output

This simple example shows a different edit distance compared to networkX's GED. Would be great if someone could help me understand the difference. From my understanding of GED, the edit distance should be 1, not 2.
import networkx
import gmatch4py as gm

g1=nx.complete_bipartite_graph(2,3)
g2=nx.complete_bipartite_graph(2,3)
g2.add_edge(0, 1)
adj=[(v, neighbors) for v, neighbors in g1.adjacency()]
print(adj)
adj=[(v, neighbors) for v, neighbors in g2.adjacency()]
print(adj)
ged=gm.GraphEditDistance(1,1,1,1) # all edit costs are equal to 1
result=ged.compare([g1,g2],None)
print(result)

[(0, {2: {}, 3: {}, 4: {}}), (1, {2: {}, 3: {}, 4: {}}), (2, {0: {}, 1: {}}), (3, {0: {}, 1: {}}), (4, {0: {}, 1: {}})]
[(0, {2: {}, 3: {}, 4: {}, 1: {}}), (1, {2: {}, 3: {}, 4: {}, 0: {}}), (2, {0: {}, 1: {}}), (3, {0: {}, 1: {}}), (4, {0: {}, 1: {}})]

[[0. 2.]
 [2. 0.]]

ged_nx = nx.graph_edit_distance(g1, g2)
print(ged_nx)

1.0

It depends on the algorithm heuristic used to compute the edit distance. Here, the algorithm heuristic is different from the one used by networkX


[turborepo] "outputs" data of turbo.json does not work, and automatically creates a .next directory no matter what

What version of Turborepo are you using?
1.10.2
What package manager are you using / does the bug impact?
pnpm
What operating system are you using?
Mac
Describe the Bug
{
  "$schema": "https://turbo.build/schema.json",
  "pipeline": {
    "build": {
      "outputs": ["dist/**", ".next/**", "!.next/cache/**"]
    },
    "lint": {}
  }
}

I put this in as turbo.json and it only creates .next directory! It doesn't create a /dist directory.
I also removed the .next/** string and !.next/cache/** and it still created a .next directory. Seems like a bug to me.
Expected Behavior
It's supposed to create a dist/ directory with the files.
To Reproduce
This bug always reproduces, so I can't even use the Verel site without it being broken.
pnpm turbo build
Reproduction Repo
No response

Hi there, this is behaving correctly. turbo does not create the outputs of your build task, the outputs configuration is to tell turbo what to cache. Turbo assumes you know where your build task will put files. If you can think of anything in the docs that is confusing or can be improved, please let us know! https://turbo.build/repo/docs/reference/configuration#outputs


User Profile Property mapping for "Work phone"  should be AAD Attribute "businessPhones"

The "Work phone" SharePoint User Profile Property is from AAD Attribute businessPhones, not telephoneNumber (which is an AD attribute).
PS it would be great if the internal names (eg. WorkPhone) of the properties were included on this page. Oh and the names of the columns in the user information list too ;)

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 54ff426d-6bba-75ea-970b-03f16fe191b5
Version Independent ID: 51db9ad2-9e46-4391-601a-062b640b00d2
Content: About user profile synchronization - SharePoint in Microsoft 365
Content Source: SharePoint/SharePointOnline/user-profile-sync.md
Service: sharepoint-online
GitHub Login: @SerdarSoysal
Microsoft Alias: serdars

Hello @fowl2 James, how are you?
telephoneNumber is the property name used by Azure AD Graph and  businessPhones is the one used by Microsoft Graph
See here for more information https://docs.microsoft.com/en-us/graph/migrate-azure-ad-graph-property-differences

Ahh could the docs be updated to be more specific about this then?
Perhaps the existing column could be renamed to specify "Azure AD Graph" and a new "Microsoft Graph" column added.


Universal Cable Not Transmitting Power At Certain Point

Waila doesn't work on the cable either but it does on the other ones

All are in one chunk space

Yeah I find it does that too if you put it on top of a redstone emitting block (say projectred gates) and then toggle off its redstone sensitivity.

Version?

Mekanism-1.7.10-<IP_ADDRESS>

I had the same odd problem on 1.7.10-<IP_ADDRESS> I think. If you hit the wire with the network reader does it say "No Network" ??
I just went through this and had to remove the wire and replace it to get it to work again. Sadly it made me replace every single wire in the line. All blocks showed "no network" via network reader prior to be replaced.
Oh and this affected item, liquid, and gas pipes too. Not all tho oddly. I got tired of fixing them so on a whim I did a server restart and they are all working again. I know that's not exactly a font of info to go from.

8.1.7 yeah.

I tried the network reader an the capacity was negative were as the others were like 1.5E9

Just saw some pipe fixes in the commits... wonder if these are in the new version? Will have to upgrade and test...

More testing... if I log out and back in that seems to fix them which lead me to think.. chunk loading.
I put down a chunk loader to cover my entire base and the problem has gone away!

@Utildayael If memory serves, the chunk loading issue was due some wierd mod interaction and was fixed in 8.1.6?

I tried logging in and out multiple time and it still didn't work, and as i said in my reporting there all in one chunk for me so i think it may be a different problem.

All within one chunk

Awesome! I'll have to test. :)

On Aug 7, 2015, at 6:42 PM, ruifung<EMAIL_ADDRESS>wrote:
@Utildayael If memory serves, the chunk loading issue was due some wierd mod interaction and was fixed in 8.1.6?
—
Reply to this email directly or view it on GitHub.


Referer header is getting dropped for API calls.

What is your Test Scenario?
The site that I'm testing makes API calls to a third party that are returning a 403 in the latest version, but works in version 1.9.4.  It turns out that the APIs are looking for the presence of a referer in the request header to be considered valid.  This is keeping me from upgrading.
What is the Current behavior?
The referer header is missing after version 1.10.1, including 1.14.2.  In my research, it appears that the referer header does not look like the hammerhead proxy url, it's the normal url, before it gets transformed by hammerhead.  This is only happening for API urls.  When it attempts to transform it, it gets dropped instead.
What is the Expected behavior?
Refer header should be present.
What is your web application and your TestCafe test code?

Your website URL (or attach your complete example):

Your complete test code (or attach your test files):

<script>
   // index.html
   function reqListener () {
       console.log(this.responseText);
   }

 var oReq = new XMLHttpRequest();
 oReq.addEventListener("load", reqListener);
 oReq.open("GET", "https://testcafe.io/");
 oReq.send();
</script>

import { RequestLogger } from 'testcafe';

const logger = RequestLogger('https://testcafe.io', {
    logRequestHeaders: true
});

fixture `When making an xhr request:`
    .page('http://localhost:8080/index.html')
    .requestHooks(logger);

test('The origin header is present.', async t => {
    await t
        .expect(logger.contains(r => r.request.headers.hasOwnProperty('origin'))).ok();
});

test('The referer header is present.', async t => {
    await t
        .expect(logger.contains(r => r.request.headers.hasOwnProperty('referer'))).ok();
});

Your complete configuration file (if any):

Your complete test report:

Running tests in:
 - Chrome 91.0.4472.77 / Windows 10

 When making an xhr request:
 √ The origin header is present.
 × The referer header is present.

   1) AssertionError: expected false to be truthy

      + expected - actual

      -false
      +undefined

      Browser: Chrome 91.0.4472.77 / Windows 10

         13 |        .expect(logger.contains(r => r.request.headers.hasOwnProperty('origin'))).ok();
         14 |});
         15 |
         16 |test('The referer header is present.', async t => {
         17 |    await t
       > 18 |        .expect(logger.contains(r =>
      r.request.headers.hasOwnProperty('referer'))).ok();
         19 |});

         at <anonymous> (D:\Projects\xxx\scripts\node\testcafe-bug\tests\referer.js:18:84)
         at asyncGeneratorStep
      (D:\Projects\xxx\scripts\node\testcafe-bug\tests\referer.js:1:250)
         at _next (D:\Projects\xxx\scripts\node\testcafe-bug\tests\referer.js:1:588)
         at <anonymous> (D:\Projects\xxx\scripts\node\testcafe-bug\tests\referer.js:1:753)
         at <anonymous> (D:\Projects\xxx\scripts\node\testcafe-bug\tests\referer.js:1:494)
         at <anonymous> (D:\Projects\xxx\scripts\node\testcafe-bug\tests\referer.js:16:5)

 1/2 failed (15s)

Screenshots:

Steps to Reproduce:

Go to my website ...
Execute this command...
See the error...

Your Environment details:

testcafe version:                   1.14.2
node.js version:                    v12.18.4
command-line arguments:  npx testcafe chrome:headless
browser name and version: Chrome 91
platform and version:          Windows 10
other:

Hi @p0rt23
Thank you for the shared example. I've reproduced the issue.

@miherlosev We're experiencing the same bug and it prevents us from updating to versions of Testcafe after 1.10.1

Hello,
Thank you for pointing this out. We need more time to investigate the issue. We'll get back to you when we have any results.

We're experiencing this same issue, using 1.14.2.

I am not 100% if this Github issue is causing instabilities and fails, but we had to downgrade TestCafe too because every e2e run had couple failed tests and couple unstable ones.
Screenshot showing BEFORE as latest TestCafe e2e test runs, and AFTER where we have downgraded TestCafe:

Nothing helpful in logs, so we assume TestCafe proxy is faulty and something is improperly altering requests.

Here someone debugged some issues all the way to http lib (https://stackoverflow.com/a/59548457/7937721). But even if it's http lib it makes TestCafe completely unstable and unpredictable. If this is the issue, maybe you should consider using different lib.

@AlexanderMoiseev  Do you have any updates on this?

+1


Link to Download Page broken

The link does not go to the Language Pack Download Page.
It should navigate to somewhere like this

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: b2f072d3-a8c3-f755-f78a-9dccebdc936a
Version Independent ID: 87c63ac2-a203-f31a-0c2a-d6af5f9c1362
Content: Install and enable a Language Pack
Content Source: ce/customerengagement/on-premises/deploy/install-and-enable-a-language-pack.md
Product: crm-2016
GitHub Login: @Mattp123
Microsoft Alias: matp

@AgileXRM - Thank you for your feedback. The link has been fixed.
Closing issue.


Uniform Sales Parameters

As a developer, I'd like for our code to be easier to read and consistent across the codebase.
The parameters for Sales items will be set as strings for consistency.

This actually did not make sense to do. It looked nice at first but then over-complicated the Sales. Don't fix it if its not broken!


Have you compared it with the official TF implementation?

Hi,
Have you compared it with the official TF implementation? Are the score significantly different? Are there pitfalls one should be about when using it that might get significantly different results than TF?
Thanks, and thank you for writing that code.

Hi,
I am actually in the process of comparing it with TF's implementation, and I will update with more info once I get around to do so.
Unfortunately, so far I have got pretty different results between this and TF's version. At the moment, I would not recommend using the results from this implementation for anything serious. I am currently digging into where the differences stem from.

Thank you for your answer :)

Could you tell me how to use the fid of tensorflow? Thank you very much！

Hey,
after some long detective work I found several sources of errors between the TF and Pytorch implementation. It turns out that the Inception model of Pytorch uses different weights and a slightly different model than Tensorflow's Inception. This introduced a significant source of error. I pushed an updated version of the model (see #16), which fixes those errors.
The model itself now computes the same results as the TF model when inputting the exact same image. There might be other sources of error (e.g. image interpolation) which could result in the FID score still being slightly different. However, I think the results should now be pretty comparable.

Thank you SO MUCH.
You're making my life so much easier with that!
Kudos to you for your excellent work!

You're welcome. Out of interest, what you are doing that is so much easier with Pytorch than Tensorflow?

You're preventing me from installing TF, which messes with my CUDA version on some of my systems and doesn't play nicely with pytorch.

I see. Yeah, CUDA and Tensorflow is a mess.


feat: Add option to add tagline to homepage title [wip]

The default homepage title now is Sitename - Sitename.
It should be Tagline - Sitename, and if no tagline is set just Sitename
Todo:

[ ] Make sure tagline is only used on homepage
[ ] Fallback to Sitename only if tagline or custom vue meta title for homepage is not set.

Any updates on this?


Identify/Describe Gardener's ability to scale in terms of seed/shoot clusters

How to categorize this issue?
/area documentation
/kind enhancement
What would you like to be added:
Could the documentation provide information about Gardener's ability to scale with some "rule of thumb" numbers? For example, a rough estimation and/or best practices for the following ranges would be very interesting:

Hoy many shoots can a single Garden cluster handle?
How many shoots can/should be placed on a seed?
How many seeds can be used in a single Gardener setup?
Are there any experiences of service regression when exceeding certain thresholds (like number of active Gardenlets, etc.)

I'd e.g. expect to find information like this on the architecture page.
Why is this needed:
I'm aware that this is also dependent on a a lot of factors not involving Gardener itself (like the used infrastructure). However, I'm trying to build a reasonable intuition about what Gardener is capable of and how it behaves at scale.
If there is already any information on this topic that I didn't find, I'm also happy about some pointers.

Creation of tens of thousand of clusters is not practical (takes too long, costs too much), so we would have to get creative here. Maybe we could write a "hollow infrastructure extension" (and "hollow machine driver") that would create "hollow clusters", much like kubemark does with "hollow nodes" to test huge landscapes with many clusters. With this, we could test Gardener and Dashboard all the way down to the gardenlet, and independent extensions like DNS and cert controller. By tweaking it we could simulate also failure rates and how the landscape reacts to those. Maybe https://github.com/localstack/localstack can help to even better mock the infrastructure and simulate a large landscape. It looks interesting also in general for other tests, MCM or Gardener.


Why create-react-native-app is stuck in vesion 1.0.0

$ npm install -g create-react-native-app
/usr/bin/create-react-native-app -> /usr/lib/node_modules/create-react-native-app/build/index.js
+<EMAIL_ADDRESS>
however in the changelog, i can see that create-react-native-app is in version 1.11.1
Why create-react-native-app is stuck in vesion 1.0.0 ?

You should only need to update the global installation of create-react-native-app very rarely, ideally never.
Updating the react-native-scripts  dependency of your app should be as simple as bumping the version number in package.json

Answer was in the readme of the app created by create-react-native-app.


Fixed mixing of outputs/inputs in JvmMidiAccess

Added coroutines-test library for midi inputs/outputs testing
Added basic test for midi inputs/outputs
Signed-off-by: Frederik Bertling<EMAIL_ADDRESS>Do you know a way to create testable midi ports during a test? I have used the always prevalent midi ports from the jdk. I can connect to the midi input ports, but cannot make them to send data that can be retrieved.

Hmm, I have to say it's not something I can come up in a bit. Considering our GitHub Actions workflow runs on Ubuntu VM and javax.sound.midi does not support virtual ports, it is not going to work. My device testing is also limited to local runs and runs only when available devices exist.
Regardless of that I'll pull in the patches that fixes handful of "oops" parts (I have to say I'm not a big fan of javax.sound.midi and it was pretty hacky). The tests look failing at my code so there's nothing to worry. Thanks!


Guide: Creating a custom form field control

Documentation Feedback
I walked through your guide "Creating a custom form field control" and wondered why you provide a getter for @Input value that is actually not used in the code.
I think that
_handleInput(): void {
    this.onChange(this.parts.value);
  }

should be changed to
_handleInput(): void {
    this.onChange(this.value);
  }

Then when getting a value the additional logic defined in @Input value would take effect when the input element is changed. Also an instance of MyTel is returned and not just an object.
Affected documentation page: https://material.angular.io/guide/creating-a-custom-form-field-control
see also https://community.indepth.dev/t/never-again-be-confused-when-implementing-controlvalueaccessor-in-angular-forms/44 for further details

@crisbeto If you want I can provide a PR with a fix.

I figure the changes would need to go here: https://github.com/angular/components/blob/3d351802ccb4469e38c4360fe31c157b2273d86e/src/components-examples/material/form-field/form-field-custom-control/form-field-custom-control-example.ts#L149-L151

@tobiasschweizer I did not author that demo, but your proposal seems reasonable. A PR would definitely be appreciated. Thanks!

A PR would definitely be appreciated. Thanks!

Ok, will do.

ok, I created #18609


[fix](jdbc catalog) fix JdbcScanNode NOT CompoundPredicate filter expr handling errors (#28497)

Proposed changes
Issue Number: close #xxx
pick from master #28497
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall


Add Dockerfile and make and Azure steps to build it

Add Dockerfile, run_java.sh and make files to build the docker image.
Update Azure pipeline to build Docker container.
Add DEV_GUIDE.md with steps for building the Docker image.

This PR does not include the steps to tag and push the docker image. Those will be added with the deployment files in a followup PR.
This PR only builds the amd64 architecture.

@scholzj that's a good point, I'll update it. At the moment the azure builds are configured to build the Java project and image but not try to push images anywhere, but they don't seem to run when a PR is raised. Does this need to be enabled from the repo settings?

@katheris You have a wrong path there: templates/jobs/build/build_container.yaml instead of templates/jobs/build_container.yaml?

@scholzj ah ok, I'll sort that. How do I get from the PR to the azure build? I was expecting it to come up under the checks

@scholzj the Azure build is passing now

How do I get from the PR to the azure build? I was expecting it to come up under the checks

When you have misconfiguration in the build like this, it does nto even start the build, so it does not report the error on the PR. You have to browse the builds to find it.


How to recieve data from a x.x.x.255 ?

i got an error showed that the x.x.x.255:port is not valid , but my udp data is broadcast to the whole network
thanks

I was able to do this using the Node project, i.e. listening on a .255 address:

However running it on the broadcast address of a local network segment, even if running as admin, will not work.
You may be able to accomplish this using IPEndPoint and UdpClient directly, though: https://stackoverflow.com/questions/746519/udpclient-receive-on-broadcast-address
If you want to submit a PR with this capability I'd happily take it :)
Cheers, Joel

thanks.  i have tested and added a pr.

Thanks @charleypeng - published!
Nuget: https://www.nuget.org/packages/SimpleUdp/1.2.1
Commit: https://github.com/jchristn/SimpleUdp/commit/06877b68c84b0264fd5265fe953d16b1ca39f1fe


[flutter_tools] use existing service implementations for web

Fixes https://github.com/flutter/flutter/issues/78987
Use the same mechanism that native flutter uses to register additional services on the web. Also remove some dead code from devtools launch removal

google testing failure is unrelated, due to the some version skew in the base CL. @zanderso maybe we should follow up separately on you quandary here?

@zanderso moved all of the future awaiting into the Future.wait method since I could reproduce an error getting thrown early....

hmm, accidentally broke another test - will take a look.


ubutun 18 make test What is the reason for failure?

The following tests FAILED:
38 - restart-scenarios-test-resync (Failed)
40 - restart-scenarios-test-none (Failed)
45 - bnet_nodeos_voting_lr_test (Failed)
Errors while running CTest
Makefile:119: recipe for target 'test' failed
make: *** [test] Error 8

The test results of these tests might be subject to machine CPU power, RAM usage, harddisk performance. Would you try to run it several times to see if you can get any positive result?

closed as no reply. Please ask in eosio.stackexchange.com if you have further questions.


Logz.io v1.4 Image not published

Error:
Back-off pulling image "fluent/fluentd-kubernetes-daemonset:v1.4-debian-logzio-1"

While looking to see if I simply misspelled the tag I noticed that the image I require is not being published:
https://hub.docker.com/r/fluent/fluentd-kubernetes-daemonset

Just built the image. We missed several images for creating new rules after docker hub incident.


release v0.2

Now that most of the wrapper methods are implemented, it might be good to release soon.
Must have:

[x] #70: unit-aware wrapper methods
[ ] #42, #43, #92: more context in error messages
[ ] #2: more introductory examples / a gallery

Nice to have:

[ ] #47
[x] #89: expose setup_registry
[ ] #91: get matplotlib.units to work with xarray's plot accessor

Feel free to edit this message if you feel something is missing.
cc @jthielen, @TomNicholas

with #92 being close (I'm going to merge it this weekend), all that's left is to increase the number of tutorials. Does anyone have ideas for that?

@jthielen, @TomNicholas, I probably won't be able to come up with an idea for a tutorial. Does anyone have any ideas? If not, should we go ahead with the release?


Add the Glacier tag to any MXF files already in the storage service

Part of #4413, follows #4403
Specifically, objects with the tag applied by the Lambda in #4488.

You know what? https://github.com/wellcomecollection/platform/issues/4550 would make this dead easy.

Done!
Well, ish. It turns out there aren't any MXF files in the storage service yet, and any added now will be tagged properly, so this is done.


Angular-cli not found file system.config.js

I use lastest version of angular-cli. And i can't find system.config.js. Please explain how i config it?

Have you followed the beginners guide at Angular2's home page: https://angular.io/docs/ts/latest/quickstart.html? They instruct you how to create your system.config.js file. And then you modify it with the instructions found on this repository.

The lastest angular-cli no have system.config.js. But i did it with a different way. tks

Hi. Sorry I haven't been around for a while. I was able to use the module with angular-cli by adding it to angular-cli.json and using the relative path for the import statement in app.module.ts instead of the SystemJS alias. I've updated the readme with the details.

it package very good, but after install it, my component will lag and slowly when type text to a input in component, and i remove it :(

I guess that might be to do with your other issue with ngFor? I will have a look to see if I can find any way of improving the performance.

i use observable, ngFor(but it just have one element in observable), and use pipe to bind trust html(my content include all code highlight in observable or normal text, if i have multi statement(>2) code tag, it will slowly and lag). I use service to show highlight auto.
Waiting for you fix it :)

Maybe this is related to #4?


Grammar to Java Generator

input:grammar -> parser produces cst -> cst is transformed to ast -> compiler produces Java

out of focus for Javaslang


merge package from arlac77/npm-package-template

package.json

chore(package<EMAIL_ADDRESS>chore(scripts): cover@#overwrite c8 --temp-directory build/coverage ava && c8 report -r lcov --temp-directory build/coverage
chore(package): add nyc from template
docs(package): remove keyword null
chore(package): set $.ava.require='esm' as in template
chore(package): set $.ava.files='tests/-test.js,tests/-test.mjs' as in template
chore(package): set $.ava.extensions='js,mjs' as in template

Codecov Report

Merging #637 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #637   +/-   ##
=======================================
  Coverage   92.63%   92.63%
=======================================
  Files           7        7
  Lines        1073     1073
=======================================
  Hits          994      994
  Misses         79       79

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4b39ce4...b698f21. Read the comment docs.

Coverage remained the same at 89.502% when pulling b698f210e0ac82b14dbf6c79d5cbab0b25f6b3b1 on template-sync-1 into 4b39ce4cd720ca88ca6558f242e11d1d45a24deb on master.

:tada: This PR is included in version 5.0.0 :tada:
The release is available on:

npm package (@latest dist-tag)
GitHub release

Your semantic-release bot :package::rocket:


[Autocomplete] Some WAI-ARIA attributes are incorrect

[x] The issue is present in the latest release.
[x] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯
The attributes aria-activedescendant and aria-controls do not fully conform with the WAI-ARIA design pattern (https://www.w3.org/TR/wai-aria-practices/#combobox)

The aria-controls attribute on the <input> is set to the listbox id from the beginning, even when the listbox is not present in the DOM
When the combobox is closed, the aria-activedescendant attribute on the <input> is still set to the id of the last focused option in the listbox

There are two errors in react-axe caused by this:

ARIA attributes must conform to valid values (2 instances)

I'm a little bit unclear on the the actual user impact. But any divergence from the design pattern increases the risk for screen reader bugs.

Expected Behavior 🤔
The attributes should work the same as in the WAI-ARIA design pattern (https://www.w3.org/TR/wai-aria-practices/#combobox):

aria-controls should only exist when the listbox is present in the DOM. Remove the attribute from the input whenever the listbox itself is removed.
aria-activedescendant should only be set when the user is actively navigating in the listbox. When closing the listbox, the aria-activedescendant value should be cleared.

Steps to Reproduce 🕹

Steps:

Install aXe plugin for Chrome
Open https://codesandbox.io/s/dnc5t
Run aXe
Look for error "ARIA attributes must conform to valid values"

Your Environment 🌎

Tech
Version

Material-UI Core
v4.5.2

Material-UI Labs
v4.0.0-alpha.30

React
16.11.0

aria-controls should only exist when the listbox is present in the DOM. Remove the attribute from the input whenever the listbox itself is removed.

Is this actually an issue with assistive technology or is this just warning for authors that this has no effect? Since the markup is rendered by another library (Material-UI) I don't consider this an important issue.

@eps1lon
I'm not aware of any adverse effects for assistive technologies related to faulty aria-controls values. IIRC, it is only JAWS that support aria-controls at all. Other screen readers simply ignore it. So I think it's fair to consider this low priority.
aria-activedescendant might be worse though.

Yeah I'm currently writing the tests and have already addressed this issue. I think I'll open this. No need to merge all tests at once.

These issues should be fixed with #18142. @fymmot<EMAIL_ADDRESS>should no longer have issues.


Timeline speed adjustment

It would be a nice addition to be able to adjust the playback speed when replaying log files.

This is actually supported already. Just right-click the play/pause button to open the menu.


Fix snippet tabstops

Thanks a lot for the nice changes to snippets! I've incorporated your changes and published an updated version of the extension to the VSCode Marketplace. Sorry for taking so long, but I try to work on this in whatever spare time I can find.


~rssroles doesnt work

[]http://light-theme-hurts.my-ey.es/7M4Nj7m.png

The command is now rssmention. Please read the changelogs https://github.com/synzen/Discord.RSS/releases to stay informed of any changes when updating, and see https://github.com/synzen/Discord.RSS/wiki/Discord-Commands for a list of commands.


Update to 2.2 for OpenSSL 1.1, include openssl, & rerender

Checklist

[x] Used a fork of the feedstock to propose changes
[x] Bumped the build number (if the version is unchanged)
[x] Reset the build number to 0 (if the version changed)
[x] Re-rendered with the latest conda-smithy (Use the phrase @conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
[x] Ensured the license file is being packaged.

Update to QCA 2.2, which includes updates to work with OpenSSL 1.1. Rerendered, but manually edited to pin 5.6 so we can get a build out for that before updating to Qt 5.9.

Hi! This is the friendly automated conda-forge-linting service.
I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

This is covered in #11


feat: add notification controls

Summary
Add showNotificationControls prop to Android & iOS
Motivation
Allow to control video from notification controls
Test plan

[x] Tested locally
[x] CI passes

Speaking for android: why do you use custom Notifications with custom actions instead of using the standard MediaSessionCompat and MediaSessionConnector? Those two classes create system's media notifications and listen to hardware volume/media buttons (like headphones or remotes) and assistant on TV.

I want in feature to allow set custom actions

👀 thanks for info, will check out this

@zoriya seems like MediaSessionConnector from exoplayer is deprecated in favour of MediaSession from media3

I will check if with current implementation, tv pilots will work (I will test it via adb)

Yes, I tried to use MediaSession from media3 in the draft PR. Is there a reason we can't use it?

We don't have exoplayer2 any more as we migrated to media3

I have tested and with current implementation we support key events like 126, 85 so I guess with this TV should be supported ?

Yes, since everything was migrated to media3 I don't see why we can't simply use: androidx.media3:media3-session:$media3_version

We are using it
https://github.com/react-native-video/react-native-video/blob/edbb3b60aab0085ccd047f69bd04e7898a0b62a1/android/build.gradle#L226-L229
And I am using MediaSession from androidx.media3:media3-session (you can look into imports) as MediaSessionConnector is no longer available in media3

Okay, I'm sorry I was referring to outdated docs. I got the right one now.
I don't understand why you create a notification manually. media3's session support notifications out of the box: https://developer.android.com/media/media3/session/background-playback#notification

@freeboub I don't see a way to dynamically update metadata... for now I am using player.replaceMediaItem but this resets video. I also have tried to update notification content when setting metadata but "content" is lost when you do any action (like pause, seek)

@freeboub I don't see a way to dynamically update metadata... for now I am using player.replaceMediaItem but this resets video. I also have tried to update notification content when setting metadata but "content" is lost when you do any action (like pause, seek)

Ok, thank you for double checking !

So I guess in this case will be better to move prop metadata to source ?

So I guess in this case will be better to move prop metadata to source ? or should I leave it outside

🤔 It should be in source then... As you will need it at playback startup it fully make sense to put it in the source !

I don't understand why you create a notification manually. media3's session support notifications out of the box

When I was using those out of the box, there could be only 1 "notification" even with there was more then 1 player - with custom notification each player can have separate "notification"
cc @zoriya

@freeboub just to let you know - all the time I was testing on physic device (iOS)

@KrzysztofMoch the PR: https://github.com/TheWidlarzGroup/react-native-video/pull/5/files

@freeboub just to let you know - all the time I was testing on physic device (iOS)

can you test on simulator for my curiosity please ?

@Duell10111 ping for you as I am made breaking change for your code for custom metadata. I moved propreties for user metadata from source to source.metadata to make it more readable

@freeboub issue with "metadata reset changing source" should be fixed now (now I am disabling notification controls for player with "no media item" (mostly invalid url/source no view etc.)

I have tested iOS simulator and it does not support "NowPlayingInfo" notification so I added to docs info that fot iOS you need to run on real device

@KrzysztofMoch
#3723 is awesome! however, prop name seems narrow in scope compared to the actual functionality.
MediaSession is not only about controlling notifications and showing metadata about the video, but it's also about synchronizing processing for external controls (airplay, car, air pod, remote controller etc..).
But it's hard to tell from the prop name if it covers this functionality.

@YangJonghun you right, I had not better idea then - we can add this information to docs maybe ?

@YangJonghun you right, I had not better idea then - we can add this information to docs maybe ?

I agree it is a good idea!

Custom notifications require editing the AndroidManifest.xml (as stated in the readme), would it be possible to include those changes on the repository, so expo could automatically apply them? Should I make a new issue to track that?

@zoriya Your request make sens, but I am 100% sure if need, can you please open a ticket or discussion to discuss about it with @KrzysztofMoch ?

That's true, it will always request for permissions. I'm not sure if media notifications is a permission that require user consent or if it is automatically granted.
I think this should be opt-out more than opt-in tho, as users, we expect to be able to control media using media buttons.

@KrzysztofMoch @freeboub @zoriya
I think we can make people choose changeable opt-in.
some of the Player's features require permissions, services, and activities.

service & FOREGROUND_SERVICE(permission) : download, media session, google cast ...
activity : picture in picture ...

Currently, If someone need these features, they have to write within their AndroidManifest.xml. because Android doesn't support programmatically generate Service or Activity
But, If we write each feature as native Android dependency, people can choose and install with native flag like below
    if (ExoplayerDependencies["useExoplayerPIP"]) {
      // For PictureInPIcture support with react-native-video
      implementation "com.brentvatne.react-native-video:$rnv_version"
    }

(As far as I know, react-native-notifee's app.notifee.core takes that approach, which allows it to get around some of the limitations of RN library.)
fyi) if we choose this approach, #3385 can be rewrite with Activity.

@freeboub
I don't care about the size of the package, I want the library to support users to specify only the permissions for the features they actually use (because Play Store has strict permission checks for background behavior).
There are two ways to do this: opt-in and opt-out, and currently we choose opt-out, where users specify the permissions and services they need in their code to use certain features.
My hypothesis is that react-native-video supports opt-in to improve library user's DX. If it's a regular React-Native library, not a native dependency, you can't specify the service, activity, permission, etc. required for the feature separately.

@YangJonghun You may not but other developers are care about package size

As someone said and remove his comment: "You may not but other developers are care about package size"
That is not the main topic for now :)
Regarding to optin vs optout, I think you choose the good strategy to avoid changing default behavior of the package !
Regarding to the 2 new permissions, I don't think they change anything for store submission even if the feature is not used ? What's why I wonder if we can add it to the AndroidManifest from the package.

Recently, Google Play Console has been requiring proof of app content actually using Foreground Service, so if someone not using it and only have the permission added, this could be a reason for rejection.

@YangJonghun Thank you for the information ! So I think we should keep implementation as is !

@KrzysztofMoch
When the playInBackground prop is false, I was expecting the notification control to exit as well, but currently it doesn't behave that way. Is there any plans to change it?

On iOS or Android ?

@KrzysztofMoch
I tested on Android

@KrzysztofMoch When the playInBackground prop is false, I was expecting the notification control to exit as well, but currently it doesn't behave that way. Is there any plans to change it?

I think it makes sense - will try to care of it next week


multilingual Stocktake actions

PR for #1438

[x] tests?
[x] use right translations in UI
[x] how to keep old translations around for backwards-compatibility

Default fallback when no translation available: English! Gets quite difficult to maintain otherwise - with vastly decreasing returns.

@matmair I would suggest putting this one on hold for a little while. I am currently looking into how to remove the StockItemTracking model completely, in favor of a more robust "stock item history tracking" approach - see https://github.com/inventree/InvenTree/issues/1303
So this PR would conflict with that change a lot!
The same goes for - https://github.com/inventree/InvenTree/pull/1482
I'm keen to address both these issues but not until the stock history tracking framework is refactored.

@SchrodingersGat the functionality is done already, it just needs a bit of polishing / testing.
I have had bad experiences with rollbacks in django-simple-history in other projects before but maybe I can learn from your implementation.

@matmair I have not settled on django-simple-history yet, if there's some issues you have come across I'd be interested to know!

I have posted my thoughts to #1303 as it seems that that is the issue regarding the implementation.


As a tutor, I can view the summary statistics

...keep track of the total number of students I have.

Currently (MVP) the popout box is this small tiny cutey little thingy.


chore: miscellaneous refactoring of barretenberg_structures

I've removed some unused methods, derived default rather than defining it in terms of new() and replaced the usage of Scalar renaming of FieldElement.

've removed some unused methods, derived default rather than defining it in terms of new()

These switches I support merging

I like the separation of Scalar and FieldElement as we use field element everywhere as it is our base field. Scalar differentiates that this field element has to be used as part of the witness, not anywhere else

Using as doesn't actually limit where you can use Scalar because Rust will accept a FieldElement. If you want this functionality, we need to introduce a newtype.


Improve text in English

Fix some typos, use correct form of verbs, and so on

Many thanks for checking the text!


x/sys/windows/registry: way to get ACL

Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (go version)?
Go 1.10.3
Does this issue reproduce with the latest release?
What operating system and processor architecture are you using (go env)?
GOHOSTARCH=amd64
GOHOSTOS=windows
What did you do?
Using registry package to access the registry keys, values and their ACLs
If possible, provide a recipe for reproducing the error.
A complete runnable program is good.
A link on play.golang.org is best.
What did you expect to see?
NA
What did you see instead?
NA

I'm not sure but I think this is a feature request for golang.org/x/sys/windows/registry: provide some way to find the ACL of a key.  I don't know if that is meaningful or not.  If I'm wrong, please clarify.

Yes, I am checking if there is/or isn't an equivalent of RegGetKeySecurity function in golang that retrieves the security descriptor protecting the specified open registry key.

If this is a wanted feature I can give it a look, seems like adding the winapi deceleration to sys/windows/registry/syscall.go, and adding GetACL and SetACL methods to sys/windows/registry/key.go

adding GetACL and SetACL methods to sys/windows/registry/key.go

I don't see how adding just 2 new methods will do here. What API addition did you have in mind?
Alex


ls: exit code 2 when IOError happened for argument

Save if an IOError happened to a file/directory that was specified in the command line as an argument. Make exit code equal to 2 in this case.
Add exit code checking for some ls tests

$ info ls:
   Exit status:

     0 success
     1 minor problems  (e.g., failure to access a file or directory not
       specified as a command line argument.  This happens when listing a
       directory in which entries are actively being removed or renamed.)
     2 serious trouble (e.g., memory exhausted, invalid option, failure
       to access a file or directory specified as a command line argument
       or a directory loop)

GNU tests:

tests/ls/dangle
tests/ls/follow-slink
tests/mv/no-target-dir
are expected to succeed after this change.

Ok, quick-xml yanked some of its versions, hope grcov releases new version soon https://github.com/mozilla/grcov/pull/880

Let me ping them, I know @calixteman and @marco-c


Transifex sync (29 Nov 2022)

@ldodds nothing to pull down from transifex yet but this updates the config to include consents and onboarding yaml's


Removed deprecated future imports

Relevant JIRA issue here.

Coverage remained the same at 100.0% when pulling db211baf14b7d59e32ceb7eeec1e9664dcf520ee on 2to3 into 26e23e7e57f134c3a2ca5150e83cc7c608da44b5 on master.


Add missing MenuItem disabled prop

SUI core CSS supports disabled menu items, however, they do not give a disabled menu item example, therefore, our port of this component did not include the disabled prop.
We should add a boolean disabled prop to the MenuItem:
<Menu.Item disabled />
// =>

We should also then add an example to the doc site.  This would go under States for the Menu, as indicated by the core CSS file heading comment.

Fixed in #1366


input type email not supported. why?

Hello. I have a problem then i try add email alias on input with type "email". Stack trace:
app.js:1284 Uncaught TypeError: el.inputmask._valueSet is not a function
    at Inputmask.maskScope (app.js:1284)
    at Inputmask.remove (app.js:1445)
    at HTMLInputElement.<anonymous> (app.js:1425)
    at Function.each (jquery.js:365)
    at Inputmask.mask (app.js:1421)
    at HTMLInputElement.<anonymous> (app.js:1728)
    at Function.each (jquery.js:365)
    at jQuery.fn.init.each (jquery.js:137)
    at jQuery.fn.init.$.fn.inputmask.$.fn.inputmask (app.js:1727)
    at HTMLDocument.<anonymous> (registrationcreate:549)

+1, adding a JSFiddle to demonstrate the issue : fiddle

@airetnes , @cyrilmesvayn ,
See https://html.spec.whatwg.org/multipage/forms.html#do-not-apply
It is not possible to position the caret with input type=email


treewide: decomissionate urandom

Since urandom is inactive.
Description of changes

Things done

Built on platform(s)

[ ] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)

[ ] sandbox = relaxed
[ ] sandbox = true

[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

Add a :+1: reaction to pull requests you find important.

🤡

Funny, "inactive": https://github.com/NixOS/nixpkgs/blob/94930d463b3c7b50eb6a6a8a25089759a8431f59/maintainers/maintainer-list.nix#L21464-L21471
https://github.com/NixOS/nixpkgs/pulls?q=is%3Apr+is%3Aopen+involves%3Aurandom2

How in the world did you manage to try to "decomissionate" someone who made a PR two days ago?

Apologies.

@AndersonTorres this level of carelessness is not what I'm expecting to see, when approaching an issue where we as a community essentially say to a person: "We don't need you any more, you can go"

You created an issue without linking to any related conversations, and when this is pointed out to you along with a suggestion for a connecting RFC, your response is essentially "eh, different thing" without clarifying any connex or difference and how such difference would affect your judgement (and AFAICT, all of this so far is based on your judgement alone)
When your (duplicate?) issue failed to attract much engagement, you just went ahead and created a bunch of PRs for kicking people out, in which you don't even link back to your new issue (from the perspective of a maintainer targeted such, that must feel very discouraging and willful)
Where the discussions around RFC55 seem to be very mindful around the human side of such a push, worry about how to make it clear to people that they'd be welcome back in the future, even going so far as to create a "retired" team. You seem mostly oblivious even putting a "thank you for your service" just as an oh-btw - afterthought.
Why are we even focussing on kicking out maintainers? I can get committers, since those are security-relevant. But the only downside of an inactive maintainer, is that they might not respond to pings at a given time of the year. I would argue that your effort to "clean up" here is actively harming the community, because even an inactive maintainer may contribute their knowledge at times, or somebody may have luck contacting them when dealing with an especially tricky situation.

I have been less active in nixpkgs at times and I can tell you for sure that I'd have been greatly offended if I woke up to some rando removing me from my packages and the organization, without even proper community backing.
I understand if there is a language barrier when trying to communicate effectively, but this is not a simple technical issue, where we can easily fix stuff afterwards, or play around with changes.
Therefore, in an abundance of caution, I'll close down your other related PRs for the time being and I'll ask you to work in a more consensus - oriented fashion, if you feel you have to question people's roles with the project in the future.

@superherointj since you seem to disagree with closing down the PRs where approval by the targeted maintainers had been given, would you mind sketching out what benefit you see in removing maintainers?

would you mind sketching out what benefit you see in removing maintainers at all?

Users ask maintainers for reviews and wait long for reviews that never materialize.
Committers have to wait for package maintainers to answer for a week even which delays merging PRs.
It's best to know no one is taking care of a package. On breakage, instead of forever spending build resources, the package should be removed, since no one cares about it.

Let me reply a few of those points that I think it is relevant considering I merged some of those cleaning up PRs.

* Where the discussions around RFC55 seem to be very mindful around the human side of such a push, worry about how to make it clear to people that they'd be welcome back in the future, even going so far as to create a "retired" team. You seem mostly oblivious even putting a "thank you for your service" just as an oh-btw - afterthought.

Yes, +1 for being grateful for those that did some job in nixpkgs. But I think we also need to keep in mind that @AndersonTorres is a human like any other, and putting pressure on they without further discussion (and closing their PRs preemptively, again, without at least some discussion) is not the kind of reply I expected from someone that is against the idea.

* Why are we even focussing on kicking out maintainers? I can get committers, since those are security-relevant. But the only downside of an inactive maintainer, is that they might not respond to pings at a given time of the year. I would argue that your effort to "clean up" here is actively harming the community, because even an inactive maintainer may contribute their knowledge at times, or somebody may have luck contacting them when dealing with an especially tricky situation.

There are a few downsides of an inactive maintainer that I can think:

They have moderation powers inside the nixpkgs repository. Yes, this means they can't merge code per see, but I wouldn't say there is zero risk of keeping maintainers account indefinitely
This also makes the process of reviewing and merging PRs more difficult. It is really difficult to merge a bump PR since you never know if the maintainers are active or not. Some maintainers get really aggressive when you merge something without their blessing (not going to expose anyone here, but if you want examples ask me in Matrix or somewhere else), so knowing that "everyone that is maintainer in this package is actually active" would be useful

Also, I disagree about the part of "actively harming community". If the member ever wants their maintainer bit back, they can be re-added. Again, I agree that maybe this should be more clear, probably putting a message in the PR making it clear, e.g.: "if you ever want to come back @someone, just open another PR and feel free to link this issue, and your maintainer rights should be restored ASAP".

I have been less active in nixpkgs at times and I can tell you for sure that I'd have been greatly offended if I woke up to some rando removing me from my packages and the organization, without even proper community backing.

I think this is mostly a communication problem. We definitely need to have a guideline on how to do those kind of clean-ups, but I still think, IMO, we should have them often.

@AndersonTorres this level of carelessness is not what I'm expecting to see, when approaching an issue where we as a community essentially say to a person: "We don't need you any more, you can go"

This is neither the intention nor the message those pull requests are passing.
This is a practical issue: there are maintainers not interacting with Nixpkgs in a long span of time.
The most immediate effect is that it brings a misleading impression that some packages are being maintained and care by someone when they are not.

You created an issue without linking to any related conversations, and when this is pointed out to you along with a suggestion for a connecting RFC, your response is essentially "eh, different thing" without clarifying any connex or difference and how such difference would affect your judgement

The issue pointed by emilylange deals mostly with commit status.
Albeit being related with the issue I opened, they deal with different scopes (even because commit privileges floating around bring some security challenges), and they can run mostly in parallel.
I gave a terse and direct answer to emilylange, not because I dismissed his information as not important, but because it was orthogonal.
I did not feel the necessity of over-explaining this orthogonality.

(and AFAICT, all of this so far is based on your judgement alone)

As I said above, it is a practical issue: maintainers not interacting with the codebase in a long span of time.

When your (duplicate?)

As I said above, not duplicate but orthogonal.

issue failed to attract much engagement,

I disagree on both accounts:

the issue attracted a non-negligible amount of engagement
an issue does not necessarily need to attract a critical-mass amount of engagement in order to be worked out

However, I will not elaborate here - since I will close the main issue.

you just went ahead and created a bunch of PRs for kicking people out,

My intention is not a violent kick as your wording is suggesting here.
Again, it is working about the practical issue of packages being maintained in name only.

in which you don't even link back to your new issue (from the perspective of a maintainer targeted such, that must feel very discouraging and willful)

This was a failure from my part.
In order to not generate a flood of pings, I did not past the link in the commit message.
Usually I put them in a reply, via web interface.
However I was careless in recent PRs by not doing this upfront.
Apologies for this.

Where the discussions around RFC55 seem to be very mindful around the human side of such a push, worry about how to make it clear to people that they'd be welcome back in the future, even going so far as to create a "retired" team.

To be honest, I never thought this is necessary. To me, in Nixpkgs anyone is welcome by default.
Nixpkgs is a very rare case of a warm, welcoming community, with a low barrier of participation - I dare to say, a very open doors policy.
People do not need to do more than sending a PR in order to contribute - and we even provide a mail thread when people can contribute with patches.

You seem mostly oblivious even putting a "thank you for your service" just as an oh-btw - afterthought.

I did this in some cases when the person answered the PR, not as an afterthought but as a sincere acknowledgement.
Apologies for my terseness.

But the only downside of an inactive maintainer, is that they might not respond to pings at a given time of the year. I would argue that your effort to "clean up" here is actively harming the community, because even an inactive maintainer may contribute their knowledge at times, or somebody may have luck contacting them when dealing with an especially tricky situation.

As I said before, despite recent events, Nixpkgs is very welcoming.
Any of these retired maintainers are fully free to contribute, and they do not even need an entry in maintainers-list.nix to contribute.
Therefore, the cleanup is still useful.
Since I will not disagree with your final paragraphs, I will not pursue this further.

Oh I almost forgot this:

I can get committers, since those are security-relevant.

Maintainers are also security-relevant. A maintainer is formally invited to the team, having some mild moderation powers.
What if some of these maintainer accounts that did not touch Nixpkgs in years was hacked and started deleting a truckload of open PRs? I think it would be a non-negligible security concern.

Especifically for @urandom2
I made an error of judgement by overlooking your most recent commit in my local Nixpkgs repo.
My sincere apologies for not being careful.

Why are we even focussing on kicking out maintainers?

Can I ask honest ask the reason why we are focusing in keeping inactive maintainers? From what I understand (and I may be wrong), meta.maintainers were created as a mechanism so folks can be involved in the process of maintaining packages (e.g.: bumping, testing, fixing issues, etc.) without needing for us to give unnecessary commiter access to everyone (since this would reduce security).
However, by keeping inactive maintainers, we can't rely in this mechanism anymore since there is no guarantee that pinging a maintainer will get an answer.
It does seem to me that we are relying in maintainers right now mostly as a "reward" for those that ever had a contribution to nixpkgs. So if you ever get to the point that you can open a PR, congratulations, you can add your name to maintainers-list.nix and have your name there forever. At least this is the impression I get if we commit to never remove a maintainer, because if we keep creeping up inactive maintainers, eventually nobody will bother trying to ping maintainers anymore, since most of the time the person will be inactive.

this level of carelessness is not what I'm expecting to see

Here is one example that the even the maintainer concur that they're inactive: https://github.com/NixOS/nixpkgs/pull/330232#pullrequestreview-2202454694 (not sure @bendlas you decided to ping the maintainer again in this instance).
You can see that even sometimes the maintainer themselves concur that they should be removed. Maybe they don't want to bother to open a PR (this is clearly the case here) or even answer the topic because they don't remember their password account/lost access to e-mail for example. But I still think we should be removing those cases.
Again, if they ever want to come back, they should feel free to do so.

REMARK I mixed quotes from different people in this reply, please don't nail me to it. I tried to keep each answer self-contained.

Can I ask honest ask the reason why we are focusing in keeping inactive maintainers?

I already gave one reason: even an inactive maintainer may contribute their knowledge at times, or somebody may have luck contacting them when dealing with an especially tricky situation.
Another one is, that being in maintainers-list.nix will be a point of pride for anybody who made it in there and make it much easier to activate them again in the future.

Maintainers are also security-relevant.

A fair enough point. Also a few other good points, all around. And yet, a PR for removing somebody is still not the place for making them.

where we as a community essentially say to a person: "We don't need you any more, you can go"

This is neither the intention nor the message those pull requests are passing.

It is at least part of the message, though. No matter how much legitimacy the process has (which in this case it didn't), that message will always be part of the mix. Which is why I want us as a community to deal with this with matters like this in the most mindful and empathetic way possible.

I did not feel the necessity of over-explaining this orthogonality.

Even when looking at everything I could find (let alone just looking at this PR) I didn't feel at risk of being over-explained to. In fact, I would have wished for some reasoning (e.g. many of the arguments now made in these comments). Was there a link to an RFC that I might have missed?

When your (duplicate?)

As I said above, not duplicate but orthogonal

Not fully orthogonal either: There may be many differences between contributors and maintainers, but a few similarities remain:

there are people that these roles refer to
who we ask to provide resources to the community as part of fulfilling their roles
who take pride in having fulfilled their roles and will take pride if fulfilling their roles in the future

We need to be aware of this dimension when asking people to step out!

(and AFAICT, all of this so far is based on your judgement alone)

As I said above, it is a practical issue: maintainers not interacting with the codebase in a long span of time.

I can empathize with getting frustrated over the RFC not moving forward and wanting to take matters into your own hand. However, there is a reason that people felt the need to do an RFC around an issue very similar to this: This is not about just another list in source code: This is about just another list in source code with human names on it.
Why not at (the very) least publish the method  that you use for selecting the people that you want to take off the list?

this level of carelessness is not what I'm expecting to see

Here is one example that the even the maintainer concur that they're inactive: #330232 (review) (not sure @bendlas you decided to ping the maintainer again in this instance).

I appreciate your use of irony. I'll repeat my explaination from one of the closed PRs here: Any reasonably polite person would say "sure, count me out". The fact that this was never properly discussed or decided, invalidates the whole process.
In essence, I was trying to make a point of inviting people back in, when they might have felt pressured to agree without due process.

putting pressure on they without further discussion (and closing their PRs preemptively, again, without at least some discussion) is not the kind of reply I expected from someone that is against the idea.

Again, appreciate the irony. And again I did what I did in attempt to undo some of the damage I saw in front of me and to take the opportunity to make it into an invitation to contribute again.

As I said before, despite recent events, Nixpkgs is very welcoming.

I'd argue that asking people to leave in such a careless way, is making it less so.

Therefore, the cleanup is still useful.

See, here is something I'm honestly not getting: If we deem it necessary to tidy up. Why not go the extra mile to make sure that people know what is what, when they are removed from a list? Why go with bland statements like Since xxxx is inactive. (or not even that), while leaving a default PR template in? Why not at least type out a standard text block, thanking people, telling them that they're welcome back any time, referring to a well-reasoned issue (which https://github.com/NixOS/nixpkgs/issues/290642 is not, even if you do "not feel the necessity of over-explaining"), maybe even taking the time to list their contributions?
Also about the usefulness of this cleanup: In https://github.com/NixOS/nixpkgs/issues/290642#issue-2149275657, you state They should be listed, formally retired and their packages put to adoption.. OK. Has this work been done as part of the PRs?
Here https://github.com/NixOS/nixpkgs/issues/290642#issuecomment-2105397276 you state

~I am cogitating another idea: mark them as inactive at maintainer-list.~ Abandoned idea.

 Because that's What I would have suggested.
I imagine an active flag on a maintainer would actually be very useful:

it would encourage them to start contributing again, to get that active back, instead of alienating them by erasing their contribution mark
it would allow a bot to post something like It seems you pinged XXXX, who has unfortunately been inactive lately, please consider finding more eyes to look at this. This issue/PR has also been automatically escalated to the nixpkgs adoption agency. Thank you for your patience
we could still take away their moderation powers, while they're not active, while keeping the recognition for as long as we keep the package

There would be more to respond to, but I'll stop now. I hope that my stance is clear: I'm not against cleaning up our maintainers list, per se. But I would like us to at least leave an appropriate paper trail, when having to do the open-source equivalent of HR, and better yet, actually take the human element into consideration -- which we can do precisely because we're not about money.

@bendlas Since you have consensus, proceed as you wish.

@bendlas Feel free to proceed as you wish. I'm done with nixpkgs.

It is at least part of the message, though.

The "kick as a putrid corpse" spin you are conveying here - it is not.

Another one is, that being in maintainers-list.nix will be a point of pride for anybody who made it in there and make it much easier to activate them again in the future.

I am was not interested on deleting entries on maintainers-list.nix.
As I said, the issue is around packages maintained in name only.

I can empathize with getting frustrated over the RFC not moving forward

Since we are talking about barriers of communication here, I dare to disagree.
RFCs are reserved for structural changes - as explained in the README, section When this process is followed.
Orphaning packages is arguably not a structural change in Nixpkgs.
On the other hand, not a long time ago, in a heated discussion I suggested that adding meta.repository  should be the subject of an RFC.
Among other arguments, it was dismissed because RFCs are slow and tiresome and frustrating.
(And I can't censor them - from what I found around, this is a general feeling that is brought about time after time.)
Well, the code adding meta.repo was merged. Maybe RFC process was unneeded after all...
Oh! A couple of weeks later it was reverted because it caused a bug that broke evaluation of some closed-source binary-only packages.
Who would have thought...

Why not at (the very) least publish the method that you use for selecting the people that you want to take off the list?

I was initially polishing some ideas for a shell script, but it was basically filtering people with commits older than a threshold, like 12 or 18 months. This can be done in a local checkout of code.
After that, some filtering on GitHub API would be useful to clean up, but it would require extra code for dealing with anti-flood measures...

Why not at least type out a standard text block, thanking people, telling them that they're welcome back any time

It would be a nice idea!

Has this work been done as part of the PRs?

Some packages were adopted while I did some cleanups.
An issue about adopting critical packages was opened too: https://github.com/NixOS/nixpkgs/issues/327779

Have you written out this deliberation of yours somewhere? Because that's What I would have suggested.

Feel free to suggest it again: https://github.com/NixOS/nixpkgs/pull/310759

The problem I see in nixpkgs:

thiagokokada, 2275 reviews merged
AndersonTorres, 2055 reviews merged
superherointj, 1569 reviews merged
bendlas, 75 reviews merged

There are things you can only understand with experience. There is a reason the active reviewers/commiters want to get rid of inactive maintainers. It doesn't help.
While then, good luck pleasing your inactive maintainers.
Anyway, I'm out of this madness. Good work!

The problem I see in nixpkgs:

thiagokokada, 2275 reviews merged
AndersonTorres, 2055 reviews merged
superherointj, 1569 reviews merged
bendlas, 75 reviews merged

There are things you can only understand with experience. There is a reason the active reviewers/commiters want to get rid of inactive maintainers. It doesn't help!
Since you claim there isn't consensus in favor of removing INACTIVE maintainers. And I'm quite tired of nixpkgs by now. I'm out of this madness. Good luck pleasing your inactive maintainers.
Feel free to review my PR removing myself. Since we disagree about direction of things. And I'm honestly too tired for everything negative comings from nixpkgs. The amount of negativity I receive from here is surreal. Also, this is not your fault. It is just that I don't want to continuously live sudden crisis that require having to debate everything until exhausting for bad reasons. Or be blamed for anything. My reasons. No worry. I'm not merging anymore PRs. Peace.

It is at least part of the message, though.

The "kick as a putrid corpse" spin you are conveying here - it is not.

I know it's not meant as such. It's still a credible emotional worst-case scenario for somebody on the receiving end.
And the more I think about it, the more I actually do find the erase the contribution mark while keeping the fruits of labour - angle kind of disgusting, even while I know that the maintainers field is not for contribution marks.

Another one is, that being in maintainers-list.nix will be a point of pride for anybody who made it in there and make it much easier to activate them again in the future.

I ~am~ was not interested on deleting entries on maintainers-list.nix. As I said, the issue is around packages maintained in name only.

See, even this in name only selection, that I keep seeing, strikes me unnecessary (borderline toxic, in fact). We aren't interested if somebody got a cheap github credential through a small nixos contribution (in fact, more power to them).
We are interested in whether we can expect somebody to react to issues and PRs that they might be pinged into. Or if it's time to start advertising an open maintainership for a package, to the users of that package (which is, btw, a much gentler way to find new maintainers, than to delete stuff out from under them).
And even if we end up deleting packages: Isn't the information who used to maintain them, valuable until the very last second?

I can empathize with getting frustrated over the RFC not moving forward

Since we are talking about barriers of communication here, I dare to disagree.

If your point is that I could have stepped into the RFC process at any point: Touché!

RFCs are reserved for structural changes - as explained in the README, section When this process is followed. Orphaning packages is arguably not a structural change in Nixpkgs.

Establishing a process for phasing out software and people from the organization arguably is, though. And by getting started on removal PRs, you did exactly that.
Look, I'm not even about the RFC, necessarily. What I am about is treating people with dignity (yes, kill me for the irony). And when dealing with human names on lists, it is imperative that we operate transparently, even-handedly, and with explicit intent. People can easily get touchy about group memberships, believe it or not. Tons of subtext involved.
And saying goodbye is always hard, even if it has been a few years. Whole documentation pages have been written and subsequently ignored for much less.

Why not at (the very) least publish the method that you use for selecting the people that you want to take off the list?

I was initially polishing some ideas for a shell script, but it was basically filtering people with commits older than a threshold, like 12 or 18 months. This can be done in a local checkout of code. After that, some filtering on GitHub API would be useful to clean up, but it would require extra code for dealing with anti-flood measures...

Yeah, but like .... how did you do it? Or rather: Do you agree that it's important to let people know how they were selected for removal? Even if it's just an english sentence of the criteria you used?
Can you imagine how the criteria that are being communicated at that point, are the criteria that the person will seek to fulfill in case they want to be let back in? And so if their criterium was somebody named Charlie opening up a removal PR without further elaboration, how they could easily see no choice other than to go to Charlie personally and beg him to let them have their maintainership back?

Some packages were adopted while I did some cleanups. An issue about adopting critical packages was opened too: #327779

OK, good to know they weren't just abandoned. This information would btw also be nice to pass to someone, who's being replaced as a maintainer for a package: Who is stepping up for it.

Feel free to suggest it again: #310759

You know what? I will!

While clearly there is nuance to how to go about dealing with inactive maintainers, and obviously this PR was totally incorrect, I think there is no rational reason to keep maintainers around when they have signalled agreement with their removal. Maintainers are allowed to remove themselves! I don’t think @bendlas’s unilateral closures of PRs where the inactive maintainers approved them were at all appropriate and I hope those PRs can be revived.
We have an opt‐in eval warning for unmaintained packages for a reason. We have an RFC for removing unmaintained and broken packages for a reason. When a maintainer list contains names but those names are not active in the project and won’t respond to pings, the package is effectively unmaintained. Leaving names in there and expecting people to just know – or spend time looking up – who isn’t active makes the maintenance problems in the tree less legible, both to human contributors and to the policies and automated systems we have built up around packages being unmaintained.

I don’t think @bendlas’s unilateral closures of PRs where the inactive maintainers approved them were at all appropriate

You don't think my "due process" argument, has any merit, and that without any information about the "how" and "why" somebody might feel pressured to say "sure, remove me", instead of feeling encouraged to step back up?

Anyway, it’s really unfortunate that we have lost an active committer over this PR and I hope we do not lose any more. While there is clearly scope for legitimate disagreement here, please consider if this matter really needs more 10‐paragraph replies with every sentence from the previous messages quoted and responded to…
I hate to be blunt, but given the patterns at play here I think it is necessary:
@AndersonTorres, you really need to get better at taking feedback on your actions and attitude in Nixpkgs. I’ve seen many people try to do so in various different ways but I’ve not seen your behaviour change as a result of any of it. You make a lot of valuable contributions to the project, but people find you difficult to work with, and I know there are multiple people who have burned out on the project in part because of your interactions.
@bendlas, this isn’t the first or second thread I’ve seen recently that became full of heated and very long back and forth messages going nowhere once you jumped in. Please try to contribute more light than heat. You’re talking about being welcoming and not offending contributors, but if you can’t keep civil and avoid hostility that rings hollow.

@bendlas, this isn’t the first or second thread I’ve seen recently that became full of heated and very long back and forth messages going nowhere once you jumped in. Please try to contribute more light than heat. You’re talking about being welcoming and not offending contributors, but if you can’t keep civil and avoid hostility that rings hollow.

@emilazy while I appreciate that you're saying that you find my arguments too heated and my methods to crass, I'll ask you to not derail this conversation (admittedly happening on an already derailed PR) by going meta like this.
I'll be happy to answer for anything that you or anyone may feel I need to answer for, in a new thread, be it on discourse or zulip. It should also be easier to establish patterns this way, no?

Anyway, it’s really unfortunate that we have lost an active committer over this PR

Did we? I thought they already reconsidered when they deleted their comment, while I was typing out my plea for them to stay ...

The problem I see in nixpkgs:

thiagokokada, 2275 reviews merged
AndersonTorres, 2055 reviews merged
superherointj, 1569 reviews merged
bendlas, 75 reviews merged

@superherointj it's clear to me, that I've hurt you with something, so I'll not ask any further questions about this. But that is low. My number of reviews merged, that is.

There are things you can only understand with experience. There is a reason the active reviewers/commiters want to get rid of inactive maintainers. It doesn't help!

See, that pain that I'm hearing through this statement. I understand it. I've felt it. It's not a good basis for decisions. I've always been a big fan of stepping away, touching some grass and coming back refreshed.

Since you claim there isn't consensus in favor of removing INACTIVE maintainers.

Well, is there? How does the consensus say it's supposed to be done? Can I read about it? Why didn't we link it in the PRs that were opened?

And I'm quite tired of nixpkgs by now. I'm out of this madness. Good luck pleasing your inactive maintainers.
Feel free to review my PR removing myself. Since we disagree about direction of things. And I'm honestly too tired for everything negative comings from nixpkgs. The amount of negativity I receive from here is surreal. Also, this is not your fault. It is just that I don't want to continuously live sudden crisis that require having to debate everything until exhausting for bad reasons. Or be blamed for anything. My reasons. No worry. I'm not merging anymore PRs. Peace.

You know, that comparison that you drew up there, between our numbers, I found that kind of hurtful. So I'm a little bit mad at you as well right now. So I'll not review your PR now. Feel free to ping me if you still want to leave in a week. I hope you'll reconsider staying.

Is there anything I can do to amend my failures on our interactions?

There are better venues to have this conversation (feel free to email me or PM me on Matrix), but my frustration boils down to this:

@AndersonTorres, you really need to get better at taking feedback on your actions and attitude in Nixpkgs. I’ve seen many people try to do so in various different ways but I’ve not seen your behaviour change as a result of any of it. You make a lot of valuable contributions to the project, but people find you difficult to work with, and I know there are multiple people who have burned out on the project in part because of your interactions.

You're right that I probably shouldn't use such harsh words, but when your interactions with the project have never changed as a result of my many comments, I have no reason not to.

@emilazy while I appreciate that you're saying that you find my arguments too heated and my methods to crass, I'll ask you to not derail this conversation (admittedly happening on an already derailed PR) by going meta like this.
I'll be happy to answer for anything that you or anyone may feel I need to answer for, in a new thread, be it on discourse or zulip. It should also be easier to establish patterns this way, no?

No, thank you. I think someone had to say something and the behaviour from both parties here demanded comment but I’m content to have tried and I don’t think it’s my role to get into the weeds about this with you when you’ve already been warned about this kind of conduct recently by a member of the moderation team.

@superherointj it's clear to me, that I've hurt you with something, so I'll not ask any further questions about this.

You have not hurt me. What I can't handle is the amount of extra-work, back-tracking happening in nixpkgs, necro-bumping and second guessing. The more contributions, the more the odds of someone digging up something and starting a thread arguing whatever and then being forced to participate/answer in a crisis mode. Also, no merit. Then we end up in this situation that, people claim whatever, and whatever so be it. Say the words, RFC, 'consensus', process and nothing moves forward ever. And people that have put the work gets punished many times over. (Not that I am putting that much work, I stopped long ago, other people do a lot more than me, I'm a minor contributor). I'm just trying to explain the issue.

But that is low. My number of reviews merged, that is.

Well, I don't know what you mean by that. I only tried to convey the idea that people that have reviewed more think differently. A better awareness of pain points. And then, those 'useless PRs' are actually meaningful considering the amount of 'ghosting' we see.

See, that pain that I'm hearing through this statement. I understand it. I've felt it. It's not a good basis for decisions. I've always been a big fan of stepping away, touching some grass and coming back refreshed.

I honestly don't know.

Well, is there? How does the consensus say it's supposed to be done? Can I read about it? Why didn't we link it in the PRs that were opened?

Well, ... I'm tired, so I'm no longer interested in discussing what should/shouldn't be. People usually think 'rigidity' is a solution, but then, it also doesn't work as well as people think. The more bureaucracy there is, the harder it is for those that actually doing the work. I don't know the right answer. Things just feel miserable.

You know, that comparison that you drew up there, between our numbers, I found that kind of hurtful.

Just facts. If you want to be really hurt, see @SuperSandro2000, and he got suspended and had a lot of trouble to get back. lol
+12.000 reviews merged, Sandro is not a bot! He is a real person! lol
I only used that to try to convey why the difference in thinking. One is trying to optimize for what is best for whom is active. You wanted to optimize for the inactive. Time is scarce resource. You took time from me today, that I have to answer all these messages, read, think, etc. (And vice-versa.) It's a trade-off. Things won't be perfect.

So I'm a little bit mad at you as well right now.

I'm not mad at you. I'm at peace. I invite you to calm yourself. And just reflect about whatever is bothering you. Then, grow wiser. (This is a general solution for such problem.)

So I'll not review your PR now.
Feel free to ping me if you still want to leave in a week. I hope you'll reconsider staying.

I won't be staying, but not because of you specifically, I understand you had your reasons to try to move things to a certain direction. That makes sense for you. I just can't handle nixpkgs anymore because I don't have the bandwidth for it. I was already 'slowing down' before you pinged me 10x today (lol. You went over that many PRs and re-posted the same messages.)
So yeah, I need to leave nixpkgs anyway. For many reasons, I don't have the time/energy/motivation/etc. It's such a distraction for me. And there other pressing issues. So I kinda need to be out of this.
I'm all good. I hope you are well too.
Btw, I like Anderson Torres here. And I never had any communication problem with him. I think, it is a bit unfair the much bashing he gets. I think, often people misread things.
No bad feeling from me about anything. I'm just at my edge here. Just that.
I wish you all the best. And I hope you contribute more than Sandro ever did. Then, you laugh at us with our humble stats. :-)
Best regards.

Even if you can bypass the lock, please consider if this is the best venue to spend your time and energy. We won't solve these problems buried in a random PR.

Even if you can bypass the lock, please consider if this is the best venue to spend your time and energy. We won't solve these problems buried in a random PR.

Sorry to bypass the lock, my last reply in this discussion. Anyone that wants to discuss this further, please ping me on Matrix, not that this will happen, because I think the objective was already done (derailing an otherwise peacefully clean-up of maintainers that don't care about nixpkgs to discuss yet another process that will probably never gain traction).
And yes, I concur with @superherointj and @AndersonTorres here that we don't need a RFC for everything: sometimes we just need a few people that have strong desire to improve the situation. But that is my rant, I digress, let's back on-topic.

I already gave one reason: even an inactive maintainer may contribute their knowledge at times, or somebody may have luck contacting them when dealing with an especially tricky situation.

I contribute for a bunch of open source projects and have a few of my own (they're definitely not big or anything). I also work as a professional developer for at least 8 years. If someone asks me about a piece of code that I contributed 6 months ago and didn't touch it anymore, there is a good chance that I will just say "I don't remember". However, if I am still interested on it, I will definitely say something.
I think this is way more likely to be the case with an inactive maintainer: even if they want to contribute, they have nothing to add to the discussion because they don't remember anymore. It is also very common for inactive maintainers that they stopped using the package in case or even nixpkgs at all.
I don't think expecting maintainers show that they're still interested in the package by replying a (friendly) call if they didn't contribute in the last X months, something like:
"Hey @someone, are you still interested to collaborate in nixpkgs? Otherwise we will remove you in 1 week, but please keep in mind that you're welcome to come back if you want."
Keep in mind this is an example, the wording could be improved.

Another one is, that being in maintainers-list.nix will be a point of pride for anybody who made it in there and make it much easier to activate them again in the future.

I really don't think we should use maintainers-list.nix as a "point of pride". It is not free to keep the list growing without ever cleaning it up. I can think a few reasons here:

Big files slows down lots of editors making it difficult to contribute, especially for newcomers that may have no clue on how to optimise their editor configuration
This also probably has some implications in eval times. I wouldn't say huge, but we are already having performance issues in nixpkgs in general and I am sure a ~500kb file doesn't help here
Again, the security issue part since AFAIK being in the maintainers-list.nix is how we invite someone to the @NixOS/nixpkgs-maintainers group in GitHub (and give them moderation powers, that again, can be a security risk)

See, that pain that I'm hearing through this statement. I understand it. I've felt it. It's not a good basis for decisions. I've always been a big fan of stepping away, touching some grass and coming back refreshed.

There is no problem of stepping out. We are not removing maintainers forever. If they ever want to come back, the process is exactly the same as it was: open a PR adding themselves to maintainer-list.nix, add themselves to a few packages, done.

You know, that comparison that you drew up there, between our numbers, I found that kind of hurtful. So I'm a little bit mad at you as well right now. So I'll not review your PR now. Feel free to ping me if you still want to leave in a week. I hope you'll reconsider staying.

@superherointj did a honest comparison to show what a person that is a long time in nixpkgs has as a vision vs. a newcomer, and even if maybe it was not the best way to do so, it is still a valid argument that if we want to have a proper discussion, should be considered.
What I mean by that is that someone that is longer in nixpkgs will probably have more context about the kind of issues a package having inactive maintainers will have them someone that is new. But this is not to make your contributions lower or anything @bendlas (I don't know you and this is my first interaction with you AFAIR).
So again, while we are talking about the human aspect here, I think we should also consider how people replying here are also human and consider this instead of making the whole reply about one point.