Yarn install fails with acceptable node version

Following the Getting Started > Running Backstage Locally instructions fail with error when node version greater than minimum required.
Expected Behavior
When running yarn install, I should see the install process continue past the validation step when my node version meets the minimum required.
Current Behavior
yarn install fails validation and task exits without completing successfully.
✔ backstage % yarn install                                                                             (master)backstage
yarn install v1.22.1
[1/5] 🔍  Validating package.json...
error<EMAIL_ADDRESS>The engine "node" is incompatible with this module. Expected version "12". Got "14.7.0"
error Found incompatible module.
info Visit https://yarnpkg.com/en/docs/cli/install for documentation about this command.
✘[1] backstage %

Possible Solution

Adjust the package.json's engine node version specified to accept anything greater than the minimum required.
or
Adjust the Getting Started > Running Backstage Locally documentation's verbiage.

First make sure that you have at least node version 12 installed locally
First make sure that you have node version 12 installed locally

Steps to Reproduce

run yarn install with node version greater than 12.

Context
Stops me from exploring Backstage
Your Environment

Yarn (1.22.1)
NodeJS Version ( v14.7.0 ):
Operating System and Version ( macOS 10.15.6 (19G2021) ):
Shell (zsh)
Browser Information: n/a

Thanks for reporting. There were actually node 14 issues at some point at least, I think. Definitely with node 13, that much I'm sure of. Version 14 is due to become LTS soon, and we will definitely switch up at least then.
We should adjust the wording as you suggested (maybe you would even like to make a PR? :)) for starters, and later try to evaluate everything on node 14.


Fix invalid receipts error with rest function call

Change summary:

Charge gas amount for skipped REST function calls
Delete timer flags file for testnet-dev
Turn off console logging for local trackers

Related issues:

https://github.com/ainblockchain/ain-blockchain/issues/1185

Thanks for the review. Now merging.. @minsulee2 @ehgmsdk20


Add tasks to publish zips for Notifications and Notifications Core plugins

Signed-off-by: Mohammad Qureshi<EMAIL_ADDRESS>Description
Publish Notifications and Notifications Core zips to maven repo.
Issues Resolved
#474
Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

I tested locally and running ./gradlew publishPluginZipPublicationToZipStagingRepository at the top-level project will produce the plugin zip contents for both plugins in the local-staging-repo directory.
Since we have two backend plugins here, we'll need to make the following changes to the scripts in https://github.com/opensearch-project/opensearch-build:
For notifications-core build script:
./gradlew publishPluginZipPublicationToZipStagingRepository -Dopensearch.version=$VERSION -Dbuild.snapshot=$SNAPSHOT -Dbuild.version_qualifier=$QUALIFIER
mkdir -p $OUTPUT/maven/org/opensearch/plugin
cp -r ./build/local-staging-repo/org/opensearch/plugin/opensearch-notifications-core $OUTPUT/maven/org/opensearch/plugin

For notifications build script:
./gradlew publishPluginZipPublicationToZipStagingRepository -Dopensearch.version=$VERSION -Dbuild.snapshot=$SNAPSHOT -Dbuild.version_qualifier=$QUALIFIER
mkdir -p $OUTPUT/maven/org/opensearch/plugin
cp -r ./build/local-staging-repo/org/opensearch/plugin/notifications $OUTPUT/maven/org/opensearch/plugin

@peterzhuamazon @prudhvigodithi Can you advise that the changes above to the build scripts are in fact what you expect?

Hey @qreshi yes those 3 lines looks good, also just FYI, here are some PR's to refer
https://github.com/opensearch-project/alerting/pull/455/files#diff-3d64996115d0ac3b74e36f57ce6b00d6b4982614c41b1ed39eab8ef43b2e9a2b
https://github.com/opensearch-project/opensearch-build/blob/main/scripts/default/opensearch/build.sh#L81-L84
Thank you


Switch to NuGet package for libnethost.lib in .NET 7 Preview 7

https://github.com/vezel-dev/ruptura/blob/d8b4eb46d47d12bb7a48142c1a978f972569ba5c/src/module/module.cproj#L25-L44

This is going to run into: https://github.com/dotnet/runtime/issues/63602

https://github.com/dotnet/runtime/issues/63602#issuecomment-1209711704


The worst datepicker ever

full of bugs, format prop does not work as expected  - reverses month and day i don't know why. Passing function param does not work as well. Event listeners does not work as expected - 'closed' event works only if you close by selecting date or clicking on the input box, it does not triggers when clicked outside the Date picker box. 'opened' event never triggers!!!

Beautiful! Comments like this make contributing to open source software so satisfying.
I'm not asking you to use this. Go forth and write your own.

@sdaudishvili I can understand your frustration but your comment is out of line. Have respect to work people are willing to put in to open source projects (most of them in their free time) and actively contribute where you can.
This said, @charliekassel we would all appreciate you would accept this help from numerous people who also care about this project and are submitting pull requests that would address some quite severe bugs.
If life circumstances are preventing you from maintaining this project we would all respect if you could grant maintenance privileges to other contributors that (by reading the comments) already contacted you about it.
Wish you well and thanks for all the work you put into this.


watchguard

v20_watchguardmsg.zip

This parser is for all watchguard firewall

Thanks for your contribution, we'll have a look and get back to you if anything else is required.


API fees

Not an issue but a question for discussion if that's ok.
Using this plugin on a few sites even with caching won't be possible without obtaining an enterprise license the provider.
I have about 35 sites I check daily which causes over 3 times the 250 query limit. I have made enquiries on the pricing but it's a little too expensive for just me to pay.
Has anyone got any ideas about how we could collaborate around this project to get better value than everyone having to buy an enterprise license?

I think it was just a matter of time when they were charging fees for it. As I do understand they need to cover their costs, I don't understand their steep fees. It's a self fullfilling prophecy, lower fees provides more users (and will attract more additinal users) as higher fees don't. But this is too easy for me to say. I don't need to operate their company, so they might have a valid reason for it. We all need to make money right?
On the other hand, more ethical oriented, this doesn't make the world a safer place. As a strong believer in open source and free information, I do believe that the data itself should be free of charge to make the wp world safer.
Time will tell, allthough it doesnt look very promising right now. I guess we have to go for the long run.
Regarding your question, I don't think we should collaborate in creating a public cache of their database (where the needed solution will lead to, to prevent spending their fees). Their database is probably protected by copyright. I don't want to violate any licence for that matter.
The only way to overcome this (IMO) is to persuade wpvulnb to open up their data (not services) and give it to the community. But it will probably a tough sell as they are currently moving to the dark side.

OK, well I was told that an enterprise license is €40 per month, for unlimited queries. I was actually thinking it would make sense to set up a syndicate to share this enterprise key. Probably not permitted, and quite a bit of work to manage.
Have you enquired how much it would cost to license the wp-sec plugin? possibly could set up a patreon or something to cover the fee if enough people are interested. I like the fact I can script stuff so I only get the information I need.
Anyway after intensive searching I have realised that for me, the managewp bundles is probably the way to go, they charge $25 per month for per 100 sites for security scanning and bundle quite a few features in including being able to update from their console, and add new sites and log into sites easily over slack.


Provider: VK

vk.com offer an iframe embed for videos on the platform. Would be nice to see it included as a provider.

Thanks for the issue! Our providers are standard (audio/video/hls) which should work with most streaming providers. If VK does not provide either of those file types and is only an embed then we won't be supporting them.
Alternatives:

AWS
Mux
Cloudflare Stream
Api.video


plan-coordinates: floating box with values

If I want to have multiple floorplans in one card, it's impossible to read top/left values as they show just under the top panel and floorplan is further below, need of scrolling.
Would be great if box could just float and be visible all the time

Yes it can. I will do a fix for this next week
Sent with GitHawk


Move GitHub stats fetching to Vercel

https://github.com/deepset-ai/haystack-home/issues/349

Hey @carlosgauci - thank you. Before I merge, could you educate me on somehing: Does everythng inapi/ become a vercel function? And is there a way I can inspect them within vercel too?

Hey @TuanaCelik, yes the api directory is for Vercel functions, you can inspect the logs for them from the Vercel dashboard but I don't think you can see the actual code from there


Consolidate and organize docs after monorepo merge.

More work remains, this is a first step.

@geeknoid: Adding do-not-merge/release-note-label-needed because the release note process has not been followed.

One of the following labels is required "release-note", "release-note-action-required", or "release-note-none".
Please see: https://github.com/kubernetes/community/blob/master/contributors/devel/pull-requests.md#write-release-notes-if-needed.
Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.

@geeknoid: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
22c42e8b5e3471aebb6bf3f8aee87a338a5b6b5e
link
/test istio-presubmit

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@geeknoid: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

prow/istio-presubmit.sh
2139f2449434701bce83c63616fe02b76f2e3bb4
link
/test istio-presubmit

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


How should i choose window_size_samples?

it was said in the comment "Silero VAD models were trained using 512, 1024, 1536 samples for 16000 sample rate"
so, for a better acuuracy, should i chosse 1536 as my window_size_samples?
however, for a better lantancy, i should choose 512?

The bigger the window size, the higher the quality.
With an obvious latency trade off.


added web topic

Hi Eldar!
Hi noticed a networks-web topic was missing, so I added one :)

Hi, made requested changes:

Updated list numbers
Created web scraping topic
Fixed Beutifulsoup typo to BeautifulSoup
Added requests module to HTTP Client and warned about it's synchronous functionality


Bridged Device Basic Information cluster

Problem

Spec conformance.
Server implementation.

Change overview
XML and ZAP updates.
Generic platform server implementation.
Testing
How was this tested? (at least one bullet point required)

Wrote and read NodeLabel.
Read Reachable.
Read ServerGeneratedCommandList.
Read ClientGeneratedCommandList.
Read AttributeList.
Read ClusterRevision.

Not sure why this built locally with the files misnamed...


OS hides cursor while pressing WASD

I realize this issue is not really a fault of PixiJS, but I figured it would be a common issue for people making games in the browser, so maybe someone here knows how to solve this.
In my game, the user presses WASD to move, while simultaneously using the mouse to aim and fire off spells.  The cursor is constantly flickering because OSX has a "feature" that hides the mouse cursor while someone is typing -- something that makes sense in normal scenarios, but not for games.
I've tried hiding the native mouse cursor and listening for the "mouseover" event and then rendering my own cursor at the latest location.  This works to a degree in that it stops the flickering, but there is noticeable input delay.  The cursor just feels sluggish.
Any ideas?

