The prebid.org Download PrebidJS page is refering to some modules incorrectly

The prebid.org Download PrebidJS page is refering to some modules incorrectly. https://docs.prebid.org/download.html

BritePool refers to britepoolIdSystem module that is not present in prebid js repo. Also https://docs.prebid.org/dev-docs/modules/userid-submodules/britepool.html mentions that "britepool is probably a defunct User ID system, as britepool.com is now an e-commerce site."
DeepIntent ID module referes to modulecode = deepintentIdSystem whereas actual module code should be deepintentDpesIdSystem @sourabhg
Adriver ID, modulecode = adriverId not present in repo

There might be more... how can we automate the validation?
When user selects the Prebid version, we can hide the modules that are not present in https://github.com/prebid/Prebid.js/blob/master/modules/.submodules.json?

https://github.com/prebid/Prebid.js/blob/22aa7ce4566aa53ef4976fbe462aadf1abe425dc/modules/adriverIdSystem.js#L21C1-L22C1 is in js @pm-harshad-mane ; what do you see?


sample code should be

certificates:
device_ca_cert: "c:\<path>\device-ca--full-chain.cert.pem"
device_ca_pk: "c:\<path>\device-ca.key.pem"
trusted_ca_certs: "c:\<path>\root-ca.root.ca.cert.pem"

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

ID: 94792ff1-5976-90f4-5092-0d8d8ff01635
Version Independent ID: d65482d2-64cc-56b1-c52a-b3ddde07b205
Content: Manage device certificates - Azure IoT Edge
Content Source: articles/iot-edge/how-to-manage-device-certificates.md
Service: iot-edge
GitHub Login: @kgremban
Microsoft Alias: kgremban

Thanks for the feedback! We are currently investigating and will update you shortly.

Hello @chris-han , I looked at the source code and found that config.yaml is using "\\" for homedir:

homedir: "C:\\ProgramData\\iotedge"

Do you have an error when using \\ ?
Thanks

Hi @chris-han , let us know the answer to the above question to proceed the troubleshooting.
Thanks!

Since we have not heard back from you we will now proceed to close this thread. If there are further questions regarding this matter, please tag me in your reply. We will gladly continue the discussion and we will reopen the issue.


Updating readme.md to have network.json part of 2015-06split tag

Microsoft.Network/2015-06-15/network.json is a partial spec and it does not make sense to exist on its own. it has to be part of 2015-06split tag.
I

No modification for AutorestCI/azure-sdk-for-python

No modification for AutorestCI/azure-sdk-for-node

No modification for AutorestCI/azure-sdk-for-ruby


Google Chat left click on links not working

Left click on links in chats is doing nothing (it should open the link in system browser). Right click + Open link works.
Tested on version 5.6.2 and 5.6.3 under linux.

Duplicate of #1501


1.21.3 support fabric please

Is your feature request related to a problem? Please describe.
I wanted to use your awesome PlayerAnimator (it's great ngl) and I noticed that is not compatible with 1.21.3. So there are particularly two problems. #121 and the the getPlayerAnimLayer is not useable with the newer version (I think the class_742 has another name now but I'm not sure.
Describe the solution you'd like
So I would highly appreciate a 1.21.3 Fabric port :). Thanks in advance!

@RaphyTwin a port is already in progress by one of the contributors
The main author of the mod isn't super active so I don't know when it will be released on the maven, but you can check out this fork and build it yourself in order to use it. (IT'S NOT READY YET!!!)
Please close #121 because that error is simply because the library isn't released for 1.21.3 yet

Whenever the port is ready it should end up on this maven repository first before KosmX's one:
        maven {
            name "dima_dencep"
            url "https://repo.redlance.org/public"
        }

Okay, thank you very much :). Btw Merry Christmas

Thanks :)
Also I talked to KosmX and she decided that she wants to make the port on her own
So forget everything I said, just wait very patiently!

Ok, good to know. Only a question (because I want to know in what time range) how long will she approximately take to port it? Thanks in advance

Don't know how long will it take, probably it will be done in a few days.

@RaphyTwin you can build the 1.21.3 branch for a fabric version.
MC had a lot of changes in render API, and I also replaced a lot of mixins for better ones.
The first person animation is completely broken (as of now), but it can be used to port mods depending on this, as the API is already fixed.
bendy-lib compatibility is also removed, the compatibility layer will be moved into bendy-lib (for easier maintenance)

if you don't use bendy, it won't affect you

you can build the 1.21.3 branch
Maybe you could publish an alpha version on your maven? 🙏


admin right needed now?

Hello there!
I am using Anaconda 5.0.1 on windows 10. and I noticed that running conda update conda will fail without admin rights. It used to be the case I was able to run all the conda update suite (-anaconda, -conda, -all) without admin rights.
Is this expected?
Thanks for your help

This is an Anaconda problem. Please report it in its appropriate place:
https://github.com/ContinuumIO/anaconda-issues/issues/


Support multiple runs.

This currently changes only the gmm eval and the Futhark tool.

Marking as draft for now since CI is currently failing.

This is designed to be minimally invasive and strictly speaking does not require any protocol extension. It also turns out the generated from_dict methods are lenient regarding bonus fields.

@athas could you fix the merge conflict?


Fastlane builds failing in CI

See e.g. https://github.com/soundscape-community/soundscape/actions/runs/5945776471/job/16125363745
@Oliver2213 was this working before, or are there still missing pieces that need to be filled in?

@2kai2kai2 Is this something that's easily fixable?

Not sure. I have a few ideas as to what it might be:

Pods compatibility issues
Signing issues
Something with localization

Can we run the workflow again on the most recent version to see if it was the first one? (and has potentially been resolved by the removal of cocoapods?)

Good call -- the app does report building successfully now, but it fails at the upload stage since we're still using @Oliver2213's credentials: https://github.com/soundscape-community/soundscape/actions/runs/6714118429/job/18246849543
Will need to update the email here, and a runner environment variable somewhere: https://github.com/soundscape-community/soundscape/blob/main/apps/ios/fastlane/Appfile#L2

Some guides suggests best practice is to use an App Store Connect API key, rather than a username/password, to authenticate Fastlane in a CI build. The Apple docs indicate that only an account admin can generate the key, and although it can have limited privileges, it can't be limited to a single app. Because we're currently using an Apple Developer account for a broader organization, this limitation might be prohibitive. I'd still like to have this process not tied to anyone's individual account. Maybe we should make an Apple ID out of the shared<EMAIL_ADDRESS>email address and use that to publish builds?

I looked through the Fastlane docs and came to the same conclusion. They recommend a dedicated apple id with the app manager role (needed by the fastlane match  command), and an API key for uploading builds from Github actions.
There might be some hacky way to get round it with xcode automatic signing, but two factor authentication makes it difficult.
Perhaps the best we can do just now is to modify the Fastlane configuration to use Xcode automatic signing to ease the process of releasing testflight builds by developers, even though it wouldn't work in Github actions.

To clarify the above, Xcode automatic signing is the only way to upload builds for Testflight or the Appstore without the app manager role, and Xcode automatic signing requires Xcode to be signed into an Apple Id, which it isn't when running on Github Actions.


Replace ContainerLabelTagMapping.controls_tag? with Tag.controlled_by_mapping scope

More efficient and necessary for https://github.com/ManageIQ/manageiq-providers-kubernetes/pull/162 mapping in graph refresh.
Links
Overview/plan: https://github.com/ManageIQ/manageiq-providers-kubernetes/issues/126
This is necessary to complete containers graph refresh, BZ:
https://bugzilla.redhat.com/show_bug.cgi?id=1470021

@miq-bot add-label enhancement gaprindashvili/yes

@miq-bot add-label performance, gaprindashvili/yes
Yeah, I should benchmark.  Wanted something that works at all first :-)

Also, I hope later to move to simpler query on tag prefix, but not before some refactorings, that'd be g/no.


"stress_test" doesn't seem to add any studies

I've run a few times and added quite a few plates but still only have a single study

The creation of studies is outside the scope of labman and that's why it doesn't include it. if run on maptest it will take advantage of all the studies present on the DB.


drivers: serial: bt: Use dedicated Work-queue

Description
Add dedicated NUS Work-queue since the System Work-queue no longer supports Blocking BT TX APIs (and for a good reason).
The default Priority is set to Main Thread and Stack-size 1KiB, but can be adjusted through Kconfig configuration.
Fixes #72019.

@dcpleung may I get a review on this PR?


could not find the source blob

Getting this error when trying to create the app with Heroku.

could not find the source blob

When I click the README links from Heroku I get a 404, so I'm wondering if the links in the app to GitHub need updated.

Yes, I am having this problem as well.

Interesting, can you try this link instead: https://heroku.com/deploy?template=https://github.com/LandonPatmore/yahoo-fantasy-bot/tree/master and see if that works?

Interesting, can you try this link instead: https://heroku.com/deploy?template=https://github.com/LandonPatmore/yahoo-fantasy-bot/tree/master and see if that works?

Yep, that solved the deployment error. Thanks!


Ticket by mail

Although this is probably not an easy task I suggest this anyway:

Option to create a ticket tag for each user. (Simple button: 'Create/Renew ticket tag')
Ticket tags are simply a random number with at least 10 digits. the longer the better.
2 Users should be able to send a mail to a predefined mail adress (Configurable from within the tinyissue administration) using their 'ticket tag' in the beginning of the subject: like this

'388576636: There's an error when creating a user'
and some text in the mail.

New mails are simply polled from the mail account when logging in as 'manager' or administrator'

I actual have implemented  a prototype for this feature when I was using the old version of TinyIssue. I used it for short time, then removed the code. I was worried about the possibility of generating spam issues.
Can revisit this feature later.

Hey, I think this idea was actually quite good. I think there are however several possibilities to prevent spam.

Use an automatically generated ticket-tag per user and per day.
Limit the mail ticket to a certain number of mails per ticket-tag and per hour
Only accept mail if certain keywords are matched:
for Example:

Subject:
Report: 23940234 whatever the user wants to report
Mailtext:
Text: whatevery else is there to say.
whereas "Report:", the daily ticketID and the word "Text:" are keywords which must be given at exactly this position.


Protobuf 3 and google.protobuf.Timestamp type