I remember being where you are about a year ago, ignoring the issue solved it for me :)

@kaansoral Ignoring the flickering or the sluggishness?

Ignoring the flickering, also, generally people move their cursors while gameplay, and when you move the cursor, the cursor constantly re-appears, it's a small consolidation


Docs: Granular permissions when linking to resources

Given a lambda and SQS queue:
    const app = new sst.aws.Function('PublisherFn', {
      handler: 'publisher.handler',
      link: [queue],
      url: true,
    });

Is it possible to provide granular permissions via link instead of sqs:*?

Yeah I'll try and put an example together but https://sst.dev/docs/component/linkable#static-wrap the queue and specify your own permissions.

Here it is https://sst.dev/docs/component/linkable#modify-built-in-links


Register field ordering is broken.

From open-register-design-tool created by sjalloq: Juniper/open-register-design-tool#69
The RDL spec shows how fields are packed in a register on p.44 of the v1.0 spec.  In the case of LSB ordering, the following should hold:
lsb0;
reg {
field {} A; // Single bit from 0 to 0
field {} B[3]; // 3 bits from 3:1
// 4 bits from 7 to 4 are reserved and unused
field {} C[15:8]; // 8 Bits from 15 to 8
field {} C[5]; // 5 Bits from 20 to 16
};

However, this doesn't appear to be the case with Ordt.  My understanding from the above example is that the following register:
reg irq_reg_6 {
    regwidth = 16 ;
    interrupt _init_done ;
    interrupt _tc_ready ;
    interrupt _temp_low_warn[4:4] ;
    interrupt _temp_high_warn ;
    interrupt _temp_low_alarm ;
    interrupt _temp_high_alarm ;
};

should result in a packed register of the form:
Bit 0 : init_done
Bit 1: tc_ready
Bit 2 : reserved
Bit 3 : reserved
Bit 4 : temp_low_warn
Bit 5 : temp_high_warn
Bit 6 : temp_low_alarm
Bit 7 : temp_high_alarm
Ordt is outputting the following:
Bit 0 : init done
Bit 1: tc_ready
Bit 2 : temp_high_warn
Bit 3 : temp_low_alarm
Bit 4 : temp_low_warn
Bit 5 : temp_high_alarm

Yes, ordt will pack fields with no assigned offset in first available space in the reg starting from lsb.  Spec was somewhat ambiguous here so implementation may differ from other compilers - given volume of code out there, default behavior will not be changed.  Might be worth adding a switch at some point, but solution for now is to use bit offsets when instancing fields.


Rel 0.5.0

Syncing development status of upcoming Release 0.5.0 with adaptations towards a new V2 API.

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 70.90607% with 350 lines in your changes missing coverage. Please review.

Please upload report for BASE (prep-rel-0.5.0@e52b690). Learn more about missing BASE report.

Files with missing lines
Patch %
Lines

databroker/src/grpc/kuksa_val_v2/conversions.rs
18.88%
219 Missing :warning:

databroker/src/grpc/kuksa_val_v2/val.rs
90.09%
88 Missing :warning:

databroker/src/broker.rs
0.00%
27 Missing :warning:

...tabroker/src/grpc/sdv_databroker_v1/conversions.rs
0.00%
6 Missing :warning:

databroker/src/grpc/server.rs
25.00%
6 Missing :warning:

databroker/src/grpc/kuksa_val_v1/conversions.rs
0.00%
2 Missing :warning:

databroker/src/main.rs
0.00%
1 Missing :warning:

databroker/src/viss/v2/conversions.rs
0.00%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@                Coverage Diff                @@
##             prep-rel-0.5.0       #3   +/-   ##
=================================================
  Coverage                  ?   52.62%
=================================================
  Files                     ?       33
  Lines                     ?    13115
  Branches                  ?        0
=================================================
  Hits                      ?     6902
  Misses                    ?     6213
  Partials                  ?        0

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Add support for declaratively setting RigidBody userData

I ran into a case where I wanted to add user data to a rigid body in order to read it when raycasting. I can do this now with a ref and the raw api, but it would be nice to be able to set rapier user data on <RigidBody /> declaratively.
I have noted that the RigidBody component and Collider components already have a userData prop for body/collider Object3Ds.

Here are some approaches I've thought of:
Option 1: add a rapierUserData prop for the RigidBody userData
Fairly self-explanatory. One con is if you want some user data on both the Object3D + the rigid body, two props are needed.
Option 2: use the userData prop as both the three Object3D userData and the rapier RigidBody userData
Both three.js Object3D userData and rapier RigidBody userData are just arbitrary objects. We could set both of these to the one userData prop. There could be some potential footguns though around expectations of Object3D userData and RigidBody userData always being equal.

Option 1 would be my preference for its simplicity, but keen to get thoughts. I'm happy to do the implementation too 🙂

Good point!
I like both of these suggestions 🤔
In a way I feel the consolidated userData passing to both objects is simpler, and perhaps wouldn't hurt...
I kinda want someone with a strong opinion for what makes most sense here 😄

I'd be happy with a single userData prop that sets both.
It's an easy thing to change in future if use cases pop up for providing different user data to three and rapier objects.

If there's no other suggestions on this issue in the coming days, I'll put together a quick PR.
Might also flick it into the discord.

I would recommend putting all the rapier-related data in an object like userData.rapier. userData may be set in blender when exporting a gltf and it's already a standard thing, I think it would be trickier for people to set rapierUserData via something like blender out of the box.

Please correct me if I'm wrong, but I don't believe user data from models/blender will be affected by this change. The <RigidBody /> component only sets userData for it's own Object3D using the userData prop.
If you're using gltfjsx, you'd still need to wrap meshes in <RigidBody /> components, and that shouldn't interfere with the gltf user data.

Closing this now - PR has been merged and released 🎉 (https://github.com/pmndrs/react-three-rapier/pull/154)


Try pop up two

We implement javascript object to render the cards onto the modal
Linters were used to find programmatical errors and they were resolved

Thank you for the review

Please, I have loaded the projects section dynamically

Please, to the second reviewer, some changes were made after the project was submitted for review.
In light of this, please double-check before you give a review.
I am assuming you will review the project before those the late changes were made.
Thank you for your consideration


Fun cargo gift crates

About the PR
Added the chance for fun crates to be gifted to the station!
Why / Balance
Fun gift crates for fun crews!
Technical details
Edited cargo_gifts.yml and cargo-gifts.ftl to match.
Media
Requirements

[ ] I have read and am following the Pull Request and Changelog Guidelines.
[X] I have added media to this PR or it does not require an ingame showcase.

Breaking changes
Changelog
:cl:

add: Added the chance for fun crates to be gifted to the station!

This is throwing exceptions due to an UnknownPrototype error, and I can't figure out why/what I'm missing:

Fixed the issue I was having with the exception, also added some minor character changes for gift descriptions to read better when it triggers

Can you make your PR description and changelog a little more descriptive than "fun"? Mention what crates and the event they are gifted in.

Can you make your PR description and changelog a little more descriptive than "fun"? Mention what crates and the event they are gifted in.

Done!

Closing until this is ready with more to add!


TODOs in this repo should point to useful github issues

PhET has a policy that TODOs in production code are tied to a github issue to help in scheduling their work. This policy was created after many TODOs were created without a corresponding github issue associated with them in this repo. Never the less, this code is still production code, and TODOs should adhere to this philosophy. I'll mark TODOs in this repo to this issue now, but this should NOT be a catch all, work should be done to handle, triage, schedule and fix the work outlined by the TODOs in this repo (it is production code!).
(see work done in phetsims/tasks#1129 also)

this is a duplicate of https://github.com/phetsims/kite/issues/76.
Although it now seems like there are 94 instead of 70. Closing as a duplicate.

Updated todos pointing to this issue so it doesn't reopen tonight.

Ope thanks for that. I believe I did a couple of others that I should hit as well.

You did this everywhere. What a gem. Thanks!


Fix standing in car bug

Some times the sit animation is not applied when attaching a player to a car. If you try getting in and out of a car a few times you will notice. This PR fixes this problem by setting the animation 2 times. I did a fair amount of testing and never saw it fail.
This PR also adds player_api to the dependencies since it does seem to depend of player_api
Previously the code was attaching a riding player to the car every tick. This PR fixes that so it only attaches the player once.

Seems like this is a regression in Minetest. I didnt have this problem when I made my automobiles mod in the old days. Now I test it and it has the same problem.


added QtCreator section to .gitignore

it could help QtCreator users while working on the project

Thank you!  I'll look into why the build is failing as well.


Include Python type checking step in Precommit

The most common CI failure for me is the python type checking one since it's not automatically run during pre-commits. This means, issues of this type usually get caught in CI. And then I have to manually run the python type checking script.

I think it's a little heavy-handed to do it as a pre-commit because if I'm just modifying docs, there's not really a need to do python type-checking. Similar to TS type-checking, I think it should be done as part of the build process (and thus making it harder to forget during development) - I think this is how it's done in google3, however I'm not sure how to integrate pyright with our py_library build rules.

I was thinking that the type checking step would run only on the python files that changed or if python files have been changed, whichever is easiest to implement. Is it not possible to make precommit selectively run steps? Or to pass in certain args to the script? I have not used precommit really before, so not sure if there are limitations.

You can filter based on file type, example: https://github.com/google/mesop/blob/6a65aad6d433c633be3f4a73a2d700c374ff08b4/.pre-commit-config.yaml#L39
I'm still a bit unconvinced about adding it here because Python type-checking can be quite slow (sometimes, and potentially I've pyright misconfigured, it can take a very long time, >1 minute, it seems to just hang).
BTW are you using the pylance VS Code extension: https://marketplace.visualstudio.com/items?itemName=ms-python.vscode-pylance? I find that it's quite responsive and helps me catch most of the type issues before committing.

OK, I figured out why it was super slow, it was because pyright was choking on the venv directories which I've fixed in: https://github.com/google/mesop/pull/821/commits/4583e6752b9bab592180a0109687424c9bd04962 - it takes ~4 seconds for me now, so I'm now not opposed to this :)

I see. That's good to know.
In terms of VS Code set up, I did have pylance set up, but looks like for Type Checking Mode, I had it set to "off". I changed it to "standard" Or is there a different setting I should used there?

@richard-to - I think the main setting is https://github.com/google/mesop/blob/8b3f176c35c3b81768f6e945b74ada1ddd56bcdc/.vscode/settings.json#L26 and setting up venv: https://google.github.io/mesop/internal/development/#venv - once you do this, you should have almost no more red squigglies