Upgrading protobuf dependencies to 3.1.0 which is the latest stable. It is backwards compatible with the existing implementation that uses uint64 for timestamps. The type is checked at parsing time, and the relevant method is called to extract millis, so the rest of the system should continue to work as expected.
If the tests look good, I can merge them into the same protobuf file to minimize confusion later.

Looks good.  Thanks for the contribution.


Hey Shaun - great job on this project, any chance of swift wrapper?

Unlikely we'll do anything with this related to Swift directly (if anything, it'd get a full rewrite in Swift) -- but once Xcode 7 goes GM, we'll update to the latest objc changes that should make it look native alongside your Swift code.


Any reason why the header size is not 5

https://github.com/Microsoft/vscode/blob/5c5f93cdbcc763b94ed996d73ed4e5329e60d7a8/src/vs/base/parts/ipc/node/ipc.net.ts#L28
From my looking at the format, it appears one byte is spent to mark either isJson or not and another 4 bytes on the 32 bit length integer, giving a total of 5 bytes.
I wonder why don't we just save the extra 12 bytes per message and reduce the header length to 5 ?

good question. might be some leftover from other work...


Add support for any JSON type when suggesting values in Results

This is one half of the work needed to support arbitrary value suggestions.  I will follow up with a PR to kustomize as well if needed.  Closes https://github.com/GoogleContainerTools/kpt/issues/747.

Had to merge in changes from master and resolve a few merge conflict, but nothing major changed so feel free to merge at will @prachirp  :)


Add KML and KMZ support

Add support for loading KML to the map as well as converting KML to ee.FeatureCollection

This feature has been implemented. Four new functions have been added.

kml_to_shp()
kml_to_geojson()
kml_to_ee()
Map.add_kml()

Dear Dr. Wu.
How about supporting kmz? In most cases we have kmz files. It's easy to
change kmz to kml, but we need to change them manually.
On Wed, Dec 30, 2020 at 10:26 AM Qiusheng Wu<EMAIL_ADDRESS>wrote:

Closed #247 https://github.com/giswqs/geemap/issues/247.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/giswqs/geemap/issues/247#event-4156124351, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AE5J3HQLSD6KGOPHWLA4QY3SXKFTRANCNFSM4VNXYRYQ
.

Dear Dr. Wu.
How about supporting kmz? In most cases we have kmz files. It's easy to
change kmz to kml, but we need to change them manually.
On Wed, Dec 30, 2020 at 10:26 AM Qiusheng Wu<EMAIL_ADDRESS>wrote:

Closed #247 https://github.com/giswqs/geemap/issues/247.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/giswqs/geemap/issues/247#event-4156124351, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AE5J3HQLSD6KGOPHWLA4QY3SXKFTRANCNFSM4VNXYRYQ
.

@bangqianchen Yes, I guess I can add KMZ support as well

@bangqianchen Yes, I guess I can add KMZ support as well

KMZ support has been added. See this example.
https://user-images.githubusercontent.com/5016453/104735692-e9964f00-570f-11eb-9682-698754e43ded.mp4

KMZ support has been added. See this example.
https://user-images.githubusercontent.com/5016453/104735692-e9964f00-570f-11eb-9682-698754e43ded.mp4


Merge light-dark() into color-scheme?

https://github.com/web-platform-dx/web-features/pull/727 added color-scheme, prefers-color-scheme, and light-dark() as 3 separate features.
In https://chromium-review.googlesource.com/c/chromium/src/+/5756571 @lilles gave the feedback that light-dark() depends on color-scheme, and that it would have been shipped together if was in the spec at the time.
The reason this isn't trivial is that it would remove two features, and we haven't done that yet since v1.0.0. Should we leave the features as some kind of tombstone entries with the meaning "I was merged into color-scheme, redirecting there would make sense"?

https://github.com/web-platform-dx/web-features/pull/1552/files shows what just merging the three features from https://github.com/web-platform-dx/web-features/pull/727 would look like.
In terms of Baseline date, prefers-color-scheme predates color-scheme by 2 years, and light-dark() arrived 2 years after.
I guess that prefers-color-scheme should remain a separate feature, and that the question is how web developers think about color-scheme and light-dark().
@bramus as the author of https://web.dev/articles/light-dark can you weigh in on how these groups of features is best split or merged in a way that makes sense to developers?

I don't like the idea of merging features that shipped so far apart. Such data manipulation makes web-features completely unusable for us in projects like cssdb, postcss-preset-env, polyfill-library, ... We really need accuracy.
I think it would be more interesting to have separate bundles of features that are somehow related. A bundle of "things affecting and affected by color scheme" would be a very nice living document.


Instructions on how to cross compile Windows (amd64 -> arm64)

Since this was a rather annoying process and I thought maybe it would be helpful, I will share my steps on how I was able to successfully build (still haven't tried to consume but even getting an output is a win) an arm64 static openblas library on windows amd64.

Load into the appropriate cross compiling developer shell (in my case powershell but for cmd.exe it would be vcvarsamd64_arm64.bat):  & 'C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\Tools\Launch-VsDevShell.ps1' -Arch arm64 -HostArch amd64
Invoke the following CMake, based primarily on the example for arm64 -> arm64 in the wiki:  cmake .. -G Ninja -DCMAKE_BUILD_TYPE=Release -DDYNAMIC_ARCH=0 -DTARGET=ARMV8 -DCMAKE_CROSSCOMPILING=ON -DCMAKE_SYSTEM_NAME="Windows" -DARCH=arm64 -DBINARY=64 -DCMAKE_SYSTEM_PROCESSOR=ARM64 -DCMAKE_C_COMPILER=clang-cl -DCMAKE_C_COMPILER_TARGET=arm64-pc-windows-msvc -DCMAKE_ASM_COMPILER_TARGET=arm64-pc-windows-msvc.  Notable additions include using clang-cl instead of clang, and adding in the _COMPILER_TARGET entries.  Without C_COMPILER_TARGET, clang-cl will be trying to compile x64 machine code and not make it past the cmake generation step.  Without ASM_COMPILER_TARGET the assembly files in openblas will fail to assemble because the assembler is trying to interpret them as x64 assembly.
ninja and profit!

Thank you very much, I will copy it to the wiki (shame we had to lock it down, there were just too many link spam and phishing edits). Which version of LLVM/clang did you use for the crossbuild ?

This is the clang-cl / LLVM that ships as part of the latest Visual studio 2022 (not sure if the toolchain version will differ between patch releases or not, it is currently 17.8.3) -> 16.0.5.

Ah great, thank you, so no separate installing of llvm necessary.

Hmmmm probably not in the way you envision, but it is an optional part of Visual Studio.  The visual studio component Microsoft.VisualStudio.Component.Llvm.Clang must be installed.

Thanks, got it now (I hope).


RFC git signatures (kill, simplify or status quo)

Problem
Related to RFC #2856.
Currently we have the following commit message directives (see here):
Signed-off-by
Reported-by
Co-authored-by
Improved-by
Acked-by
Tested-by
Reviewed-by

You can broadly categorise them in two types:

directives related to giving credit (co-authored-by, reported-by)
directives related to quality stamping (reviewed-by, signed-off-by)

For new contributors it's not easy to know which to use when, and additionally it's not clear if the differences in signatures is actually used.
Proposal
Simplify the possible commit directives to:

Signed-off-by - (Related to quality) Used by authors, testers and reviewers to sign that a given commit adheres to Invenio's quality standards and to the best of their knowledge is ready to be merged.
Co-authored-by - (Related to credit) Used to acknowledge significant co-authorship including when a person significantly improves the code after the original author left.

and exceptionally:

Reported-by - Use only in exceptional circumstances, when there's no GitHub issue (could happen when an external user reports a bug report via email, and not issue was created).

Note: Tester/reviewers should only sign commits they can fully confirm the quality off. Blanco signing of commits may negatively impact their merit and credibility. For commits to be considered for integration a minimum of two Signed-off-by signatures are needed. That a commit is considered for integration, does not mean the commit actually will be integrated.

@inveniosoftware/developers please read it carefully and let us know your opinion. Thank you!

This is indeed simpler :+1:

:+1:

Some additional notes and precisions:

For new contributors it's not easy to know which to use when

This is not a problem in my eyes due to three reasons.  Firstly, our QA signatures are well documented.  Secondly, we are using standard signatures known e.g. from the Linux world.  Thirdly, the development tools usually offer all these signatures out of the box, e.g. Emacs's git-modes provides:

C-c C-s inserts Signed-off-by (`git-commit-signoff')
C-c C-a inserts Acked-by (`git-commit-ack')
C-c C-t inserts Tested-by (`git-commit-test')
C-c C-r inserts Reviewed-by (`git-commit-review')
C-c C-o inserts Cc (`git-commit-cc')
C-c C-p inserts Reported-by (`git-commit-reported')

So even if new developers don't know these "standard" signature conventions upon their arrival, they can learn it quickly from the documentation, it can be a useful knowledge for them for other personal git based projects, and putting proper signature is very cheap operation, just a keystroke away.

additionally it's not clear if the differences in signatures is actually used.

This is the core of the RFC to me.  We now have basically three QA signatures coming from reviewers, each denoting different confidence level, in the increasing order of quality:

Acked-by
Tested-by
Reviewed-by

Considering the high turnover of developers, these might be useful, for example imagine someone bisecting some code written by somebody else N years ago;  the person may want to know whether the code was reviewed only lightly or really carefully.
So the core question of this RFC is: do we make use of this confidence level distinction in real life or not?  If we do, it it worth keeping, because it is both cheap and standard.  If we don't, it is worth simplifying to only Signed-off-by.  Note that this could mean going for the highest QA standard that this signature implies, because it won't be possible to tell anymore a tester from a reviewer.

Tester/reviewers should only sign commits they can fully confirm the quality off.

With one kind of sign-off signature only, it will be impossible to tell whether John acted as a tester here or as a full reviewer when he signs.  OT1H, this difference could be important in hunting bugs N years from now, as mentioned above.   OTOH, if we don't make use of it, and if don't have an armada of separate testers in the team, and if people always tend to deeply review rather than only test, then this distinction is not so important.
Here are stats about the current usage:
$ git log master | grep -c Acked-by:
30
$ git log master | grep -c Tested-by:
259
$ git log master | grep -c Reviewed-by:
651

additionally it's not clear if the differences in signatures is actually used.

This is the core of the RFC to me.

I agree this is the core of the RFC. Do we actually use it. In my opinion I don't think we use it, or if we ever used it, the added value is so little that it does not justify the added complexity.

For new contributors it's not easy to know which to use when

This is not a problem in my eyes due to three reasons.

While I agree that signature are documented, that we use standard signatures and development tools can easily be customised to add, I don't agree that it is not an issue to be considered (e.g. signature documentation is linked from CONTRIBUTING.rst, but otherwise hidden towards the bottom of a 19-page document).
I believe we need to lower the friction for contributing to Invenio, and any complexity that can be removed from the process contributes overall to lower the entry barrier. I'm not saying that regular contributors (e.g. CERN developers) should not learn to do things properly, just that as a first-time contributor you should feel encouraged to continue contributing  (and this independently of if you are a super programmer or a newbie).

In my opinion I don't think we use it, or if we ever used it

So far we haven't made much use of the distinction, I think.  Often, knowing the person who signed is enough.  However, the real value of signatures may be revealed in future bug hunting, where people don't know original developers and reviewers anymore.
From this point of view, we are generating signatures to simplify life to future developers, so the real value of QA signatures is more longer-term.  Consider future developer D who does not know the original developer O and the original reviewer R and whether R's signature usually meant only light testing, or deep reviewing.  (and consider that D would like to correct some bug in the original code instead of rewriting it from scratch :smile:)

added complexity

If you test, you press C-c C-t when writing commit message.  If you review, you press C-c C-r.  If you sign with your blood, you press C-c C-s. That's not very complex?
(Otherwise yes, the presentation in the documentation can be improved, and setting up the entrance barrier appropriately, neither too low nor too high, is an important and delicate matter...)

setting up the entrance barrier appropriately, neither too low nor too high, is an important and delicate matter...

(speaking of which, going for a single highest-quality signature (Signed-off-by) may actually increase the barrier, if people cannot use some lower-quality signatures (such as Tested-by) to get the code integrated)

Complexity is at many different levels. I consider repeatedly writing Signed-off-by/Reviewed-by: as a kind of low-level complexity that can be automated as you say with short cuts. A higher level of complexity is the semantics/processes of it and when to use which signature for what. If you only have one signature, you only have one thing to learn and one thing to remember.

Consider future developer D who does not know the original developer O and the original reviewer R and whether R's signature usually meant only light testing, or deep reviewing.

Probably I lack direct experience on this, but does this distinction matter in the end, as wouldn't developer D anyway look at the current issue and fix it at hand regardless if it was lightly reviewed or not before?

may actually increase the barrier

For my own clarification, I guess it is increased barrier for the reviewer/integrator as the developer will  anyway add signatures as directed by reviewer R to update the PR.

In short, no developer should own any piece of code, and therefore it should not be necessary to drill down on who signed it.
What I do not get is how signatures help track down bugs. And btw, we already have the author's email, which essentially is the same as signed-off-by?
When faced with a bug, you do not care who wrote it, you care about why it was done and why is was done this way. (I agree that sometimes it is convenient to talk to the developer who wrote it, but this should not form the development cycle). Information about that specific piece of code should be clear from the issues and pull requests created and referred to by the commit.
Previous comment mentioned that it is interesting to have a review-off, but I disagree, it should be clear from the PR who reviewed it and how extensive the review was.

it should be clear from the PR who reviewed it and how extensive the review was.

There is the same issue like we had with labels. If you are debugging/bisecting off-line one might prefer not to go out of the terminal and a single commit might not have PR or issue number mentioned.
Personally, I would like to see 2+ names of people in the commit message that take responsibility for given commit. If we talk about 2x Signed-off-by or Signed-off-by + (Reviewed|Tested|Acked)-by it's not so important as long as developers understand the signature meanings and don't sign "carte blanche".

A higher level of complexity is the semantics/processes of it and when to use which signature for what.

I touched above on the decision strategy "which signature for what".
It seems simple enough to me.  Presuming people instinctively know the
difference between testing what the branch promises (i.e. did it fix
the add-to-basket bug on Opera?) vs reviewing the branch code
(i.e. reading, understanding, and suggesting improvements to every
line of code), the decision tree seems rather simple to me:

Have you only tested the feature?  Use "tester" signature.
Have you also reviewed the code in detail?  Use "reviewer" signature.

Do you have an example whether the decision tree would be more complex than that?

If you only have one signature, you only have one thing to learn and one thing to remember.

... but you also express only one level of engagement with it.  Which
is why I'm probing whether this is enough.

Probably I lack direct experience on this, but does this distinction
matter in the end, as wouldn't developer D anyway look at the
current issue and fix it at hand regardless if it was lightly
reviewed or not before?

In theory, D could look at the code and only the code, and find the
bug that way.  In practice, there is a practical difference in getting
to fix the problem faster, if you know who did what parts and who
approved it.  (Kind of social engineering meets computer engineering.)
If people study both the code and the authors and the reviewers, they
can better estimate which parts were well reviewed, and which parts
were not.  This may help speeding up the bug fixing.
The role of multi-level signatures here is the following.  OT1H, if it
is enough to know that Joe did this thing and Jane "approved" it, we
can simplify signatures to Signed-off-by only.  OTOH, if it is
useful to know that Jane only tested, but not reviewed, the code, then
we may prefer to stick to the current decision tree that we have in
place now.
The above real-life numbers show that we have 259 testing signatures
vs 651 reviewed signatures.  The difference does not look negligible,
hence I'm probing into respective pros/cons...

For my own clarification, I guess it is increased barrier for the
reviewer/integrator as the developer will anyway add signatures as
directed by reviewer R to update the PR.

Yes.  The original developer only uses Signed-off-by signature when
he/she prepares the branch.  The reviewer will then let the original
developer know whether to add Acked-by, Tested-by, or
Reviewed-by seal of approval before the branch gets merged.  This
means roughly three things: (1) newcomers use Signed-off-by only
anyway, so the entrance barrier is not really there; (2) it is the
reviewer who decides upon his level of involvement, from light (just a
tester) to heavy (full reviewer); (3) proposing to use Signed-off-by
for reviewers also would raise the entrance barrier to get the feature
branch integrated indirectly, because people would have to look for
reviewers, not only for testers or "ackers", before the branch may be
accepted.  This is what I had in mind.

Personally, I would like to see 2+ names of people in the commit message that take responsibility for given commit. If we talk about 2x Signed-off-by or Signed-off-by + (Reviewed|Tested|Acked)-by it's not so important as long as developers understand the signature meanings and don't sign "carte blanche".

:+1: Fully agree on the general principle of necessitating 2+ signatures for any PR branch; I've been only probing whether the "one-signature-style" model is sufficient or not WRT possible future needs.
(BTW, in the Linux kernel world, people often use both multiple Signed-off-by, but also occasional Reviewed-by and Acked-by etc.)

So let's mention only Signed-off-by in CONTRIBUTING.rst with link to "advanced" rules.

Easy and short reading for newcomers;
Knowledgeable developers/testers can express what actions they have made;
Integrators can keep internal karma points per signature.

And btw, we already have the author's email, which essentially is the same as signed-off-by?

We have been using it slightly differently.  Signed-off-by is a
quality stamp, meaning that you stand behind your code. Quoting from our conventions:
Signed-off-by
    The author says, in essence: "I have carefully implemented the
    feature without any leftover to-be-fixed places, I have run all
    code kwalitee checks and all relevant unit and functional tests,
    and everything is good. To the best of my knowledge, this commit
    is good to go into the fast merge track"

It's perhaps worth mentioning that our use of Signed-off-by as a quality stamp is different from e.g. Linux/git's kernels use where it is used to certifies that you wrote it or otherwise have the right to pass it on as an open-source patch (i.e. as a way to sign a contributor agreement to protect against law suits from e.g. SCO).
A particular weakness I see with our signatures is that they are all added by the author because he/she is the only one who can update the pull request. The signature would have a lot more value if in fact it was done by the persons themselves instead of the commit author. Also, to me it seems like in Linux/Git it's mainly a remnant from sending patches around via email, where it's the maintainer/reviewer/tester themselves that signs a commit.
While I agree with the general principle of necessitating 2+ signatures for any PR branch (i.e. more than 1 person has reviewed the code), I'm not sure the commit signatures is the most effective way. I tend to agree with @frecar that it's only through the PR comments you get the real nuances of how well reviewed the code was and by how many. Also, our automated travis/kwalittee checks will report any violations.
In either way it seems like a compromise between no signatures vs many would be using only Signed-off-by and Co-authored-by as signatures?

I tend to agree with @frecar that it's only through the PR comments you get the real nuances of how well reviewed the code was and by how many.

Sure, one has always go to the PR to see the details about some past issue.   That's natural, but that's also the bottom of the stack when hunting a bug.  Consider two things:

Unstructured information in PR reviews.  When someone writes "LGTM" or "shipit", you cannot extrapolate whether this was a brief look, a feature test, or a detailed code review.  Having convention about using separate Tested-by and Reviewed-by signatures introduces common vocabulary that permits to distinguish these cases.

(The question is will we care?  Looking at the current usage, 259 test signatures vs 651 review signatures, seems to indicate that the difference is important.)

Lack of easy local overview in the future bug hunting.  When one reads the commit log range SHA1a..SHA1b, if the commits also contain QA information, one immediately has a good overview of what commits do, which features or bugs they fixed, and also how this was tested.  This is more efficient when compared to having to look up everything in the issue tracker individually.

(We had similar arguments in RFC #2856 about where to store the description of new features and compatibility notes etc, whether in the commit logs or in the issue tracker.)

It's perhaps worth mentioning that our use of Signed-off-by as a quality stamp is different from e.g. Linux/git's kernels

Yes, we say that in the docs.  (BTW the fact that people might see Signed-off-by lightly seems more as an argument in favour of keeping separate Reviewed-by QA stamps...)

Unstructured information in PR reviews vs structured signatures:

I think even with definitions of Tested-by and Reviewed-by it will always be a subjective decision which one to use, except if there would be a yes/no recipe for what to run in your terminal. Hence, I don't think it's any better than looking at the commit description, the code and the pull request comments.

(The question is will we care? Looking at the current usage, 259 test signatures vs 651 review signatures, seems to indicate that the difference is important.)

Looking into who made those signatures I don't think it's possible to make the conclusion that the difference is important:
(zenodo)pb-d-128-141-95-181:invenio lnielsen$ git log master | grep Tested-by: | sort | uniq -c
   9     Tested-by: Esteban J. G. Gabancho<EMAIL_ADDRESS>   1     Tested-by: Georgios Kokosioulis<EMAIL_ADDRESS>  12     Tested-by: Jan Aage Lavik<EMAIL_ADDRESS>   3     Tested-by: Javier Martin Montull<EMAIL_ADDRESS>   6     Tested-by: Jiri Kuncar<EMAIL_ADDRESS>   2     Tested-by: Ludmila Marian<EMAIL_ADDRESS>   1     Tested-by: Petr Broz<EMAIL_ADDRESS>  17     Tested-by: Samuele Kaplun<EMAIL_ADDRESS> 206     Tested-by: Tibor Simko<EMAIL_ADDRESS>   2     Tested-by: Yoan Blanc<EMAIL_ADDRESS>(zenodo)pb-d-128-141-95-181:invenio lnielsen$ git log master | grep Reviewed-by: | sort | uniq -c
   1     Reviewed-by:  Jiří Kunčar<EMAIL_ADDRESS>   4     Reviewed-by: Alessio Deiana<EMAIL_ADDRESS>   2     Reviewed-by: Charalampos Tzovanakis<EMAIL_ADDRESS>   7     Reviewed-by: Esteban J. G. Gabancho<EMAIL_ADDRESS>   1     Reviewed-by: Georgios Kokosioulis<EMAIL_ADDRESS>   2     Reviewed-by: Gilles Louppe<EMAIL_ADDRESS>  39     Reviewed-by: Jan Aage Lavik<EMAIL_ADDRESS>  43     Reviewed-by: Javier Martin Montull<EMAIL_ADDRESS>   1     Reviewed-by: Javier Martin Montull<EMAIL_ADDRESS>   2     Reviewed-by: Jerome Caffaro<EMAIL_ADDRESS> 223     Reviewed-by: Jiri Kuncar<EMAIL_ADDRESS>   5     Reviewed-by: Jiří Kunčar<EMAIL_ADDRESS>   1     Reviewed-by: Joe Blaylock<EMAIL_ADDRESS>   2     Reviewed-by: Kamil Neczaj<EMAIL_ADDRESS>  33     Reviewed-by: Lars Holm Nielsen<EMAIL_ADDRESS>   2     Reviewed-by: Ludmila Marian<EMAIL_ADDRESS>   2     Reviewed-by: Ludmila Marian<EMAIL_ADDRESS>   2     Reviewed-by: Samuele Carli<EMAIL_ADDRESS>   1     Reviewed-by: Samuele Kaplun<EMAIL_ADDRESS>   1     Reviewed-by: Samuele Kaplun<EMAIL_ADDRESS>  55     Reviewed-by: Samuele Kaplun<EMAIL_ADDRESS> 219     Reviewed-by: Tibor Simko<EMAIL_ADDRESS>   3     Reviewed-by: Yoan Blanc<EMAIL_ADDRESS>

Lack of easy local overview in the future bug hunting

I think you have to compare this to how often it is actual necessary. Personally I'm it's only when I'm on flights/trains that I'm coding and being offline, i.e <1% of coding time. And also, I'm never relying on the signatures for bug hunting. The only use I can see is that I could possibly ask the person questions (but I'll always try the commit author first).

(We had similar arguments in RFC #2856 about where to store the description of new features and compatibility notes etc, whether in the commit logs or in the issue tracker.)

The purpose I think is different. In #2856 the descriptions has a clear purpose for being used to generate release notes (important if want to transition to time-based releases)

(BTW the fact that people might see Signed-off-by lightly seems more as an argument in favour of keeping separate Reviewed-by QA stamps...)

It's in the eye of the beholder :-) I see this exactly opposite, as an argument in favour of abandoning signatures.

While I agree with the general principle of necessitating 2+ signatures for any PR branch (i.e. more than 1 person has reviewed the code), I'm not sure the commit signatures is the most effective way. I tend to agree with @frecar that it's only through the PR comments you get the real nuances of how well reviewed the code was and by how many. Also, our automated travis/kwalittee checks will report any violations.

Additionally, for a developer, to go around and collect signature is not always obvious. Plus, e.g. imagine I am reviewing someone else code: I would have to ask the developer to add my reviewed-by signature, and rebase and repush. This involves many iterations, and sometime the developer is not available and the PR get stuck. This really adds to to the complexity.

I think you have to compare this to how often it is actual necessary. Personally I'm it's only when I'm on flights/trains that I'm coding and being offline, i.e <1% of coding time. And also, I'm never relying on the signatures for bug hunting. The only use I can see is that I could possibly ask the person questions (but I'll always try the commit author first).

Exactly: when doing bug hunting (which I do a lot), I have basically used bisect 0.1% of the time, and from that using the signatures was really not necessary at all... Basically the signatures are more needed at integration time, and not for debug time. And Github is always there the most part of the time.

Looking into who made those signatures I don't think it's possible to make the conclusion that the difference is important:

Look at Jan for example:
12     Tested-by: Jan Aage Lavik<EMAIL_ADDRESS>39     Reviewed-by: Jan Aage Lavik<EMAIL_ADDRESS>
If there is only Signed-off-by, then one wouldn't be able to tell the difference anymore.  This is an example of "important difference", since ~25% of Jan's signatures were of testing nature and ~75% of reviewing nature.
(If another developer does say ~5% tests and ~95% reviews, then the difference when compared to a single-signature world is not important.)
This is what I had in mind that our real-world usage shows "important differences": we don't use only one signature predominantly, we use frequently both.  (259 tests, 651 reviews)

The purpose I think is different. In #2856 the descriptions has a clear purpose for being used to generate release notes (important if want to transition to time-based releases)

The purpose is different, but the choice is similar.  One can store structured information about features (and about QA stamps) either in the git commit logs or in the issue tracker.  And one can generate release notes (and QA stats) from either as well.

It's in the eye of the beholder :-) I see this exactly opposite, as an argument in favour of abandoning signatures.

Then the RFC should be amended to "kill all signatures" :smile:

Killing all signatures would be a great step forward.

To sum I think we have the below options in play (correct me if not):
Common for all options
I haven't seen anyone against keeping the Co-authored-by signature for giving credit to significant co-authorship, and possibly also keeping Reported-by for some few exceptional cases.
Please correct me if I'm wrong.
Option 1 - Only signed-off-by.
Reduce to only use one signature  Signed-off-by
Option 2 - Multiple signatures (as it is today)
Acked-by
Tested-by
Reviewed-by
Option 3 - Kill signatures
(except for Co-authored-by and Reported-by).

It seems that there's no consensus, so how do we proceed? DevForum discussion? Quick +1 poll (only guiding to get a feel for developers opinion)?

Then the RFC should be amended to "kill all signatures" :smile:

Indeed now that there are more options in the RFC :-)

Quick +1 poll (only guiding to get a feel for developers opinion)?

+1 for Option 3. Given the limited added value, I would go for killing the signatures, but letting developers add them if they feel like it.

It's not an important issue to me, but I think that another valid suggestion might be making signatures optional. If sb wants other developers to know that he tested the code before merging, he adds Tested-by, otherwise he doesn't.
Still, it would be nice to always include Co-authored-by and Reported-by everywhere where it applies.

This involves many iterations, and sometime the developer is not available and the PR get stuck. This really adds to to the complexity.

Yeah, finally this dance adds more complexity then it's worth. Since we introduced the signatures, I have not seen any significant value in it from my own experience (apart from  Co-authored-by and Reported-by).
If we are casting votes, I'd favor Option 3 - e.g. keep it optional. However, I suggest to discuss it in some upcoming dev forum.

I'd say Option 3, signing my own commit always felt a bit redundant to me.
Maybe in this context might make sense Reviewed-by (or other) just to reflect in the commit that a different pair of eyes looked at it.

Option 3

+1

Plus, e.g. imagine I am reviewing someone else code: I would have to ask the developer to add my reviewed-by signature, and rebase and repush.

Yes, that's indeed what's happening, a cons of the fast-forward-merging model.

Exactly: when doing bug hunting (which I do a lot) [...] using the signatures was really not necessary

The same here.  As I mentioned above, it is usually enough for me to know which person was involved in the given commit (test/review difference is not important).  But I guess we @kaplun are not the usual example, since we are involved with the project since many years, and recall the projects and  persons involved... Hence I've been probing the pros/cons from the point of view of "future developers".

Basically the signatures are more needed at integration time, and not for debug time.

Yes, for the integration purposes, Signed-off-by is usually enough.  (Provided that people use it how it was intended.)

signing my own commit always felt a bit redundant to me.

Did you have a habit of always running kwalitee and invenio-check-branch on your branches before making pull requests?  If everyone did, then signatures wouldn't have been introduced in the first place :smile:

It seems that there's no consensus, so how do we proceed? DevForum discussion? Quick +1 poll (only guiding to get a feel for developers opinion)?

Please stop voting :-)
My intend was not to call for poll on this issue, merely to get opinions on how we proceed since there's no consensus. I believe we must strive to get consensus on this issue (a majority vote is of no use), so a poll is only usable to get a feeling for where everyone stands.

Quick +1 poll

...

Please stop voting :-)

Did you have a habit of always running kwalitee and invenio-check-branch on your branches before making pull requests

Since this is now part of the CI service on GitHub and therefore more visible, signing should not impact it? Anyway, if I submit a PR (or put it out of WIP) it is given that me as the author think its good to go. Then CI/reviewers will take over and prove me wrong :-)