Use Nginx + php-fpm for better performance

Is your feature request related to a problem? Please describe.
Apache with php-cgi suffers from performance issue when there is a lot of incoming connections.
Describe the solution you'd like
Use Nginx web server with php-fpm instead of Apache2 + php-cgi

Do you have any tests / benchmark results to compare the performance between apache & nginx with Nominatim?

I think nginx really is (or at least was) faster when you have thousands of concurrent connections. Is this what you're facing?

I think nginx really is (or at least was) faster when you have thousands of concurrent connections. Is this what you're facing?

Absolutely, as I recall php-cgi on Apache2 is fork based, each connection would fork a new apache process. Though the database can't handle 1000x concurrent connections, it makes the pressure on the webserver and php much lower.
Nginx with PHP-FPM is also document in official installation guide, it's can be drop in place into the dockerfile.

My question was more along those lines: is a load of thousands requests/seconds a problem that you're facing or have you just read somewhere that nginx is faster than apache?

Yes, for this reason I had to drop running it in docker and installed a vm version with nginx.

I would not be averse to switching to nginx but you'd have to solve the the log rotation which is a bit tricky.
Would you be willing to try nginx privately and send a PR when you've tested it with your high load environment?
@philipkozeny WDYT?

I would not be averse to switching to nginx but you'd have to solve the the log rotation which is a bit tricky.
Would you be willing to try nginx privately and send a PR when you've tested it with your high load environment?
@philipkozeny WDYT?

sounds good to me.

We have started the 'n7m' project, a Numeronym for Nominatim.  It's not nearly as mature as 'nominatim-docker' but something we have been experimenting with.
This branch has a FPM docker image with n7m fronted with an official NGINX Docker image:
https://github.com/smithmicro/n7m/tree/fpm
We have yet to do any performance tests comparing NGINX+FPM to Apache.  Have at it!

@dsperling That's a really interesting project. I hope you succeed and we can refer the people with more advanced use cases (which we have been reluctant to implement for fear of extra maintenance burden) to your project.

@AnthraX1 - PHP-FPM support has now been merged to the main branch of n7m and is working extremely well.  Comments welcome.
https://github.com/smithmicro/n7m


Environment variables should allow "_" (underscore) in the environment variable name.

Failing to update environment variables via the plugin when the env variable name contains and _ character (underscore)

AWS allows this case.

Reproducing
Set environment variables to {"c_c": "c_c"}.
This will fail the assertion but passes on AWS.

what does the pipeline look like?
is it from a second deploy? or an update stage?
which verification task in the pipeline is failing?

np. thanks for the update.


Unable to unmarshal messages containing oneofs; fixed by using jsonpb

At present, it is not possible using go-micro to accept JSON input containing messages with oneofs.
This is due to the use of encoding/json rather than github.com/golang/protobuf/jsonpb, the latter of which is capable of processing oneofs.
When attempting to do so, the following error is encountered
2018/03/15 01:20:42 Unexpected error serving request, closing socket: json: cannot unmarshal object into Go struct field Backend.Config of type [redacted].isBackend_Config

The message definition I am using is as follows
// a storage backend
message Backend {
  // unique identifier for the Storage entry
  UUID uuid = 1;
  // type of the storage backend, as considered by graymeta/stow
  string kind = 2;
  // storage backend configuration
  oneof config {
    BackendConfigLocal config_local = 10;
    BackendConfigS3 config_s3 = 11;
    BackendConfigGCS config_gcs = 12;
    BackendConfigABS config_abs = 13;
    BackendConfigSwift config_swift = 14;
    BackendConfigOSCS config_oscs = 15;
    BackendConfigB2 config_b2 = 16;
  }
}

and the JSON I am using, noting that to ensure I was using the correct format, I marshalled this from within Go
{"backend":{"kind":"local","Config":{"ConfigLocal":{"path":"/tmp"}}}}

I am testing this using micro web's interface.
Please see this issue for a potential fix.  The comments in the issue seem to indicated it is necessary to use jsonpb rather than encoding/json in order to support oneofs.

The issue has been raised before. We're aware that we do not support oneof by default. Someone PRed a codec to support this but it needs to be in go-plugins https://github.com/micro/go-micro/pull/220. You can use this codec instead of the default for json.

Alright, thanks.  I'll look into that.

What issues are preventing jsonpb from being used as the default for JSON?

The default json-rpc codec supports actual json rpc 1.0. This codec doesn't do that at all. It's a hack of the proto codec to try support oneof with json. It does not take into consideration request/response format in coordination with json-rpc. It's not the way I would solve the problem.

Do you have any suggestions on better ways to solve the lack of oneof support?

Also, is there any way to have the micro cli support oneofs?  Would I need to write a custom command line client in order to support oneofs?
@asim

I thought you were working on this PR https://github.com/micro/go-plugins/pull/161

@asim I am, but I've had to modify the micro cli's code in order to get it to use my alternative codec.  What would the appropriate way to have it use an alternative codec be?

Closing as I think this is unlikely to be supported any time soon.


Adding: C language using curl library

PR Description
this PR has C libcurl codegen correct code
Related Issues

Related Issue #138
Closes #138

Checklist

[x] I have gone through the contributing guide
[x] I have updated my branch and synced it with project main branch before making this PR
[x] I have run the tests (flutter test) and all tests are passing

Added/updated tests?
We encourage you to add relevant test cases.

[x] Yes
[ ] No, and this is why: please replace this line with details on why tests have not been included

Step 1:
You can install libcurl using Homebrew, a popular package manager for macOS. Open Terminal and run the following command:
brew install curl
Step 2:
Write your C code using libcurl. You can use any text editor or an integrated development environment (IDE) like Xcode or Visual Studio Code.
Step 3:
Assuming you have a C file named main.c containing your libcurl code, you can compile it using gcc . Open Terminal and navigate to the directory containing your C file.
 cd /path/to/your/project
gcc -o my_program main.c -lcurl
This command compiles your main.c file and links it with the libcurl library (-lcurl). The resulting executable will be named my_program.
Step 4:
Once compiled successfully, you can run your program from the Terminal:
./my_program

@ashitaprasad @animator  the above steps can be used to run the program

There are compilation errors in the generated code, like for cases GET5 and GET6.
Please fix them.

@ashitaprasad @animator done with the compilation error please have a look

@nikkivirtuoso Why are headers being added in the generated code even when no headers are being sent.
Take the example of GET1
struct curl_slist *headers = NULL;
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, headers);
Is this required in the GET1 example ?

Yes ma'am,some APIs may expect headers to be explicitly set to null (NULL) e.g. Public available APIs

Do not bloat the generated code unnecessarily ..
Share 1 public API which requires the header to be explicitly set as null.

ma'am please review my code, for my previous comment I apologize I thought if we use the header at every call that would be a safe call but it is not so, and there is no API which requires header explicitly set as null https://stackoverflow.com/questions/76601491/why-would-a-header-key-with-a-null-value-in-a-get-request-exist-on-some-requests
i read this problem and consider the header key as header itself Now i am clear with the thought

Some feedback :
Is this line in the code required ?
curl_easy_setopt(curl, CURLOPT_DEFAULT_PROTOCOL, "https");

For the POST test cases where there is multipart ex in POST4, why is a multipart/form-data header being added if the library is automatically generating and adding it internally
struct curl_slist *headers = NULL;
headers = curl_slist_append(headers,"Content-Type: multipart/form-data");
curl_easy_setopt(curl, CURLOPT_HTTPHEADER, headers);

Also, please adjust the new lines in the code. You don't need more than a single new line between any code block.

no ma'am we are passing the form-data
part = curl_mime_addpart(mime);
    curl_mime_name(part, "text");
    curl_mime_data(part, "API", CURL_ZERO_TERMINATED);

    part = curl_mime_addpart(mime);
    curl_mime_name(part, "sep");
    curl_mime_data(part, "|", CURL_ZERO_TERMINATED);

    part = curl_mime_addpart(mime);
    curl_mime_name(part, "times");
    curl_mime_data(part, "3", CURL_ZERO_TERMINATED);

that's why it is generating in the POST4 ex

@nikkivirtuoso Did you check if it is required as the library is automatically generating it.
Modify the POST4 generated code and add the following feature :

print the request headers that are being sent to the server
Do this for both the cases - one where you are explicitly setting the header and the other where you are not
Share both the codes below which prints the request headers

code without header:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <curl/curl.h>

size_t write_callback(char *ptr, size_t size, size_t nmemb, void *userdata)
{
    printf("%.*s", (int)(size * nmemb), ptr);
    return size * nmemb;
}

int main()
{
    CURL *curl;
    CURLcode res;
    curl = curl_easy_init();
    if (curl)
    {
        curl_easy_setopt(curl, CURLOPT_CUSTOMREQUEST, "POST");
        curl_easy_setopt(curl, CURLOPT_URL, "https://api.apidash.dev/io/form");
        curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L);

        curl_mime *mime;
        curl_mimepart *part;
        mime = curl_mime_init(curl);

        part = curl_mime_addpart(mime);
        curl_mime_name(part, "text");
        curl_mime_data(part, "API", CURL_ZERO_TERMINATED);

        part = curl_mime_addpart(mime);
        curl_mime_name(part, "sep");
        curl_mime_data(part, "|", CURL_ZERO_TERMINATED);

        part = curl_mime_addpart(mime);
        curl_mime_name(part, "times");
        curl_mime_data(part, "3", CURL_ZERO_TERMINATED);

        curl_easy_setopt(curl, CURLOPT_MIMEPOST, mime);
        curl_easy_setopt(curl, CURLOPT_HEADERFUNCTION, write_callback);
        curl_easy_setopt(curl, CURLOPT_HEADER, 1L);

        res = curl_easy_perform(curl);
        curl_mime_free(mime);
    }
    curl_easy_cleanup(curl);
    return 0;
}

output:

code with header:
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <curl/curl.h>

size_t write_callback(char *ptr, size_t size, size_t nmemb, void *userdata)
{
    printf("%.*s", (int)(size * nmemb), ptr);
    return size * nmemb;
}

int main()
{
    CURL *curl;
    CURLcode res;
    curl = curl_easy_init();
    if (curl)
    {
        curl_easy_setopt(curl, CURLOPT_CUSTOMREQUEST, "POST");
        curl_easy_setopt(curl, CURLOPT_URL, "https://api.apidash.dev/io/form");
        curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L);
        struct curl_slist *headers = NULL;

        headers = curl_slist_append(headers, "Content-Type: multipart/form-data");
        curl_easy_setopt(curl, CURLOPT_HTTPHEADER, headers);

        curl_mime *mime;
        curl_mimepart *part;
        mime = curl_mime_init(curl);

        part = curl_mime_addpart(mime);
        curl_mime_name(part, "text");
        curl_mime_data(part, "API", CURL_ZERO_TERMINATED);

        part = curl_mime_addpart(mime);
        curl_mime_name(part, "sep");
        curl_mime_data(part, "|", CURL_ZERO_TERMINATED);

        part = curl_mime_addpart(mime);
        curl_mime_name(part, "times");
        curl_mime_data(part, "3", CURL_ZERO_TERMINATED);

        curl_easy_setopt(curl, CURLOPT_MIMEPOST, mime);

        curl_easy_setopt(curl, CURLOPT_HEADERFUNCTION, write_callback);
        curl_easy_setopt(curl, CURLOPT_HEADER, 1L);

        res = curl_easy_perform(curl);
        curl_mime_free(mime);
        curl_slist_free_all(headers);
    }
    curl_easy_cleanup(curl);
    return 0;
}

output:

#include <stdio.h>
#include <curl/curl.h>
int debug_callback(CURL *handle, curl_infotype type, char *data, size_t size, void *userptr)
{
    if (type == CURLINFO_HEADER_OUT)
    {
        printf("Sent header: %.*s", (int)size, data);
    }
    return 0;
}

int main(void)
{
    CURL *curl;
    CURLcode res;
    curl_global_init(CURL_GLOBAL_ALL);
    curl = curl_easy_init();
    if (curl)
    {
        curl_easy_setopt(curl, CURLOPT_URL, "https://api.apidash.dev/io/form");
        curl_easy_setopt(curl, CURLOPT_POSTFIELDS, "name=daniel&project=curl");
        curl_easy_setopt(curl, CURLOPT_DEBUGFUNCTION, debug_callback);
        curl_easy_setopt(curl, CURLOPT_VERBOSE, 1L);

        res = curl_easy_perform(curl);
        if (res != CURLE_OK)
            fprintf(stderr, "curl_easy_perform() failed: %s\n",
                    curl_easy_strerror(res));

        curl_easy_cleanup(curl);
    }
    curl_global_cleanup();
    return 0;
}

output:

this is the output when i am not using the header

got it providing same formdata output for both using headers and without using headers

@ashitaprasad
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <curl/curl.h>

int main() {
  CURL *curl;
  CURLcode res;
  curl = curl_easy_init();
  if(curl) {
    curl_easy_setopt(curl, CURLOPT_URL, "https://api.apidash.dev/io/form");
    curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L);
    curl_mime *mime;
    curl_mimepart *part;
    mime = curl_mime_init(curl);

    part = curl_mime_addpart(mime);
    curl_mime_name(part, "asd");
    curl_mime_data(part, "sdad", CURL_ZERO_TERMINATED);

    curl_easy_setopt(curl, CURLOPT_MIMEPOST, mime);
    res = curl_easy_perform(curl);curl_mime_free(mime);

  }
  curl_easy_cleanup(curl);
  return 0;
}

i was checking the content-type for this and i recieved the application/json type but i am sending a form-data and i don't think this code is wrong

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <curl/curl.h>

// Callback function to handle headers
size_t header_callback(char *buffer, size_t size, size_t nitems, void *userdata)
{
    // Check if the buffer contains "Content-Type" header
    if (strncasecmp(buffer, "Content-Type:", 13) == 0)
    {
        printf("Content-Type: %s\n", buffer + 14); // Print the content-type
    }
    return nitems * size;
}

int main()
{
    CURL *curl;
    CURLcode res;
    curl = curl_easy_init();
    if (curl)
    {
        curl_easy_setopt(curl, CURLOPT_URL, "https://api.apidash.dev/io/form");
        curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L);

        curl_mime *mime;
        curl_mimepart *part;
        mime = curl_mime_init(curl);

        part = curl_mime_addpart(mime);
        curl_mime_name(part, "asd");
        curl_mime_data(part, "sdad", CURL_ZERO_TERMINATED);

        curl_easy_setopt(curl, CURLOPT_MIMEPOST, mime);
        curl_easy_setopt(curl, CURLOPT_HEADERFUNCTION, header_callback);

        res = curl_easy_perform(curl);
        curl_mime_free(mime);
    }
    curl_easy_cleanup(curl);
    return 0;
}

here is the code for printing the content-type and below is the output:

@ashitaprasad ma'am done with the modifications I have used the method indication for PUT, PATCH, DELETE as for PUSH and GET lib is automatically setting it and for application/json and application/plain/text i have included in headers as it was taking wrong content-type in these cases

@nikkivirtuoso You need to add the print statements for printing the response code and response body in the generated code.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <curl/curl.h>
size_t write_callback(char *ptr, size_t size, size_t nmemb, void *userdata) {
    fwrite(ptr, size, nmemb, stdout);
    return size * nmemb;
}

int main() {
    CURL *curl;
    CURLcode res;
    curl = curl_easy_init();
    if(curl) {
        curl_easy_setopt(curl, CURLOPT_URL, "https://api.apidash.dev/humanize/social?num=8700000&digits=3");

        struct curl_slist *headers = NULL;
        headers = curl_slist_append(headers, "User-Agent: Test Agent");
        curl_easy_setopt(curl, CURLOPT_HTTPHEADER, headers);
        curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, write_callback);

        res = curl_easy_perform(curl);
        curl_slist_free_all(headers);
    }
    curl_easy_cleanup(curl);
    return 0;
}

are you saying to include this in the code ?

it is producing output if i don't include the output printing statement see:

and same output is coming if i use the above mentioned code

@nikkivirtuoso
Expected Output :
Response code: 200
Response body: {"data":"8.700 million"}

Your output:
{"data":"8.700 million"}