@jalavik I work the same way. I have local kwalitee git hooks installed (+editor warnings) to catch most stuff during development, but otherwise rely on CI service to do the final check.

I personally would go for Option 3 (maybe keeping as well Reviewed-by)
Signed-off-by does not provide any given value as it is being used at the moment, as everybody is doing by default git commit -s without considering what the real meaning is.
I personally also test and do kwalitee locally and once I remove the WIP to the best of my knowledge, the branch is ready to go.

I personally would go for Option 3 (maybe keeping as well Reviewed-by)

@jmartinm If you were to keep Reviewed-by how would you use it? For crediting or as quality stamp? Just thinking that option 3 + keeping reviewed-by (as quality stamp) sounds more like a variant of option 2.

@jmartinm If you were to keep Reviewed-by how would you use it? For crediting or as quality stamp? Just thinking that option 3 + keeping reviewed-by (as quality stamp) sounds more like a variant of option 2.

I was thinking about crediting. Reviewing takes a significant amount of time and effort so it is nice to have your name in the commit.

Since this is now part of the CI service on GitHub and therefore more visible, signing should not impact it?

Yes, the automated kwalitee run via CI plays an important role.  We seem to drift a bit from the original "social" use case towards "single-author" use case, but as this is tightly related indeed, let me answer in quite some detail.
I agree fully with your statement especially for smaller projects such as Flask-Menu, where we rely on CI green/red light for everything, because we have extensive test cases covering most of the code base, and we run even pep257 check as part of the Travis CI build.  When a build fails because pep257 was not respected, the PR does not get merged.  We can say that the code kwalitee is fully exposed and checked as part of the "merge process".
However, for the Invenio package itself, we are not there yet.  We are only approaching this situation asymptotically.  Consider the following points: (in increasing order of difficulty)