*   Trying <IP_ADDRESS>:443...
* Connected to api.apidash.dev (<IP_ADDRESS>) port 443 (#0)
* ALPN: offers h2,http/1.1
*  CAfile: /etc/ssl/cert.pem
*  CApath: none
* SSL connection using TLSv1.3 / AEAD-CHACHA20-POLY1305-SHA256
* ALPN: server accepted http/1.1
* Server certificate:
*  subject: CN=api.apidash.dev
*  start date: Mar  7 21:07:30 2024 GMT
*  expire date: Jun  5 21:07:29 2024 GMT
*  subjectAltName: host "api.apidash.dev" matched cert's "api.apidash.dev"
*  issuer: C=US; O=Let's Encrypt; CN=R3
*  SSL certificate verify ok.
* using HTTP/1.1
> GET /humanize/social?num=8700000&digits=3 HTTP/1.1
Host: api.apidash.dev
Accept: */*
User-Agent: Test Agent

< HTTP/1.1 200 OK
< Server: nginx/1.24.0
< Date: Sat, 23 Mar 2024 18:19:34 GMT
< Content-Type: application/json
< Content-Length: 15
< Connection: keep-alive
<
* Connection #0 to host api.apidash.dev left intact
{"data":"8.7M"}

will this output be considered as correct output ?

@nikkivirtuoso No this will not work.
We have already clearly mentioned what should be the expected output.

modified the code as the need, please have a look on the code

Thanks for resolving all the issues. LGTM 🚀


Exception in handler when response has started

Hi! The middleware throws exception when the response has started when it tries to clear it. I can make a PR if you give me permissions.
Steps to reproduce:
HttpContext.Response.HasStarted is true when the middleware executes

@valdisiljuconoks  Thanks I created a PR

Believe I'm seeing the same issue on my side.

Hi. Just flagging that we are seeing this error logged frequently also.

@Dandroid5000 @hybrid897 release 2.0.0 should solve the issue

Hi @AndersHGP ,
Can you please update the package to also support .Net 5?
We are not in a position to move to .Net 6 yet as we have other packages stuck in 5.
Thanks
Dan

@Dandroid5000 You should be able to run on .NET 6 and use .NET 5 packages.
What packages don't support .NET 6 for you?
P.S. I recommend upgrading to the latest Optimizely (Epi) packages. Recently we found out that older Opti packages had a security hole. Luckily, good people found it out and not the bad guys :)

Anyway, this is fixed in 2.0.0. So closing.


Emulate MOHYSE in Raven (4)

Julie will integrate MOHYSE into RAVEN with the help of James Craig.

James Craig's evaluation of MOHYSE in RAVEN:
#Translation of MOHYSE model into Raven:
  :PotentialMelt     POTMELT_DEGREE_DAY
  :CatchmentRoute    ROUTE_GAMMA_CONVOLUTION2
  :EvaporationMethod PET_MOHYSE
  :DirectEvaporation DIRECT_EVAP_BASIC

  :HydrologicProcesses
     :SoilEvaporation  SOILEVAP_LINEAR  SOIL[0]      ATMOSPHERE
     :SnowBalance      SIMPLE_MELT      SNOW         PONDED_WATER
     :Precipitation    RAVEN_DEFAULT    ATMOS_PRECIP MULTIPLE
     :Infiltration     INF_HBV          PONDED_WATER SOIL[0]
     :Baseflow         BASE_LINEAR      SOIL[0]      SURFACE_WATER
     :Percolation      PERC_LINEAR      SOIL[0]      SOIL[1]
     :Baseflow         BASE_LINEAR      SOIL[1]      SURFACE_WATER
  :EndHydrologicProcesses

#linear infil: equal to inf HBV with beta=1 or VIC_ARNO with b=1
TODO:

Add SOILEVAP_LINEAR  # should have anyhow
Add PET_MOHYSE (or find literature source for better name)
Support :DirectEvaporation which reduces rain & PET simultaneously prior to ponding as forcing correction [defaults to DIRECT_EVAP_NONE]
Add ROUTE_GAMMA_CONVOLUTION2 to be able to override shape parameter of UH

All of these are very straightforward revisions (at least for James :) )

@huard I have a meeting with James Craig about this topic tomorrow. So, I will update you by tomorrow.

@huard The meeting with James was very fruitful. We will start with the implementations of this model (rather than HMETS). You estimate is reasonable. Probably a little too high. We will have this running for our meeting in October. :)

@richardarsenault During my meeting with James, we were wondering if you have an idea where the PET formulation in MOHYSE is originating from. This document isn't mentioning any reference for this. So, we would call the approach PET_MOHYSE in RAVEN.
@richardarsenault We want to compare our RAVEN implementations against the MATLAB codes. It would be great if we could use a parameterized model if you have one at hand. Otherwise I'd use one of our catchments but would need to find good parameter sets to get reasonable outputs. Let me know!

@julemai We can certainly send you parameters and data to test the MOHYSE model on one of our catchments. I'll get that to you shortly.
@julemai The PET (ETP in french) is computed in equations 2-7 and was developed by the MOHYSE creators. It was supposed to be an equation that includes most processes that can be easily understood by students, not necessarily to perform super well.

@richardarsenault Great! I'll build up a framework then to benchmark the two versions- Raven and Matlab- against each other.
@richardarsenault Another document to improve my French. The process is going to be called PET_MOHYSE then. :)

Thanks Julie, Tell me if you need anything else.

MOHYSE is 99.9% emulated in Raven everything. Kudos to James Craig. Raven is running with an NSE of 0.731 for the test setup. The only thing we don't want to emulate is that MOHYSE allows for negative AET/soil moisture. That's the reason for the slight difference. The new version will be pushed to the Raven trunk on Monday.
I would show all the detailed results and how to setup Raven in MOHYSE-mode when we meet beginning of October. How does that sound?

Sounds good, that is great news! Say thanks to James for me!
Would it be easy for you to provide a code to run GR4J with CemaNeige ? We could start testing with that test case for now, for example with regionalization and calibration.
Thanks!

Yep. That setup should actually be in the manual of Raven. I have one example for GR4J for the York watershed. I will double-check with James on Monday if this has GR4J and Cemaneige properly setup and then I'll share it with you.
If you prefer one of your basins please send it to me and I use that one.

Hi, no problem for the catchment, it's more about the logic of connecting everything in the pavics framework than actually modelling anything interesting...
Thanks a lot!
Richard
Sent from my Samsung Galaxy smartphone.
-------- Original message --------From: Julie<EMAIL_ADDRESS>Date: 2018-09-21  20:02  (GMT-05:00) To: Ouranosinc/raven<EMAIL_ADDRESS>Cc: richardarsenault<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Subject: Re: [Ouranosinc/raven] Emulate MOHYSE in Raven (4) (#11)
Yep. That setup should actually be in the manual of Raven. I have one example for GR4J for the York watershed. I will double-check with James on Monday if this has GR4J and Cemaneige properly setup and then I'll share it with you.
If you prefer one of your basins please send it to me and I use that one.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/Ouranosinc/raven","title":"Ouranosinc/raven","subtitle":"GitHub repository","main_image_url":"https://assets-cdn.github.com/images/email/message_cards/header.png","avatar_image_url":"https://assets-cdn.github.com/images/email/message_cards/avatar.png","action":{"name":"Open in GitHub","url":"https://github.com/Ouranosinc/raven"}},"updates":{"snippets":[{"icon":"PERSON","message":"@julemai in #11: Yep. That setup should actually be in the manual of Raven. I have one example for GR4J for the York watershed. I will double-check with James on Monday if this has GR4J and Cemaneige properly setup and then I'll share it with you. \r\n\r\nIf you prefer one of your basins please send it to me and I use that one. "}],"action":{"name":"View Issue","url":"https://github.com/Ouranosinc/raven/issues/11#issuecomment-423700119"}}}
[
{
"@context": "http://schema.org",
"@type": "EmailMessage",
"potentialAction": {
"@type": "ViewAction",
"target": "https://github.com/Ouranosinc/raven/issues/11#issuecomment-423700119",
"url": "https://github.com/Ouranosinc/raven/issues/11#issuecomment-423700119",
"name": "View Issue"
},
"description": "View this Issue on GitHub",
"publisher": {
"@type": "Organization",
"name": "GitHub",
"url": "https://github.com"
}
},
{
"@type": "MessageCard",
"@context": "http://schema.org/extensions",
"hideOriginalBody": "false",
"originator": "AF6C5A86-E920-430C-9C59-A73278B5EFEB",
"title": "Re: [Ouranosinc/raven] Emulate MOHYSE in Raven (4) (#11)",
"sections": [
{
"text": "",
"activityTitle": "Julie",
"activityImage": "https://assets-cdn.github.com/images/email/message_cards/avatar.png",
"activitySubtitle": "@julemai",
"facts": [
]
}
],
"potentialAction": [
{
"name": "Add a comment",
"@type": "ActionCard",
"inputs": [
{
"isMultiLine": true,
"@type": "TextInput",
"id": "IssueComment",
"isRequired": false
}
],
"actions": [
{
"name": "Comment",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n"commandName": "IssueComment",\n"repositoryFullName": "Ouranosinc/raven",\n"issueId": 11,\n"IssueComment": "{{IssueComment.value}}"\n}"
}
]
},
{
"name": "Close issue",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n"commandName": "IssueClose",\n"repositoryFullName": "Ouranosinc/raven",\n"issueId": 11\n}"
},
{
"targets": [
{
"os": "default",
"uri": "https://github.com/Ouranosinc/raven/issues/11#issuecomment-423700119"
}
],
"@type": "OpenUri",
"name": "View on GitHub"
},
{
"name": "Unsubscribe",
"@type": "HttpPOST",
"target": "https://api.github.com",
"body": "{\n"commandName": "MuteNotification",\n"threadId": 340850537\n}"
}
],
"themeColor": "26292E"
}
]

MOHYSE documentation is added to the Wiki.
Matlab runs with NSE = 0.732655
Raven runs with NSE = 0.731842

I suggest we close this issue when a new release of RAVEN includes the MOHYSE emulator.

In theory, all we need is to get the dev version on the SVN. I doubt that a new release will be made available quickly enough for our needs?

I think if we kindly ask James, he might release soon. But I'm guessing he wants to release MOHYSE and HMETS together and not creating two releases.
So, I think as soon as HMETS implementation (and the PET thingy) gets resolved and confirmed, we will release.
Anyways, I think for the long-term you want to have access to the developers' code. There's this other ticket where I explained here how to get access. I also included it in the wiki.

I can also send you a copy of the current trunk in the meanwhile....

One release for MOHYSE and HMETS sounds good ! No need for the trunk just yet for me. Will let you know when I'm at that point.

OK great! Julie, I am looking at the HMETS code now, and it seems James is right, the version you have (and that is available on the file exchange) has the double RET calculation. No idea why it was never spotted... I have analyzed the situation and reported my opinion to François and Jean-Luc, but I suspect they will agree.
I'll get back to you shortly but I feel that this item is 99.9% of the way to being ticked.

Awesome!! Let me know and I will finish up documentation and template packaging ASAP. James is doing releases and he hasn’t committed the HMETS yet. But I’m sure he’s only waiting for your „go“.
This is exciting!


Updated "Build network," issue# 261

I updated the source of image here.

Updated the narration here.


Update certificate if issuer changes

What this PR does / why we need it: This makes cert-manager re-issue certificates if the issuer changes.
Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes #813
Special notes for your reviewer:
I noted a todo here that is a bit related and may affect how this should be done.
Release note:

Update certificate if issuer changes

Thanks for this 😄
/lgtm
/approve


cant go to company building v.50

im trying to go to company building to sell but the problem is when i type it and press enter it doesn't work it does anyone now a work around? otherwise i would love for this to be fixes!

got the same problem, i hope it's gonna be fix

so if you want there is a mod name AutoCompanyBuilding which automaticaly route your ship on the company building on days 0

so if you want there is a mod name AutoCompanyBuilding which automaticaly route your ship on the company building on days 0

I actually did find that mod but thank you. This seems to be the only fix rn so download this mod

Just download AutoCompanybuilding mod


Update BtcPay to 1.10.3

doing in branch changes110 - to be tested after fastpack. if not working revert to v1.9 versions (btcpay & nbx, webflow signer).

Manual update on v1.9 looking good.

https://www.nobsbitcoin.com/btcpay-server-v1-12-4/

Its now version 1.12.5

Installs on testing. Closing for ReleaseCandidate.


bumping js-slang

Pull Request Test Coverage Report for Build<PHONE_NUMBER>
Details

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 35.32%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
5194

Relevant Lines:
13742

💛  - Coveralls


Fix README.md - use SharedTestTrait in example

[x] Is this related to documentation?

Pull Request Test Coverage Report for Build 69

0 of 0 (NaN%) changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 78.141%

Totals

Change from base Build 68:
0.0%

Covered Lines:
311

Relevant Lines:
398

💛  - Coveralls


Normalize fields fix

Checklist

[x] Appropriate branch selected (all PRs must first be merged to dev before they can be merged to master)
[x] Any modified or new methods or classes have helpful JavaDoc and code is thoroughly commented
[na] The description lists all applicable issues this PR seeks to resolve
[na] The description lists any configuration setting(s) that differ from the default settings
[x] All tests and CI builds passing

Description
This PR supplements #371 by making NormalizeFieldTransformation.substitutions and NormalizeFieldTransformation.capitalizationExceptions not null if no default substitutions are specified in the configurations (at least an empty list is returned).

Looks pretty good, only comment is that the test doesn't really verify that it successfully returns a list with two objects for the JSON_LIST arg. I don't really find the parameterized test cases that useful here -- it might be more effective to have two tests: one that checks null input is an empty list, and one that checks that it parses JSON_LIST as Substitutions.

Right. Updated in https://github.com/ibi-group/datatools-server/pull/386/commits/06d46fe1bfb894d5faabf0fe6a8f3011f2233257.


Point added with addVertexOn is "jumping" upon zooming in or out

Hello,
When a vertex is added using the addVertexOn function, the point exhibits a "jumping" behavior upon zooming in or out.  The behavior disappears when we drag the map in any direction.

Step to reproduce

Navigate to the demo site.
Create a linestring
Add a point
Zoom in or out to observe the point "jumping".
Drag the map in any direction, then zoom again. The jumping behavior dissapear.

@MonfretAugustin we fixed the issue. It will be in the next release of the free version.


Use gnuplot from env

I get the following error when running the benchmarks:
$ make bench
[... omitted..]
dune exec --force tests/bench_append.exe > tests/bench.tsv && cd tests && ./bench.gp
Saving digest db.../bin/sh: ./bench.gp: /usr/bin/gnuplot: bad interpreter: No such file or directory
make: *** [bench] Error 126

This because I use the brew package manager on macos and gnuplot is NOT installed in /usr/bin but it is in my PATH. This is a 4 character fix in the bench.gp script header. Pull request incoming.

Thanks for the fix!


Improve OpenFGADatastore Memory storage implementation

Why?
We have people in the community bootstrapping OpenFGA datastores on startup and serving OpenFGA queries in production environments purely using the in-memory storage engine.
Overview
The in-memory storage implementation of the OpenFGADatastore  is not as efficient as it should be. It heavily makes use of a shared mutex that is shared across reads and writes. This causes contention on all operations even though we should only be experiencing contention if we're concurrently modifying a key that has an overlap with an existing query that is concurrently being executed (or vice-versa). Put differently, concurrent reads should not share a mutex, because that causes read contention for no reason.
We should re-implement our in-memory storage adapter to avoid such pitfalls by using a library such as https://github.com/hashicorp/go-memdb or something similar like https://github.com/tidwall/buntdb, etc.. These libraries both provide lock-free concurrent reads, and that's what we're trying to gain primarily.

Instead of using a third party library we could also update our existing code:

use RWLocks
have one RWLock per Backend Type
call Lock in writes and RLock in reads
reducing our critical sections.

As part of this task we should also consider reusing doing https://github.com/openfga/openfga/pull/1180#discussion_r1408152863. Get rid of memory.staticIterator in favor of the other generic static iterator in pkg/storage/iterators.go.

Ah my solution was assuming that most OpenFGA customers have only one store.

@jon-whit i was thinking about this issue. The Write API involves changing tuples and changelog at the same time for one store, so we will need to have synchronization across both arrays per store.


[ie/TV5MondePlus] Fix extractor

IMPORTANT: PRs without the template will be CLOSED
Description of your pull request and other information
This updates the TV5MondePlusIE extractor for the new URL and HTML structure of tv5monde.com.
Fixes #9118
A few open questions:

The new website does not seem to offer subtitles (at least I haven't found a video that uses them), so I have not been able to test if this part of the extractor still works.

While the extractor is called TV5 Monde Plus, this fixes the behavior for tv5monde.com, which is a different website.
In my region, tv5mondeplus.com redirects to tv5monde.com. Via a VPN I was able to access the plus version, which is a different website with a different structure. In the US it requires a subscription. As the page structure is different, I have my doubts that the current version of the extractor worked there. I have removed the tv5mondeplus.com URL from the extractor for now.
Maybe the TV Monde Plus site needs its own custom extractor and this one should be renamed.

If anyone knows more about the location of the subtitles, or has experience with TV Monde Plus, feel free to comment.
Template

Before submitting a pull request make sure you have:

[x] At least skimmed through contributing guidelines including yt-dlp coding conventions
[x] Searched the bugtracker for similar pull requests
[x] Checked the code with flake8 and ran relevant tests

In order to be accepted and merged into yt-dlp each piece of code must be in public domain or released under Unlicense. Check all of the following options that apply:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[x] Fix or improvement to an extractor (Make sure to add/update tests)
[ ] New extractor (Piracy websites will not be accepted)
[ ] Core bug fix/improvement
[ ] New feature (It is strongly recommended to open an issue first)

I think it's better to leave the current monteplus extractor as is for now and create a new TVMondeIE

@seproDev Thanks for the review. I made the changes you suggested.

Sorry, I took so long to get back to you. I was kind of dreading taking another look at the site, as the way they expose their metadata is pretty ugly. I have pushed a rework of the metadata extraction. Please take a look and verify that this makes sense.
I am specifically unsure about the title/series/episode distinction, but this is the best I came up with.


nixos/auto-upgrade: add persistent option

Motivation for this change
I am complaining about auto-upgrade not correctly working in laptop environment where laptop is turned on and off unpredictable causing those timers never expire and this service never executed.
Here is my fix.
I think that current situation is making this service unusable on laptops. Since it is auto upgrade that could lead to security issues as user might expect getting automatic updates while he is really not.
One can add this to his configuration.nix: systemd.timers.auto-upgrade.timerConfig.Persistent = true; but it is not apparent for users...
#15689
#75861
#107805
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[x] Fits CONTRIBUTING.md.

Oh, sure. Updated. Thanks!

I think the systemd.services.nixos-upgrade needs to be altered too to include after = [ "network-online.target" ]; (and maybe "network.target" too? I am not sure if only "network-online.target" is sufficient), otherwise the service will fail during restart because of the lack of network access.

https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/ says:
Cut the crap! How do I make sure that my service starts after the network is really online?

Well, that depends on your setup and the services you plan to run after it (see above). If you need to delay you service after the network is up, include

After=network-online.target
Wants=network-online.target

in the .service file.

So, I do what it says.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-already-reviewed/2617/317

I decided to give a try and test the PR to make sure everything is alright. My /etc/nixos/configuration.nix:
{
  # Backport module from unstable.
  imports = [
    /home/thiagoko/Projects/nixpkgs/nixos/modules/tasks/auto-upgrade.nix
  ];
  disabledModules = [ "tasks/auto-upgrade.nix" ];
  system.autoUpgrade = {
    enable = true;
    dates = "daily";
  };
}

And this is the result:
~/Projects/nixpkgs nixos/auto-upgrade 14s
❯ systemctl cat nixos-upgrade.timer
# /nix/store/qcv8x0xp01yn5zpz0nffk6y6zx7qdjn3-unit-nixos-upgrade.timer/nixos-upgrade.timer
[Unit]

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=0

~/Projects/nixpkgs nixos/auto-upgrade
❯ systemctl cat nixos-upgrade.service
# /nix/store/ivsfnlkw0ckf2s3qh7d12f795yq83hgj-unit-nixos-upgrade.service/nixos-upgrade.service
[Unit]
After=network-online.target
Description=NixOS Upgrade
Wants=network-online.target
X-StopOnRemoval=false

[Service]
Environment="HOME=/root"
Environment="LOCALE_ARCHIVE=/nix/store/a2px4kdz1jm03f8ifr1pzir0csfmyrlv-glibc-locales-2.31/lib/locale/locale-archive"
Environment="NIX_PATH=nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixos:nixos-config=/etc/nixos/configuration.nix:/nix/var/nix/>
Environment="PATH=/nix/store/z1qvlavy35wanw5k54fvvfffws5bvigj-coreutils-8.31/bin:/nix/store/xlfmnfbqryr6s52xgaqfaljmiccrv2rk-gnutar-1.32>
Environment="TZDIR=/nix/store/w1g27pgslf28nh1py1szj7lk4xksdhqq-tzdata-2020c/share/zoneinfo"

X-RestartIfChanged=false

ExecStart=/nix/store/h45gf360a2h7pbq86b2kvqmyxn9dsz75-unit-script-nixos-upgrade-start/bin/nixos-upgrade-start
Type=oneshot

So this seems :100: .

I decided to give a try and test the PR to make sure everything is alright. My /etc/nixos/configuration.nix:
{
  # Backport module from unstable.
  imports = [
    /home/thiagoko/Projects/nixpkgs/nixos/modules/tasks/auto-upgrade.nix
  ];
  disabledModules = [ "tasks/auto-upgrade.nix" ];
  system.autoUpgrade = {
    enable = true;
    dates = "daily";
  };
}

And this is the result:
~/Projects/nixpkgs nixos/auto-upgrade 14s
❯ systemctl cat nixos-upgrade.timer
# /nix/store/qcv8x0xp01yn5zpz0nffk6y6zx7qdjn3-unit-nixos-upgrade.timer/nixos-upgrade.timer
[Unit]

[Timer]
OnCalendar=daily
Persistent=true
RandomizedDelaySec=0

~/Projects/nixpkgs nixos/auto-upgrade
❯ systemctl cat nixos-upgrade.service
# /nix/store/ivsfnlkw0ckf2s3qh7d12f795yq83hgj-unit-nixos-upgrade.service/nixos-upgrade.service
[Unit]
After=network-online.target
Description=NixOS Upgrade
Wants=network-online.target
X-StopOnRemoval=false

[Service]
Environment="HOME=/root"
Environment="LOCALE_ARCHIVE=/nix/store/a2px4kdz1jm03f8ifr1pzir0csfmyrlv-glibc-locales-2.31/lib/locale/locale-archive"
Environment="NIX_PATH=nixpkgs=/nix/var/nix/profiles/per-user/root/channels/nixos:nixos-config=/etc/nixos/configuration.nix:/nix/var/nix/>
Environment="PATH=/nix/store/z1qvlavy35wanw5k54fvvfffws5bvigj-coreutils-8.31/bin:/nix/store/xlfmnfbqryr6s52xgaqfaljmiccrv2rk-gnutar-1.32>
Environment="TZDIR=/nix/store/w1g27pgslf28nh1py1szj7lk4xksdhqq-tzdata-2020c/share/zoneinfo"

X-RestartIfChanged=false

ExecStart=/nix/store/h45gf360a2h7pbq86b2kvqmyxn9dsz75-unit-script-nixos-upgrade-start/bin/nixos-upgrade-start
Type=oneshot

So this seems :100: .

@tex Can you fix the merge conflict?

@tex Can you fix the merge conflict?

@tex AFAIK we generally don't fix merge conflicts with merging other branches, but with a rebase.

@tex AFAIK we generally don't fix merge conflicts with merging other branches, but with a rebase.

And I though I get from this easily by doing web-based merge conflict solve :)

And I though I get from this easily by doing web-based merge conflict solve :)

So here you are and please merge it.

So here you are and please merge it.

@tex Now that #107959 can you fix the merge conflict again?
@SuperSandro2000 Do you know someone that can help reviewing this PR?

Still relevant.

@SuperSandro2000 Do you know someone that can help reviewing this PR?

Not really.

I am still interested in this PR. I can give a review/merge now.
@tex Sorry for the inconvenience. If you can rebase this PR I can review/merge ASAP.

But needs a rebase. After that i can merge it. Maybe i can rebase myself later today

@thiagokokada feel free to review and merge please :)

Thanks @Lassulus for the rebase.
Thanks @tex for the original PR.


Access to previous act data from a next act block

Not a bug but just a question/discussion about possibility.
Currently act block can access only data stored by the given block. In its turn data stored by (the last in case of overwriting) act block can be accessed only in the check block.
But what about access from act block to the data stored by previous act blocks? Currently it is not possible however it is easy to imagine possible scenarios for such possibility.
So wanted to ask if there are some conceptual limitations on this? If not probably it makes sense to add support for such access.

Sure this can be done. There isn't any conceptual block here. Again, for now you'll have to do that on a fork because I'm busy healing and on several pain meds. I wouldn't want to work even if I had my laptop with me.

Sure. I don't expect you to work on these issues now. It's just a list of things to work on regardless of who will solve them.

Implemented in 0.2.0 :)


[EventRequest] Add parameter to OnAfterIsPriceUpdateNeeded in codeunit 7020 "Sales Line - Price"

Hello, please consider adding the SalesLine parameter to the following event to codeunit 7020 "Sales Line - Price"
    [IntegrationEvent(false, false)]
    local procedure OnAfterIsPriceUpdateNeeded(AmountType: Enum "Price Amount Type"; FoundPrice: Boolean; CalledByFieldNo: Integer; SalesLine: Record "Sales Line"; var Result: Boolean)
    begin
    end;

Thanks!

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.
Build ID: 48695.


RFC: Updated Backstage Governance

Background
Backstage’s GOVERNANCE.md is largely inspired by the Envoy project, which has a large, broad maintainer team with individuals specialized in different areas, while we are a much smaller team and less specialized. We have been wanting to grow the maintainer team for some time, and have had multiple requests from contributors and contributing organizations that they want to become maintainers, but none of those discussions have ever really gotten off the ground.
🔖 Need
Becoming a maintainer is too hard
Our typical response when someone wants to become a maintainer is that they should make sure they are involved in the community, help out with support, review pull requests, and make significant contributions to core systems. After several months of presumably full time work, the maintainers are then supposed to confer and decide whether the contributor should become a maintainer or not. So far this process has never gotten off the ground, which isn’t too surprising.
We’ve had interested potential maintainers, but going from spending a bit of time on the side to dedicating most if not all of your working time for several months is a very tall order. The project has also grown a lot, and expecting someone to journey from an understanding of a few parts of the project to a complete holistic view before receiving any kind of ownership is unreasonable.
There is a strong need for an introduction of more steps in-between a new contributor and being a maintainer. An important part of this is to be able to slim down the scope and responsibilities that contributors take on, which can be done across a couple of different dimensions.
One might limit to fewer types of contributions, selecting a subset out of all the ways to contribute, for example through code, pull request reviews, issue refinement, UX design, community discussion and support, architecture, promotion and outreach, product management, documentation, and so on. All of these types of contributions are valuable and we want to make sure we encourage all of them, without making it a requirement to fill all those roles at once. The other dimension is what part of the project you contribute to, be it the core framework, specific plugins or integrations, the microsite, etc. Likewise, we want to make it possible to have a maintainer role with a more narrow scope and ownership of a smaller set of concerns.
Ownership model
Since the beginning of the Backstage Open Source project we’ve had squads at Spotify that own particular parts of the project. The most notable example of this is TechDocs that is owned by the Pulp Fiction squad at Spotify, who later on also have taken on the Search and Homepage plugins. Some other examples with owners from Spotify are the Kubernetes and Cost Insights plugins, and there are a couple more. Apart from these couple of plugins, the maintainers have been the owners of the rest of the project.
This ownership model has a couple of issues. Most notably at this point, the maintainers are overloaded and do not have enough bandwidth to review contributions to all parts of the project that they own, especially not while also trying to move the project forward. There have been some attempts to bring in reviewers and owners for some plugins, but it hasn’t worked particularly well. What I feel that what has been lacking is a more direct sense of ownership, as well as any tangible benefits. Being the owner of a plugin doesn’t help you become a maintainer, for example. There also aren’t enough processes in place to make isolated plugin ownership simple.
Another issue is that this current ownership model isn’t inclusive of the community, regardless of whether it’s new plugins built by squads at Spotify, or existing plugins that Spotify wants to support. This is both from the point of view that members of the community don’t have an opportunity to use the same kind of ownership model for their own plugins, but also that we don’t open up for community members to become maintainers of existing plugins. One of the things I feel is needed for this project to scale well is to be able to create sub-communities around different areas, and that’s not going to happen if there are fences keeping people out.
🎉 Proposal
This proposal includes a couple of updates, all intended to work well together and address the needs outlined above. They don’t dive into implementation details, we would handle that in eventual future pull requests that implement these proposals.
Contributor ladder
I propose that we introduce more steps in between first-time contributor and maintainer, in the form of a contributor ladder. This would be heavily inspired by the ladder in the CNCF Project Template, and we would add a similar document to the main Backstage repository. The purpose of the ladder is to introduce smaller steps, but also to make the requirements and responsibilities of each step as clear as possible.
By introducing the contributor ladder we make it possible to highlight many more members of the community, regardless of their particular type of contribution and amount of time that they’re able to invest in the project. These members also get the opportunity to get more involved in the project for each step up the ladder, with increased responsibilities and ownership.
We likely don’t copy the contributor ladder from the CNCF project template verbatim, but adapt it to fit our project. One particular change that I propose is to bump the project-wide responsibility up one step so that Maintainers own a specific project area. This is to allow for complete ownership of individual project areas, rather than just reviews. We then add Project Maintainers as another step, who are responsible for coordinating work across the entire project.
To give a quick and incomplete concrete example, the ladder might look as follows:
Contributor
This is a member of the community, there are no responsibilities other than to follow the Code of Conduct and Contributor Guidelines. Everyone is inherently a contributor if they are involved in the project.
Org Member
An org member is a frequent contributor that has become a member of the Backstage GitHub organization. In addition to the responsibilities of contributors, an org member is also expected to be reasonably active in the community through continuous contributions of any type. To become an org member a contributor must have a number of contributions of varying types, and also have been a contributor for a certain amount of time.
Reviewer
A reviewer is responsible for reviewing contributions to their specific areas of responsibility, and are expected to review a certain number of pull requests per year. To become a reviewer an org member needs to have reviewed or helped review a certain number of pull requests, demonstrated in-depth knowledge in their specific area, and be backed by the existing project area maintainers or project maintainers if it is a new area. Reviewers are also responsible for helping contributors become org members and reviewers.
Maintainer
Maintainers are owners of a particular project area, with project areas being a new concept that is introduced further down. They are expected to review and merge pull requests towards their area, and also drive development and manage tech health. A maintainer also needs to commit a certain number of hours per month towards the project, and exercise judgment for the good of the project, independent of their employer. Maintainers should also mentor new reviewers and participate in and lead community meetings related to their area. To become a maintainer one needs to have experience as a reviewer for a number of months, demonstrate a deep knowledge of their own area and how it fits into the larger Backstage project, and be backed by the existing project area maintainers or project maintainers if it is a new area.
Project Maintainer
Project maintainers are responsible for the Backstage project as a whole. They help review and merge project-level pull requests as well as coordinate work affecting multiple project areas. A project maintainer needs to commit the majority of their time towards the project, and exercise judgment for the good of the project, independent of their employer. Project maintainers should also mentor and seek out new maintainers, lead community meetings, and communicate with the CNCF on behalf of the project. To become a project maintainer one needs to have been the maintainer of a number of different project areas, demonstrate a deep knowledge of large parts of the Backstage project, and be backed by the existing project maintainers.
New ownership model
We divide the project up into several project areas, each covering particular parts of the project. The main driver for each area is ownership of code in the main Backstage repository, as well as other repositories in the Backstage GitHub organization. Each area has a set of maintainers, reviewers, and repository content that they own. There may be no overlap in ownership between areas, which is defined as multiple owners for a single line in the GitHub code owners file. Each area is represented by a team in the Backstage GitHub organization, and may be further divided into reviewer and maintainer teams. Apart from certain project-wide concerns, such as the release process, each area is self-governing and chooses their own ways of working. Project areas may also have special interest groups (SIGs) related to their area, but this is not required.
This RFC does not propose any particular project areas, leaving that for future discussions.
Each project area must have at least one maintainer or reviewer. A project area that only has reviewers is considered an incubating area where the reviewers are there to help drive work forward in the area but they might not yet feel ready to take on ownership. The goal should generally be that these reviewer(s) eventually become maintainers of the project area. This is to allow for a more smooth onboarding and transition of ownership, where members of the community might for example be new to open source maintainership.
The size of the project areas can vary and the intention is for them to evolve over time. An area might for example agree to take on new responsibilities, or large areas might be split into smaller ones. One type of area that may exist are “catch-all” areas where they own everything in a particular category that isn’t owned by someone else. One example might be an area that owns all source control integrations, except where another area owns the Azure integration.
Backstage Enhancement Proposals
This related proposal is handled in a separate RFC, as we want to keep the discussions separate.
〽 Alternatives
Split repositories
A frequent discussion topic among the maintainers is whether we should be splitting the project up into more repositories rather than to keep scaling the work in the main repository. We still don’t feel that we’re quite at the point where we feel comfortable pushing this forward, but would rather find ways to split ownership in the main repository for now. Long-term I think we will want to do both, but there are both technical and organizational hurdles that we’d need to overcome. Either way the core parts of the project that we would keep in the main repository are large enough by themselves that it makes sense to break things down into smaller areas.
SIGs
One alternative to the project areas is to lean more heavily into SIGs and make them the source of ownership instead. In the proposed model SIGs become an optional part of each project area, but there may also be SIGs for more horizontal concerns or multiple areas. One of the primary reasons for not making SIGs the starting point of project ownership is that they’re more geared towards getting people together to discuss and spread knowledge, rather than executing and moving development of the project forward.
Subproject Template
There’s a fairly new subproject template from the CNCF that #tag-contributor-strategy just released documentation for as I was done writing this proposal. There is a lot of overlap and I think we’ll be able to lean on many parts of the template in an eventual implementation of these governance updates. The template does however propose a structure of subprojects along with a steering committee. I feel that this structure might be something that we should consider further out in the future, but that it would be very tricky to move straight to that model. It’s mentioned in the documentation for the template that one of the requirements is that “the different subprojects share few or no maintainers”, and it will take us some time to reach that state.
CNCF Maintainer Contacts
The proposed contributor ladder gives the project maintainers the responsibility to “communicate with the CNCF on behalf of the project”. This effectively means that from the CNCF’s point of view, the project maintainers are the maintainers of the project. We don’t necessarily need to structure it this way though, and could instead for example lift up all or some of the project area maintainers to interact directly with the CNCF as well. I think starting off with the project maintainers likely makes sense, but it’s perhaps something we can tweak if we see a need further down the line.
❌ Risks
Maintainer workload
Rolling these changes out would further increase the workload on the maintainers and de-prioritize other ongoing work. In the end I feel that this is a necessary step. Of course one of the goals of these proposed changes is to scale the maintenance of the project.
Inactive Members
Something that inevitably will happen is that org members, reviewers and maintainers will become inactive. Of course it’s best to voluntarily step down in this situation, but there is also a process for handling inactive members in the CNCF project template that we would likely adopt.
Conflicts
With ownership being moved around and with a ladder to move up it is likely that there will be conflicts of different kinds. These are of course hard to predict but will need to be handled with care. It is important that the maintainers and project maintainers are equipped to deal with these situations and also have resources to lean on from the CNCF and other organizations.
Lack of non-code contributor roles
The proposed contributor ladder requires some form of ownership of code from the reviewer role and up. This would seem contrary to the highlighted need of more ways to encourage non-code contributions such as community support and outreach. The way I see this is that it’s best if there always is some form of ownership by all senior members of the community, but it may be in the form of guides, documentation, internal documents, and so on. For example, community members geared towards community management and outreach might own the backstage/community repository, while ones working towards developing strategies for adopting Backstage might own that section of the documentation.

So happy to see an active desire for getting help from the community to move the project forward. ❤
For the past few months, I have been asking similar questions to myself - what avenues do I have in front of me to help out. When I was at Spotify not so long ago, organizing backstage community sessions, doing discord support in weekly livestreams, occasionally joining "boss syncs" to look for opportunities to help, it was just a "Google Meet" away. Now, all of those ways have suddenly disappeared.
Perhaps a more direct ownership to some parts of the project as described above and some incentives can guide people (like me) who are looking to invest their energy but aren't exactly sure in what ways.

Another thought around maintainers being active/inactive in open source projects like Backstage is that if their employer is not willing to sponsor their open source contributions, they find it very hard to keep dedicating their time. Rarely anyone uses Backstage for their personal project :P - so as long as Backstage is even remotely related to anyone's full time work, it's easier for them to stay involved.
Maybe there is an opportunity to incentivize employers to sponsor such maintainers by letting them spend a percentage of their time on the project. This could be as simple as a page like https://backstage.io/sponsors or https://backstage.io/maintainers with their names and lines like "People from these companies are helping maintain the project." Very similar to the readme here https://github.com/kubernetes/steering

This is great, @Rugvip. I'm wondering if introducing the "Author" role makes sense at this point to highlight that not necessarily the "Author" has to "maintain" and that way encourage the "Maintainer" status.

This is an excellent step towards a more accessible path to maintainership.
It would be helpful to flash out and define what role SIGs are expected to play in the governance model. The current section shows that we currently need some clarity in this area.

One alternative to the project areas is to lean more heavily into SIGs and make them the source of ownership instead.

We can also lean into SIGs without tying code ownership to SIG ownership. Doing so would support the idea that we value all contributions, not only the ones that can be expressed as code.

One of the primary reasons for not making SIGs the starting point of project ownership is that they’re more geared towards getting people together to discuss and spread knowledge, rather than executing and moving development of the project forward.

This sentence sounds like SIGs are a channel for providing support. The Adoption SIG is explicitly not a support channel, as mentioned in the FAQ. We could make Catalog SIG more action-centric to help push some known issues.
Do you think we should break this out into a separate discussion or continue here?
In any case, excellent work on this RFC. I'm delighted to see this coming together.

@Rugvip I'm happy to see the team working on improvements to Governance! We have our Monthly CNCF Governance WG meeting this Thursday at 10:00am PST, and it would be great to have a couple of folks from the Backstage team attend to talk about this RFC! Details about joining the meeting: https://docs.google.com/document/d/1P9tQgCM6OwDHd1F8UnWuauL4KDVTMTp49_n64_w8nrs/edit?pli=1#heading=h.fdbtb24sf1jw
cc: @jberkus

@OrkoHunter yep, a list of contributors and their orgs would be part of the implementation of this for sure! 👍 We'd likely list reviewers, maintainers, and project maintainers.
@waldirmontoya25 I think an author would likely be a contributor or an org member, unless reviewer or maintainer for a particular section of the docs. I talk a bit more about that under "Lack of non-code contributor roles" as well. Does that sound like an alright middle ground or do you think me might need something extra in this space?
@taras to elaborate more on why I'm thinking it's best to keep SIGs separate: The main thing is I'd say SIG are by definition open, meaning they are supposed to be running some form of public forum where members of the community can join. I feel that's a big ask for a lot of project areas, and would rather have that as an optional extra for more well-established areas. Basically I worry the overhead of SIGs is a bit too high compared to their benefit. In addition, SIGs aren't really great for ownership by themselves and require additional structure similar to project areas on top. So in the end I feel SIGs fill an important role as a forum for discussing and aligning work throughout the community together with maintainers, but are an additional extra separate from project areas. SIGs are definitely not support channels. Does that address your concern?
@geekygirldawn thank you for having a look! Sorry we weren't able to join. Related to the comment in the doc I'd be happy to have a closer look at any other templates you recommend. I've had a close look at the contributor ladder one, as well as the subprojects template, which I discussed a bit in the alternatives section. I'm thinking we'll make a separate update to address the organization wording in the governance related to the Envoy roots. I'll also let you know as soon as we make a more concrete governance update proposal for this in the form of a PR.

Notes:
First, consider dividing up the contributor ladder and the other governance matters into two separate documents.

We divide the project up into several project areas, each covering particular parts of the project. The main driver for each area is ownership of code in the main Backstage repository, as well as other repositories in the Backstage GitHub organization.

Earlier conversations indicated that you wanted to get away from the model of having subprojects.  This section, though, suggests that you plan to embrace it, via a SIG system.

After several months of presumably full time work, the maintainers are then supposed to confer and decide whether the contributor should become a maintainer or not. So far this process has never gotten off the ground, which isn’t too surprising.

The other thing that helps is having clear, written criteria for exactly what a contributor needs to do to qualify for consideration as a maintainers.  This helps for several reasons: it's easier to work towards a goal if you know how close you are, it's way easier to get permission from your boss if they know what you're committing to, and it's easier for existing maintainers to evaluate new candidates if they have some clear criteria to work with.
The paragraphs in this RFC are a good start.  Consider borrowing from TAG-CS's contributor ladder which is an example of making things as quantitative as possible.

The template does however propose a structure of subprojects along with a steering committee. I feel that this structure might be something that we should consider further out in the future, but that it would be very tricky to move straight to that model.

Yeah, if it makes sense, the way to simplify that model is to simply make all subproject maintainers part of the general project maintainer group.  As long as the pool of maintainers is relatively small, that can work fine.

@Rugvip

The main thing is I'd say SIG are by definition open, meaning they are supposed to be running some form of public forum where members of the community can join.

Do you expect working areas to be closed? I've been in communities in the past where all of the decisions were made by small groups out of sight of the community. They would produce RFCs but those RFCs already eliminated many options and narrowed scope of feedback. It made the groups cliquy. The communities ultimately failed because formed echo-chambers and missed changes in the industry.

I feel that's a big ask for a lot of project areas, and would rather have that as an optional extra for more well-established areas. Basically I worry the overhead of SIGs is a bit too high compared to their benefit. In addition, SIGs aren't really great for ownership by themselves and require additional structure similar to project areas on top.

On the flip side, it can add more meetings and require more effort to broadcast information.

Does that address your concern?

I'm not sure. My primary concern is to ensure clarify on the relationship of SIGs and working areas. I'm not sure what is the best medium to do that - Backstage Contributor Sessions?

Aside,
CNCF Technical Advisory Groups has some interesting ideas. One thing that I like is "TAGs may choose to spawn focused and time-limited working groups to achieve some of their responsibilities (for example, to produce a specific educational white paper, or portfolio gap analysis report)." The ability to form temporary special purpose groups seems like a very nice feature of their Governance model.

CNCF Technical Advisory Groups has some interesting ideas. One thing that I like is "TAGs may choose to spawn focused and time-limited working groups to achieve some of their responsibilities (for example, to produce a specific educational white paper, or portfolio gap analysis report)." The ability to form temporary special purpose groups seems like a very nice feature of their Governance model.

WGs for TAGs are analogous to the Subprojects of SIGs in Kubernetes.  Kubernetes also has a concept of WGs which is different.  I think all of this may be fairly elaborate for Backstage though; consider that the project has about 30 people, total, who contribute 10 or more PRs a year.

@taras

Do you expect working areas to be closed? I've been in communities in the past where all of the decisions were made by small groups out of sight of the community. They would produce RFCs but those RFCs already eliminated many options and narrowed scope of feedback. It made the groups cliquy. The communities ultimately failed because formed echo-chambers and missed changes in the industry.

I expect them all to be reasonably open, especially to feedback and ideas, keep all contributions visible in PRs. I wouldn't expect all areas to do all their work out in the open and be running SIGs, it's a lot of overhead. One of the purposes of this structure is to allow for more lightweight ownership in order to make it possible for more members of the community to participate, even if they don't have buy-in to spend all of their working time towards Backstage OSS.
I think this is an area were we can evolve the setup as well. If we end up seeing that some areas are primarily operating behind closed doors, keeping the rest of the community in the dark, and that leads to problems, we can adjust our requirements on the project areas.

On the flip side, it can add more meetings and require more effort to broadcast information.

In my opinion our documentation and release process needs to be good enough for this not to be the case.

I'm not sure. My primary concern is to ensure clarify on the relationship of SIGs and working areas. I'm not sure what is the best medium to do that - Backstage Contributor Sessions?

I think continued discussion here is the best at this point to be honest. The relationship as it is proposed in this RFC is that project areas may choose to run SIGs, and there may be SIGs run that cover existing project areas. Exactly what is discussed and done in SIGs isn't enforced in any way at this point, SIGs are more akin to self organizing interest groups.

Heads up that we'll close this for comments on Feb 13th, and then move on towards an implementation. If you have any more comments, now's the time! 😁

@Rugvip any update on implementation?  Is there anything we can do to help get this moving?

@serenamarie125, @jhaals and I are moving this along, hopefully more to share soon 😁

Implementation proposal is now ready in #16740

Closing as this is now implemented :clap:


6.4 - Stackblitz examples don't link

Bug, feature request, or proposal:
The exact same problem happens again, but with different numbers, which is described here: https://github.com/angular/material2/issues/11568
"On angular material website, the stackblitz examples are inaccesible."
What is the current behavior?
clicking on example links returns
{"error":"UNSATISFIED_RANGE","data":{"name":"@angular/cdk","range":"6.4.4"}}
What are the steps to reproduce?
For example: https://material.angular.io/components/table/examples -> click on a stackblitz example icon

Closing as duplicate of #12662