[easy] Kwalitee for legacy does richer testing than kwalitee for master.  (For example run_sql() checking, which may still be important for legacy modules in master; see past discussions like this one). Technologically, this is easy to solve, we just have to enrich kwalitee tool enough to cover everything we may want to cover.

[easy plus social] Looking at past PRs, there were often cases where the CI builds indicates failure, yet the branch was merged.  This is due to kwalitee failing because it is checking the complete file PEP-8 compliance, while we have many holes there.  Technologically, we can solve this by amending kwalitee and paying attention only to differences that the given branch brings (as we do in legacy kwalitee), for example.  Sociologically, the kwalitee CI green/red light in PRs seems to be disregarded though because of this problem. It is mostly the test results that seem to be looked at in the CI. Socially, can we say that people are relying today on all kwalitee findings from CI and fixing them as part of the merge?

[harder] Speaking of the importance of tests, in legacy, there are quite a lot of additional acceptance/functional/regression testing being done as part of CI due to the presence of the demo site.  In master, with Invenio as a "true" library framework, it does not make sense to run these, they were separated away into invenio-demosite package.  However, the moved-away tests are not fully represented yet in the Invenio core framework code base.  So when someone pushes a feature requests, we don't know whether it was tested in the core only, or in some overlay conditions only, or in more overlays, and whether the PR does not break our example vitrine, the Invenio demo site.  Technologically, this is harder to solve, because the best would be obviously to enrich Invenio core package test suite itself in order to cover much more use cases. (Plus we have additional demo site Jenkins nightly job for nightly testing.)  Practically, adding new tests to cover the full code base takes time; we are not there yet.  So, paradoxically, one could muse that master may be "less tested" than legacy today, due to split-away demo site.  Hence usefulness of possibly capturing QA signatures to express these "external conditions" while we are getting there.

[only social] The current discussion seems to have turned more into what QA signatures the original author should use for himself, and that self-signing-for-kwalitee shouldn't be really necessary anymore.  While I agree that this is asymptotically solvable by richer kwalitee run with richer test suite and richer coverage, the CI process cannot express the notion that X tested the branch or Y reviewed it or that it runs on Z production system.  This is a matter of social conventions only, hence target of this RFC.

In summary, while we are probably in full agreement that richer kwalitee/tests/coverage in combination with CI findings can kill the necessity of signing one's own commits to indicate "self-kwalitee" -- and we are already there for Flask-Menu and friends -- what we perhaps disagree about is how far we are from this ideal state with Invenio package itself.  Asymptotically speaking, we are getting there, but we are not there yet.  However, even when we get there, we may need to express any notion of "social review" manually; hence the question of whether capturing the review process into some formal signed-off-by/tested-by/reviewed-by system is still useful of not.

Option 3 [...] but letting developers add them if they feel like it

Option 3 - e.g. keep it optional

Option 3 [...] make them optional

Please note that the signatures are already optional and have always been optional; quoting from our conventions:
The authors can use the following commit signature directives in order
to highlight the quality of the patch at hand before requesting its
review and merge [...]

Here is the list of QA directives that the author may use: [...]

The purpose of signatures was simply to indicate higher QA to help the integration process, and, by calling attention to QA matters, to help spreading good practices in our teams;  quoting from our contributing guide:
If you tested your code thoroughly and stand by its perfection, use
Signed-off-by commit QA stamp. If you reviewed the code created by
others, use Reviewed-by QA stamp. Helps to get them onto fast
integration track.

In this light, how is "Option 3 [...] make them optional" different from the status quo text where the signatures are already optional?
I think the description of various RFC options would benefit from refinements...

In summary, while we are probably in full agreement that richer kwalitee/tests/coverage in combination with CI findings can kill the necessity of signing one's own commits to indicate "self-kwalitee"

Yep.

... but we are not there yet (for Invenio)

Right. It is true that as CI rely heavily on tests and our coverage is in the lows (15-20%?) coupled with some missing kwalitee features from legacy. This is an issue we have to address. However, I am still convinced that the "merge process" for future PR's to master is not reliant on the Signed-off-by.

where the signatures are already optional

In terms of submitting PR's to 2.0 this has in practice been required. cc @jirikuncar Probably not for legacy, though.

Sociologically, the kwalitee CI green/red light in PRs seems to be disregarded though because of this problem.

I am not an integrator, but as a contributer, I can say that for contributions to master code, kwalitee is not disregarded (except in those cases when touching legacy code).
I guess overall we have seen a difference in the "merge process" between legacy vs master code contributions.

In terms of submitting PR's to 2.0 this has in practice been required

That was also my impression. In this case there was a difference between theory and practice.

In terms of submitting PR's to 2.0 this has in practice been required

Yes, I asked every contributor to fix kwalitee issues and sign their commits whenever they are done. Unsigned commits raised a flag that I need to be extra careful with the commit as contributor probably hasn't read the CONTRIBUTING.rst guidelines or simply hasn't paid enough attention to the commit.
Recently I would say that all regular contributors are following the guidelines and the extra signature check contributed to better awareness of existing rules. Hence personally I find it useful.

I would propose keeping current rules, but shorten and simplify all contributing rules.

simple checklist (max. 10 points);
extended version where each rule can be explained in more details;
CONTRIBUTING.rst should state that contributor agrees to donate his code under terms of Invenio licence and he agrees with new code of conduct.

this has in practice been required

I see what you mean. When we agreed upon not only recommending PEP-8 and friends (as in legacy), but also requiring it (as in master), we also discussed making all the various kwalitee checks more or less mandatory... and signatures came along in the process.  Anyway, let's take this occasion and streamline both the docs and the practices.

Unsigned commits raised a flag that I need to be extra careful [...]

Yes, exactly as in the legacy world, I found signatures useful.  However, if people do git commit -s when on autopilot, then this is actually harmful.  Asymptotically, the difference may not matter; but here-and-now, it still does.  Let's brainstorm IRL about all the various options proposed here and let's see what we can come up with...

new code of conduct.

(BTW I'll send a separate PR about "Code of Conduct", outside of the forthcoming "Community" docs section refactoring #1799)

So isn't the conclusion should be "write more tests and add more code analysis checks" ? (http://radon.readthedocs.org/en/latest/intro.html)
I agree with @jirikuncar, contributing rules should be short and succint ( Can be expanded dropdown style if needed) , otherwise it is like CGI .... not read.
Signed-off-by -> Doesn't bring more information (git blame)
Reported-by -> Doesn't add information if the commit message contains link to issues
Co-authored-by -> As Signed-off-by (git blame)
Improved-by -> As Signed-off-by (git blame)
Acked-by -> ???
Tested-by -> Say that it works in the specific configuration of the tester, it is information but partially junk.
Reviewed-by -> I think it is the only one which can bring information in terms of management ("who else knows this module when the original guy went away"), also work not visible in git blame (cf @jmartinm  point).

How can I get "Co-authored-by" from the "git blame" output?

You can't ! My bad, wrote it too fast.In case of peer programming there is no other way than adding it. Otherwise if a rebase overwrite authorship it is whatever, bad.

How can I get "Co-authored-by" from the "git blame" output?

You can't ! My bad, wrote it too fast.

Depending on the code editor, this should not be too far away from people's fingertips.  For example, in Emacs, when you visit a file, you can annotate it via C-x v g, and then on an interesting line press l to bring a pop-up with full commit message, including signatures.  (Another option is to use magit-blame-mode where the full commit message is also just a keypress away.)

There is no objection against Co-authored-by and Reported-by as they help to overcome a built-in git limitations. Signed-off-by comes from Linux kernel era when patches were/are sent around, which is not our case. The more we simplify the commit message, merging process and engineering bureaucracy, the more contributions will emerge, thus helping us to be a real open-source project, and not just a open-source-licensed project.

Depending on the code editor, this should not be too far away from people's fingertips. For example, in Emacs, when you visit a file, you can annotate it via C-x v g, and then on an interesting line press l to bring a pop-up with full commit message, including signatures. (Another option is to use magit-blame-mode where the full commit message is also just a keypress away.)

This does not apply to the question. You are speaking about an Emacs function, not a git blame information. Therefore, Co-authored-by is a valid signature that we should keep (as optional, of course), but I feel that you are agreeing with me on this one.

The more we simplify the commit message, merging process and engineering bureaucracy, the more contributions will emerge

The goal behind our QA practices is not the red tape; it is to make the final product more robust.

Therefore, Co-authored-by is a valid signature that we should keep (as optional, of course), but I feel that you are agreeing with me on this one.

Yes, we fully agree on this one; we probably disagree about the usefulness of (optional) Tested-by/Reviewed-by signatures.
My point about git blame was the following.  I presume that people don't really use git blame in its "raw" state, but rather through their code editors.  (If not, then they should :smile:)  Here, one has richer "blame" functionality at one's fingertips.  E.g. I find it useful that I can do C-x v g l RET and see almost everything about the given line of code: not only when it went to the codebase and who authored it (the usual "blame"), but also who tested-it and who reviewed-it (thanks to QA signatures), and what was the announced user-level purpose (thanks to #2856 labels).  This is one of the advantages of having rich commit log messages, as opposed to storing this information elsewhere.  People have all the information at their fingertips in their code editors, as opposed to having to look things up through independent news file or in an external issue tracker.  (The cons being that the git commit message is "set in stone" after merge, but we discussed these pros/cons in #2856 already.)

Now the https://github.com/inveniosoftware/invenio/issues/2876#issuecomment-81612605 is starting to make more sense with #2900. We should also try to simplify the CONTRIBUTING guidelines.

We should also try to simplify the CONTRIBUTING guidelines.

Yes, this will come as part of #1799.  After we gather existing scattered documentation in the consistent set of reST pages, the simplification and interlinking will be able to follow more easily.

The goal behind our QA practices is not the red tape; it is to make the final product more robust.

To make this very explicit, I mentioned above in detail why QA signatures were introduced and why they are still interesting for Invenio, as opposed to say Flask-Menu, where we could in theory replace QA signatures with a rule like:

A branch is not considered for merge unless it preserves or increases the code coverage.

We wouldn't be able to do that in Invenio just as yet.  So, if you don't like self-signatures indicating QA status, and if you like the idea of making the final product more robust, what about aiming at making the self-signatures obsolete by enriching our test suite?

:+1:

what about aiming at making the self-signatures obsolete by enriching our test suite?

:+1:

what about aiming at making the self-signatures obsolete by enriching our test suite?

:+1:
I feel like we have actually managed to get to the real problem. Is there some specific plan on this?

what about aiming at making the self-signatures obsolete by enriching our test suite?

:+1:, but what about PRs that don't contain Python code? For example purely js PRs?

what about aiming at making the self-signatures obsolete by enriching our test suite?

I'm not sure if I fully understand current state of this RFC. Does it mean that we are getting rid of all signatures besides Co-authored-by (optionally) and as a compensation we will try to work on our test suite?

For example purely js PRs?

Isn't that the same applies here for js - enriching our test suite? (see: jasmine ext)
Additionally (I don't think it is a standard in Invenio now, but maybe we already have some rules on that which I'm not aware of?) I feel like jslint or jshint or eslint should become standard way of checking quality of js code.

Isn't that the same applies here for js - enriching our test suite? (see: jasmine ext)

I agree, but is there a way to make coverage check both Python and js code?

coverage for js code?

e.g. http://blanketjs.org/

"A branch is not considered for merge unless it preserves or increases the code coverage."

I feel like we have actually managed to get to the real problem.

Good then! :smile:

Is there some specific plan on this?

Individually, let's take resolution to commit and live by the above principle already, i.e. always improving code coverage with every local branch from now on.  TDD for the win!
Collectively, I'd be all for organising a common hackathon to improve code coverage. Who's in? I could probably contribute some tasty poppy seed cakes and fine green tea.  We can discuss this at one of our next developer forums...

Would this mean that relatively small PRs (small additions and bug fixes) would also need some accompanying (and somewhat unrelated) tests for it to be accepted?
It sounds nice, but I can absolutely see this increasing the threshold for contributing.

small additions

Should come with tests where it makes sense.

bug fixes

For typos or wrong imports it's not necessary, however it shows that that piece of code is not covered by tests, hence adding simple test case would be very welcome. On the other hand we should not make any exception for bug fixes in "business logic".

I'm @jirikuncar, if you have a valid use case that should be properly handled but it is not, IMHO together with the bug fix must come a test to cover your use case.

I'm @jirikuncar and I approve this message. :wink:

@blixhavn There's an order of PR readiness, so to speak, from "preserving or increasing code coverage" at the top of the scale, through "having two or more review signatures" in the middle, down to "unsigned unreviewed untested" at the botom.  The top of the scale is very integration-ready and can be almost self-merged; the latter is very integration-unready and can be almost self-rejected.  We'll probably always have PRs that fill the whole scale, but we'll encourage the top-end practices and discourage the bottom-end practices. Hence, to get a PR integratquickly, one knows what one has to do.  I'll document the process in a RTFD checklist.
@egabancho @greut I like the tripling of @jirikuncar :smile:


Weird ws PubSub behaviour

I'm not entirely certain if this bug is specific to the js wrapper but thats what I'm testing with.
I am on Node LTS (v18.17.0) and latest uWebSockets.js.
My code is essentially the included Broadcast example with this as the open handler:
ws.subscribe("foo/wildcard/#");
ws.subscribe("foo/normal");

setTimeout(() => {
  ws.publish("foo/wildcard/bar", "broadcast ws");
  ws.publish("foo/normal", "normal ws");
}, 1000);

setTimeout(() => {
  app.publish("foo/wildcard/bar", "broadcast app");
  app.publish("foo/normal", "normal app");
}, 2000);

I would expect to receive 4 messages whenever I connect, however, in reality, all I receive is the bottom-most one

I spotted this issue because I'm building a new app and was trying to use a Wildcard subscribe, however never actually received anything that I publish. Eventually I figured out that Wildcards just seem to not work whatsoever, and while building this testcase also spotted that publishing on the ws doesnt work either for me.

v20.0.0 - Massively simplified & improved pub/sub

Support for MQTT wildcards has been removed

Oh, I see. Its been a while since I used uws last and I missed that that happened. I guess I'll have to figure out a workaround, thank you.
As a Sidenote, the PubSub example still includes Wildcards which is why I assumed it should just work


FIX44Enumerations.CxlRejResponseToValues

Value '2' should be called OrderCancelReplaceRequest
http://www.onixs.biz/fix-dictionary/4.4/tagNum_434.html

The same applies to all FIX versions, btw.

I agree that it is confusing.
The enumerations are generated based on the FIX Repository, which specifies a description and a symbolic name for each value. For CxlRejResponseTo(434), the value 2 has the description "Order Cancel/Replace Request" and, for some reason, the symbolic name OrderCancel.
Any thoughts on this?

I think "Order Cancel/Replace Request" means "Order Cancel Replace Request" 😄
In our use case value '2' is only used on a order cancel reject originating from an order cancel replace request.

Yes, indeed. The values in the FIX Repository are as follows:

Value
Symbolic Name
Description

1
OrderCancelRequest
Order Cancel Request

2
OrderCancel
Order Cancel/Replace Request

So I'm kind of blaming the FIX Repository here. (Maybe they generate the symbolic names from the descriptions, and their generator breaks down at the slash).

Cool ok makes sense in this case if it agrees with the FIX repo, even though I also think the slash tripped the generator up 💣

Maybe Philadelphia's code generator could generate an OrderCancelReplaceRequest alias here...


Test is failed with RuboCop HEAD

A method signature of autocorrect_source has been changed  by https://github.com/bbatsov/rubocop/pull/4510 .
So the test for rubocop-rspec is failed with next version RuboCop.
This problem can be avoided by one of the following methods.

Drop rubocop 0.49.1 or older support if rubocop 0.50.0 is released
Pin rubocop version with 0.49.1 or older
Check Method#arity for autocrrect_source method.

This way supports both rubocop versions, but it's a workaround.

Nice. I just noticed while working on a rubocop PR that a few things are failing on the latest master. What I usually do is just make then new release be constrained to the latest rubocop release. Easiest that way.


Blue line in the middle of the cell

Testing #141222
There seems to be a blue line appearing in the middle of Markdown cells after I click near the bottom edge of them:

Yeah, you focused the status bar. Doesn't look great but is by design basically.


chore: make yarn ocnfiguration safer

Make yarn install check integrity of installed files
Add audit information to output of yarn install

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

AWS CodeBuild CI Report

Result: SUCCEEDED
Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository


Release 1.7.1

Checklist

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

@conda-forge-admin, please rerender

@conda-forge-admin, please rerender

OK, that last re-render got me back to the default boost and boost-cpp versions in .ci_support.  I've added a migration file in recipe/migrations per https://github.com/conda-forge/cfep/blob/main/cfep-09.md and the libboost migrator in conda-forge-pinning-feedstock.
@conda-forge-admin, please rerender


Filtering NVARCHAR column is missing "N" when using string literal

Hi,
I've a very simple Forum entity:
public class Forum
    {
        public int Id { get; set; }
        public string Name { get; set; }

        public string Description { get; set; }

        public virtual List<Post> Posts{ get; set; }
    }

And nothing extra related to Forum in the OnModelCreating method.
EF correctly generates Name as NVARCHAR(MAX) and filtering with a variable generates the correct SQL:
var var = "דורון";
var scoops = _context.Forums.Single(x => x.Name == var);

exec sp_executesql N'SELECT TOP(2) [x].[Id], [x].[Description], [x].[Name]
FROM [Forums] AS [x]
WHERE [x].[Name] = @__var_0',N'@__var_0 nvarchar(4000)',@__var_0=N'דורון'

But when I use a string literal:
var scoops = _context.Forums.Single(x => x.Name == "דורון");

EF generates the following SQL:
SELECT TOP(2) [x].[Id], [x].[Description], [x].[Name]
FROM [Forums] AS [x]
WHERE [x].[Name] = 'דורון'

Note that the parameter is treated as VARCHAR instead of NVARCHAR

Using RC1
The generated SQL was taken from SQL Server profiler.

@smitpatel by the way, I tried to SQL inject myself with
_context.Forums.Where(x => x.Name == "1' or '1' = '1").ToList();

But EF escapes the ' even if the parameter is a string literal so it didn't work... :smile:

@gdoron - Its good to know EF stops SQL injection. :smile:
The cause of the issue is we do not have type information about the constant used in the query. And string type constant is generated in SQL as is. While it is not easy to infer if the string constant is varchar or nvarchar, we may possibly need another function to specify either of them and use the other as default (that's what we did in EF6 I think).
There is sadly no work-around for it now. The only way is to use the parameter.

@smitpatel Isn't it possible to always treat the string literal as NVARCHAR even if unicode isn't needed just like as when using a string parameter?
Why should they differ?

@smitpatel @gdoron From what I remember besides the EntityFunctions.AsNonUnicode() and EntityFunctions.AsUnicode() methods in EF6 we actually had some logic that tried to figure out the right value for the Unicode facet based on certain common patterns, e.g. if there is an expression of the form SomeNonUnicodeColumn = SomeLiteral then we know that we can render the literal as non Unicode by borrowing the facet from the column.
I think that kind of inference for simple patterns is what we should try to do here. To @gdoron's point I think it is probably a good idea to default to Unicode literals when we can't figure out better.

What problem does the merge for this solve besides the generated sql being more syntactically correct.
From what I read using a non Unicode string in the predicate maintains compatibility between varchar and nvarchar indexes.  Adding the N'. By default breaks varchar indexes as sql server cannot do 16bit to 8bit conversion on the predicate and has to  upsize all the index from 8 bit to 16 bit.
If we leave the parameter or literal non Unicode it can do 8bit to 16bit conversion of the paramter which in the case of a large index is 1000s of times faster

@mikes-gh it is not just a syntax error, the query won't yield results in case of non Unicode characters.

@gdoron
Thanks I understand now.
The following issue made it clearer to me
https://github.com/aspnet/EntityFramework/issues/4781


Updated README

generated table of contents at top
added a concrete example near the end
re-organized headers

@WadeBarnes  just a documentation refinement, with a concrete example as many ppl got confused by the nfs-provisioning and the DB parameters


Cannot put my github repository

Trying to put my Blazor Webassembly prerendered with Authorization code on this repository?
The GitHub link is:-
https://github.com/kalvin1dog/BlazaTech
Cheers

Hello,
What you repository is about?
The source code is not available?


npm start

windows 10

0 info it worked if it ends with ok
1 verbose cli [ 'C:\Program Files\nodejs\node.exe',
1 verbose cli   'C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js',
1 verbose cli   'run',
1 verbose cli   'start' ]
2 info using<EMAIL_ADDRESS>3 info using<EMAIL_ADDRESS>4 verbose run-script [ 'prestart', 'start', 'poststart' ]
5 info prestart<EMAIL_ADDRESS>6 info start<EMAIL_ADDRESS>7 verbose unsafe-perm in lifecycle true
8 info<EMAIL_ADDRESS>Failed to exec start script
9 verbose stack Error<EMAIL_ADDRESS>start: cross-env NODE_ENV=development node server
9 verbose stack Exit status 1
9 verbose stack     at EventEmitter. (C:\Program Files\nodejs\node_modules\npm\lib\utils\lifecycle.js:217:16)
9 verbose stack     at emitTwo (events.js:87:13)
9 verbose stack     at EventEmitter.emit (events.js:172:7)
9 verbose stack     at ChildProcess. (C:\Program Files\nodejs\node_modules\npm\lib\utils\spawn.js:24:14)
9 verbose stack     at emitTwo (events.js:87:13)
9 verbose stack     at ChildProcess.emit (events.js:172:7)
9 verbose stack     at maybeClose (internal/child_process.js:829:16)
9 verbose stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:211:5)
10 verbose pkgid<EMAIL_ADDRESS>11 verbose cwd C:\xampp\htdocs\react-boilerplate
12 error Windows_NT 10.0.14393
13 error argv "C:\Program Files\nodejs\node.exe" "C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js" "run" "start"
14 error node v4.6.0
15 error npm  v2.15.9
16 error code ELIFECYCLE
17 error<EMAIL_ADDRESS>start: cross-env NODE_ENV=development node server
17 error Exit status 1
18 error Failed at the<EMAIL_ADDRESS>start script 'cross-env NODE_ENV=development node server'.
18 error This is most likely a problem with the react-boilerplate package,
18 error not with npm itself.
18 error Tell the author that this fails on your system:
18 error     cross-env NODE_ENV=development node server
18 error You can get information on how to open an issue for this project with:
18 error     npm bugs react-boilerplate
18 error Or if that isn't available, you can get their info via:
18 error
18 error     npm owner ls react-boilerplate
18 error There is likely additional logging output above.
19 verbose exit [ 1, true ]

Can you try doing npm install cross-env and seeing if that fixes it?

I did that and it shows different error:
$ npm start

<EMAIL_ADDRESS>start C:\xampp\htdocs\react-boilerplate
cross-env NODE_ENV=development node server

module.js:327
throw err;
^
Error: Cannot find module 'express'
at Function.Module._resolveFilename (module.js:325:15)
at Function.Module._load (module.js:276:25)
at Module.require (module.js:353:17)
at require (internal/module.js:12:17)
at Object. (C:\xampp\htdocs\react-boilerplate\server\index.js:3:17)
at Module._compile (module.js:409:26)
at Object.Module._extensions..js (module.js:416:10)
at Module.load (module.js:343:32)
at Function.Module._load (module.js:300:12)
at Function.Module.runMain (module.js:441:10)
npm ERR! Windows_NT 10.0.14393
npm ERR! argv "C:\Program Files\nodejs\node.exe" "C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js" "start"
npm ERR! node v4.6.0
npm ERR! npm  v2.15.9
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>start: cross-env NODE_ENV=development node server
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>start script 'cross-env NODE_ENV=development node server'.
npm ERR! This is most likely a problem with the react-boilerplate package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     cross-env NODE_ENV=development node server
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs react-boilerplate
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!
npm ERR!     npm owner ls react-boilerplate
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     C:\xampp\htdocs\react-boilerplate\npm-debug.log

You need to first do npm install.

already did from beginning.

What was the result? Can you run it again? Then show npm ls express?

 What matters is to run npm install properly.

$ npm install

<EMAIL_ADDRESS>preinstall C:\xampp\htdocs\react-boilerplate
npm run npmcheckversion

<EMAIL_ADDRESS>npmcheckversion C:\xampp\htdocs\react-boilerplate
node ./internals/scripts/npmcheckversion.js

C:\xampp\htdocs\react-boilerplate\internals\scripts\npmcheckversion.js:6
throw new Error('[ERROR: React Boilerplate] You need npm version @>=3');
^
Error: [ERROR: React Boilerplate] You need npm version @>=3
at C:\xampp\htdocs\react-boilerplate\internals\scripts\npmcheckversion.js:6:11
at ChildProcess.exithandler (child_process.js:204:7)
at emitTwo (events.js:87:13)
at ChildProcess.emit (events.js:172:7)
at maybeClose (internal/child_process.js:829:16)
at Socket. (internal/child_process.js:319:11)
at emitOne (events.js:77:13)
at Socket.emit (events.js:169:7)
at Pipe._onclose (net.js:486:12)
npm ERR! Windows_NT 10.0.14393
npm ERR! argv "C:\Program Files\nodejs\node.exe" "C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js" "run" "npmcheckversion"
npm ERR! node v4.6.0
npm ERR! npm  v2.15.9
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>npmcheckversion: node ./internals/scripts/npmcheckversion.js
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>npmcheckversion script 'node ./internals/scripts/npmcheckversion.js'.
npm ERR! This is most likely a problem with the react-boilerplate package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     node ./internals/scripts/npmcheckversion.js
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs react-boilerplate
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!
npm ERR!     npm owner ls react-boilerplate
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     C:\xampp\htdocs\react-boilerplate\npm-debug.log
npm ERR! Windows_NT 10.0.14393
npm ERR! argv "C:\Program Files\nodejs\node.exe" "C:\Program Files\nodejs\node_modules\npm\bin\npm-cli.js" "install"
npm ERR! node v4.6.0
npm ERR! npm  v2.15.9
npm ERR! code ELIFECYCLE
npm ERR<EMAIL_ADDRESS>preinstall: npm run npmcheckversion
npm ERR! Exit status 1
npm ERR!
npm ERR! Failed at the<EMAIL_ADDRESS>preinstall script 'npm run npmcheckversion'.
npm ERR! This is most likely a problem with the react-boilerplate package,
npm ERR! not with npm itself.
npm ERR! Tell the author that this fails on your system:
npm ERR!     npm run npmcheckversion
npm ERR! You can get information on how to open an issue for this project with:
npm ERR!     npm bugs react-boilerplate
npm ERR! Or if that isn't available, you can get their info via:
npm ERR!
npm ERR!     npm owner ls react-boilerplate
npm ERR! There is likely additional logging output above.
npm ERR! Please include the following file with any support request:
npm ERR!     C:\xampp\htdocs\react-boilerplate\npm-debug.log

Yes, you need an npm version >=3 😊

lol...just saw that too

awesome. Love it 💃


Meetup GraphQL: Prevent event duplicates and build resiliency to API calls

Cache the JWT access token for use in future event imports. No need to request a new JWT key for every event import.
Add HTTP retries to the GraphQL call. Alleviates issues where we get rate limited for making too many calls in a 60 second period.

I set up the retries to be 3 retries, with a 1 second gap between requests. Could be a little more flexible, but this was just a start.

Check for duplicate events by comparing event title and event date, using an MD5 hash for comparison.

#411

@irby is the issue just that Meetup is returning duplicates due to some bug on their end?
Is it the case that all of the duplicates have alpha-numeric URL slugs and all of the proper URLs have numeric slugs?   If so, would it be easier to just filter out the duplicates based on if the last URL value isn't numeric?

@irby One of the new examples of a duplicate event has two different titles.  Using the title as the duplicate finder may not do the job.
https://www.meetup.com/codewiththecarolinas/events/zwghntygcnbsb
https://www.meetup.com/codewiththecarolinas/events/303630720

I said alpha-numeric, but it seems the duplicates have one event with an alphabetic value at the end of the URL and a numeric version of the same event.
Perhaps it's some sort of previous version they create when the organizers does something to the event?

@irby no great rush, but I did post some questions above about if using the title as a duplicate-finder would work, given the screenshot example posted above.

@allella Can you double check the events table and verify the service = graphql for both of the duplicate events on 10/17/2024 and 10/30/2024? I'm not seeing duplicate event data for these two orgs in the Meetup GraphQL response data.
I wonder if these events were imported while the service was still meetup, and remained when these orgs were transitioned to meetup-graphql?
Code with the Carolinas-Graphql-2024-10-16-2350.json
Greenville South Carolina WordPress Group-Graphql-2024-10-16-2350.json

In Filament, they appear to be importing from GraphQL.
We previously have some duplicates from the transition from REST to GraphQL, but I tried to delete those duplicates and the current issue seems to be related to something on Meetup's side that's creating more than one entry and URL for the same event.  These events do seem to be part of a recurring event, since the Meetup event pages have the series of upcoming recurring events below the graphic on the Meetup event page, like below.

Oct 14
This had two entries and two different URLs when I posted above.  One of those URLs, the alphabetic value at the end, is no longer active on Meetup and the numeric one still works. These also have different titles at the same date/time, which may mean the organizer changed the title.
https://www.meetup.com/codewiththecarolinas/events/zwghntygcnbsb
https://www.meetup.com/codewiththecarolinas/events/303630720
Oct 16
Has two URLs and both are currently active and show the same event
https://www.meetup.com/codewiththecarolinas/events/kwghntygcnbvb
https://www.meetup.com/codewiththecarolinas/events/303664634

@allella I'm unable to reproduce this duplication running locally. I'm only able to get duplicate events when I've run the import with meetup and meetup_graphql as the service type for the organization.

https://www.meetup.com/codewiththecarolinas/events/303941658 (Code with the Carolinas, Civic Tech Volunteer Coffee Break 10/30/24)
https://www.meetup.com/codewiththecarolinas/events/kwghntygcnbnc (Code with the Carolinas, Civic Tech Volunteer Coffee Break 10/30/24)
https://www.meetup.com/codewiththecarolinas/events/304153585 (Code with the Carolinas, Mappy Hour! with Open Sidewalks 11/11/24)
https://www.meetup.com/codewiththecarolinas/events/bnglntygcpbpb (Code with the Carolinas, Mappy Hour! with Open Sidewalks 11/11/24)
I think it might be helpful if I could get some time to pair up with you and review some things on the database side and the server side.

@irby Is the testing on your with a fresh database, or a database that would have existed before the first of the two duplicates was created?
I think one of the conditions is that organizers are making an event and then changing something about it at a later date.
Is it possible to run an import on your local copy every day or so and see if / when a new duplicate situation arises?
And/or I can dump the live database and we could see if that's telling.
We certainly had Meetup imports in there before, but I feel like I deleted those after the GraphQL imports, so I don't think these are part of that transition.

@allella This is testing on a fresh database. I delete the events and venues and run the import only on certain orgs. I can setup my instance to run the import every hour or so. What is the frequency the import is running at?
Can I get a list of organizations that are using service=meetup and service=meetup_graphql?
I don't forsee that looking at the event's service_id and ruling it out based on whether it's strictly numeric or alphanumeric is a good way to filter out. Looks like newly created events use the alphanumeric format.

I've sent a copy of the live DB.
This issue would likely only appear if your local copy were running imports long enough for whatever the triggering event to happen.
This seems to be some combination of being a recurring event that's part of a series, the organizer changing something (the title in the Oct 14th example), Meetup giving the same event two different URLs (numeric vs alphabetical URL suffix value), and one of the duplicate events sometimes being deleted (as with the Oct 14th example).

Just noticing this was closed.  Was the approach of deleting anything that already matched the exact date + time + org + service not going to do the trick?


Invalid NameIdentifier on use GetUserID with Identity Server Bearer Token Authentication

Probably should be some my ignorance.
When configuring with success authentication using the "Thinktecture.IdentityServer3" with "MembershipReboot" and use the extension method of "UseIdentityServerBearerTokenAuthentication" the IPrincipal not has some data when authenticated by "Cookie like SingleTenant" or something has not been mapped in my factory.
So when calling a method of with "Principal.GetUserID ()" get the error "Invalid NameIdentifier".
Something I should check in the examples or any tips?

Check the list of claims you have and the claim types. Something in the token is not lining up with the expectation.

And this would go in "Client" to "IdentityServerServiceFactory"?
Another thing I noticed is that when authenticating so is not called my ClaimsTransformer. More there is nothing there that can cause lack for now.

Well, if the GetUserID() you're using is the one from MR, then it's expecting a claim of type NameIdentifider, but in the WebAPI with the UseIdSvrBearerToken middleware, it's creating a claim of type sub. The claim types are different.

At exactly this, the guid is in "sub", and the code below does not seem to affect anything this.
JwtSecurityTokenHandler.InboundClaimTypeMap = new Dictionary<string, string>
{
    { Thinktecture.IdentityManager.Constants.ClaimTypes.Subject, System.Security.Claims.ClaimTypes.NameIdentifier }
};

Authentication with "UseOpenIdConnectAuthentication" exposes the "Notifications" that could use to transform a claim, however is not the case as the "UseIdentityServerBearerTokenAuthentication" does not.

So then why not just look for the sub claim directly? Do you need to use the GetUserID extension method?

Yes this is a minor problem.
Besides this claim, I use other claims (not mapped in this case) of "Principal" (populated from claims transformer) in some algorithms that can be problematic.
Anyway I am studying the case.
Thank you for your attention.


Labels do not populate on webhooks requests

I created a card and it triggered a webhook into my POST endpoint, but in the webhook data i didn't see any label information, i have a custom label on the card, does it not work with custom label?

Hi Bentley, The reason i closed this ticket is that i realized that the label is not sent out with every post it is only sent when its first created on the card. Once i saw that coming in, i realized i had to change some implementation on my side. Thanks


Add multivariate Vasicek model example

It would be awesome if we can use thermox.log_prob and gradient ascent to fit a multivariate Vasicek model to some real data

At the end of this notebook there is an example for bond pricing with the Vasicek model https://github.com/cantaro86/Financial-Models-Numerical-Methods/blob/afd0e5340502f0056aec00b594c64928b34f4bcb/6.1 Ornstein-Uhlenbeck process and applications.ipynb

This seems to be univariate right? But yeah might be a good resource for inspiration for extending to multivariate case

At the end of this notebook there is an example for bond pricing with the Vasicek model https://github.com/cantaro86/Financial-Models-Numerical-Methods/blob/afd0e5340502f0056aec00b594c64928b34f4bcb/6.1 Ornstein-Uhlenbeck process and applications.ipynb

This seems to be univariate right? But yeah might be a good resource for inspiration for extending to multivariate case

It will be kind of messy if you are trying to obtain some substantial amount of real bond data without access to certain databases (e.g., WRDS (TRACE) database). That said, you can check out the datasets here at Open Source Bond Asset Pricing - https://openbondassetpricing.com/data/ - and I recommend skimming through some Fabozzi to understand what the variables mean in the data files.

At the end of this notebook there is an example for bond pricing with the Vasicek model https://github.com/cantaro86/Financial-Models-Numerical-Methods/blob/afd0e5340502f0056aec00b594c64928b34f4bcb/6.1 Ornstein-Uhlenbeck process and applications.ipynb

This seems to be univariate right? But yeah might be a good resource for inspiration for extending to multivariate case

What exactly do you mean by a multivariate extension? There is only one short rate modelled in a Vasicek model - presumably you might be thinking of modelling interest rates in different economies (e.g., G7), but then these rates may be highly correlated, so it may be preferable to model and simulate in a more suitable basis where the transformed interest rates are not highly correlated and then transform back to the original interest rates in the end.

@zauberresonator thanks for your insight! You clearly are coming from a more financially applied viewpoint than us which is great!

What exactly do you mean by a multivariate extension?

I was thinking that yeah we could have multiple interest rates/economies within the same model and as you say they might be correlated but these correlations would be learnt by having a higher dimensional Vasicek/OU model that includes dense covariances and drift dependencies. I.e. learning numerically how correlated the interest rates are.

Wow, that is cool - I have studied the relevant subjects in the context of physics, statistics, and finance in uni before. I will try this out on my own over the holidays, but you can ping me at<EMAIL_ADDRESS>if I can be of help offline. There are a few more things I will note if you are trying this out:
(i) Covariance matrix: typical (high-dimensional) covariance matrix estimation often assumes some form of low-rank structure (revealed through various rank-revealing matrix factorisations) and/or applies some form of regularisation/shrinkage to only use the "important" components; this can be visualised by plotting the eigenvalues (from largest to smallest) for naive and shrunk sample covariance matrices
(ii) Precision matrix: assuming multivariate Gaussian distribution, entry (i,j) of the precision matrix is related to the partial correlation of $x_i$ and $x_j$ conditioning on the other $x_k$ variables and is precisely zero when $x_i$ and $x_j$ are conditionally independent (given the other variables); similar high-dimensional concerns apply to the sample estimate precision matrix
(iii) RMT: naturally, there is all the beautiful results from random matrix theory going back to Wigner, Dyson, and Mehta, but I will be careful before applying those as sanity checks because the relevant limit in this context is $T \rightarrow \infty$, $N \rightarrow \infty$, and $q=\frac{N}{T}=O(1)$


Configuring a direct source with delete behaviour causes a "hi" to be printed to the console

I know this sounds strange, but doing src.config_delete_behavior(&del_cfg).unwrap(); causes a "hi" to be printed to the console.
I'm using the code verbatim in https://github.com/synthizer/synthizer-rs/blob/master/synthizer/examples/linger.rs to play a sound with linger (something like a footstep) and noticed this. Below is the code that I'm using.
pub fn play_with_linger(&self, buffer: &syz::Buffer) {
        let del_cfg = syz::DeleteBehaviorConfigBuilder::new()
            .linger(true)
            .linger_timeout(10.0)
            .build();
        let src = syz::DirectSource::new(&self.context).unwrap();
        let generator = syz::BufferGenerator::new(&self.context).unwrap();
        generator.set_buffer(buffer).unwrap();
        src.add_generator(&generator).unwrap();
        src.config_delete_behavior(&del_cfg).unwrap(); // this line
        generator.config_delete_behavior(&del_cfg).unwrap();
        src.play().unwrap();
    }

Forgot to mention, I'm on version 0.3.3 of the Synthizer crate.

Bleh ok.  There was a debug print that landed in mainline Synthizer.  I didn't realize that hit actual releases.
I'll fix that this morning and roll releases across the board.

Thanks!
While we're on the subject of linger, I really like this convenience feature because its the one thing that exists outside the model of have the soundsystem observe the world and it updates itself based on the world state similar to React's reconciliation.
There were instances where I just needed a sound to be played and didn't want to have to manage the lifetime of its objects.

Ok, this is fixed.  I've been awake for all of 20 minutes so if it's still there we'll do this again when I'm actually alert.
I like lingering from the external user perspective--even with what little we have now it goes beyond everything I know of.  That said it may be slightly buggy still, so if you find issues do open something against the main synthizer repo.  I hate how I can either write the library or use the library due to lack of time to do both but that's life I suppose.