Fix ConvexHull constructor, add tests

It seems that recent changes must have added a field to ConvexHull, but the new
statement was not correspondingly updated. This adds tests for construction and
whether the expected vertices are returned for a simple problem.

I recommend reviewing with Files changed -> gears icon -> Hide whitespace. I have my vscode settings to automatically fix things like trailing whitespace.

I wonder how I have managed to not notice the missing parameter.
Thanks for the test case too.
I will tag this as v0.2.1

BTW, in case you're unaware, PkgTemplates is very nice when creating a new package. I usually use
tpl = Template(; plugins=[GitHubActions(), Codecov(), Documenter{GitHubActions}()])
tpl("MyNewPackage")

but there are many other tweaks you can make.

I think I have seen references PkgTemplates, but I haven't used it.
Admittedly I am undisciplined on polishing my packages.


Use the latest ProtoData

Previously, ProtoData plugin was experiencing some issues related to the inability to parse some of Proto definitions. There were some changesets which addressed them:

ProtoData#69: addressing the issues in the ProtoData plugin, but temporarily strip the Protobuf API to make the compilation pass.
mc-java#38: migration of modelCompiler to the fixed, but "stripped down" version of ProtoData plugin.
ProtoData#70: using the "fixed"/"stripped down" version of ProtoData to bring back the previously removed Proto API pieces and produce a "normal" ProtoData plugin.

Within this changeset, we complete the journey by migrating modelCompiler to the "normal" ProtoData plugin published on the previous step.

@alexander-yevsyukov @dmdashenkov PTAL.


Initializer fails with ArgumentError: Missing secret_key_base for 'test_data' environment, set this string with bin/rails credentials:edit

It seems that the test_data:install task wants to initialize the new test_data environment. If you are in a repo that has a config/credentials.yml.enc but you are unable to edit that with rails credentials:edit (i.e. because you don't have a config/master.key or haven't set RAILS_MASTER_KEY, the environment creation throws an exception.

Thanks for the report @mdoel -- sorry for taking my time in looking into this. Looks like it's still an issue as of 49768a2.
To reproduce:
$ bin/rails credentials:edit
# save the file
$ mv config/master.key someplace/else
$ bin/rake test_data:install
$ RAILS_ENV=test_data bin/rails server

Will yield this error on each request:
2021-07-06 09:03:45 -0400 Rack app ("GET /" - (<IP_ADDRESS>)): #<ArgumentError: Missing `secret_key_base` for 'test_data' environment, set this string with `bin/rails credentials:edit`>

This doesn't happen to development, indicating that it's treated differently for some reason.

Yeah, sure enough:
    def secret_key_base
      if Rails.env.development? || Rails.env.test?
        secrets.secret_key_base ||= generate_development_secret
      else
        validate_secret_key_base(
          ENV["SECRET_KEY_BASE"] || credentials.secret_key_base || secrets.secret_key_base
        )
      end
    end

If we were to slam this lovely private-method call into config/environments/test_data.rb, it would work:
Rails.application.secrets.secret_key_base ||= Rails.application.send(:generate_development_secret)

The number of places in which Rails hardcodes Rails.env.development? || Rails.env.test? or similar is frustrating, given its support for arbitrarily-many environments (the undocumented working assumption appears to be that all non-development/test environments are production-like)


[Feature Request]: Everygreen-ADMX to get your ADMX included

The request
Support Downloads of Winget Autoupdate-Intune ADMX via EvergreenADMX.
There is this great project to keep ADMX updated.  Wanna hook up so it is supported by this solution?
Is your feature request related to a problem?
No response
Additional information
No response

Evergreen ADMX is meant to keep ADMX files in your on-premises Active Directory up-to-date. How would this benefit this project?

@msfreaks I understand you concern it is aimed at ADMX files for on-premises AD DS, but also EvergreenADMX already spanning over a variety of ADMX templates not limited to Windows OS. Including these admx templates could be of use to manage GPO for this tool.
I understand most might use the ADMX files to be imported in Intune, yet there are a hybrid join scenarios where the ADMX can be used for GPOs.

as I understand the is no intention from this side or evergreen admx maintainer, PR closed. Thanks for your consideration.


pytestifying demo

WIP example using pytest for our entire test suite. The example is located in test/functional. This is meant to demonstrate converting an existing integration test using a class based approach to using pytest and pytest fixtures. Feel free to ask questions in a PR review!

closing this PR! this served as an example for https://github.com/dbt-labs/dbt-core/issues/4690


Enhancements

If property doesn't exist config will also try to pull the missing value from system env
now logs all the configuration sources that ran
adds putall function to easily add a maps values to a config

Feel free to rename the functions.
We seem to be using IllegalStateException a lot, do you think there should be a custom exception just for config?

I think the getAs should have been a separate PR (as I don't think that works so can't be merged)

I have seperated getAs into #69


Odd calculation in bandwidth table?

My understanding is that for t3.micro for example, 0.064 Gbps translates to 64 Mbps, not 6.4Mbps ?
While not amazing, it's ten times more bearable.
https://github.com/AndrewGuenther/fck-nat/blob/5628ea57d04a8dcaff09491b8269f440119d780a/docs/choosing_an_instance_size.md?plain=1#L18-L26

https://docs.aws.amazon.com/ec2/latest/instancetypes/gp.html#gp_network

Looks like you're right and there was a bug in my script that pulled this info from the API. I'll need to take a closer look at the rest of that page because we reference some of these instance types (t4g.nano in particular) quite a bit from an efficiency standpoint.


use finnhub rest api endpoint for stock prices instead of scraping yahoo finance

Requires an API key, but is apparently free for life.
https://www.alphavantage.co/support/#api-key

Ah nevermind, just read that it limits you to 5 API requests per minute. Will look into alternatives...

Found a different one that limits to 60 API calls per minute, which should be more than enough for us.
https://finnhub.io/pricing


select * from aws_wellarchitected_workload fails

Describe the bug
A clear and concise description of what the bug is.
aws_wellarchitected_workload does stops in ⠼ Loading results...
Steampipe version (steampipe -v)
Example: v0.11.2
Plugin version (steampipe plugin list)
Example: v0.44.0
To reproduce
Steps to reproduce the behavior (please include relevant code and/or commands).
Execute select * from aws_wellarchitected_workload
Expected behavior
A clear and concise description of what you expected to happen.
Additional context
Add any other context about the problem here.

@defec8edc0de Thanks for raising this part of your testing. Adding this track separately.  Reference

As of now, AWS endpoints package does not provide support for well-architected service. AWS GO SDK issue reference.


Repo for the website?

Hi Craig! @craigraw
I was on https://sparrowwallet.com and I notice that images could be optimized to make the site snappier.
I'm thinking, "I can fix that, then I'll send Craig a pull request"
So I come to GitHub to find the website's repository and it's not here. Maybe it's private, if it's here at all?
If the website is on GitHub, make me a collaborator?  I'll send you a PR with assets optimized.

Thanks - any images in particular? The logo is pretty large I know, but since it's often scraped for various things I keep it high resolution.

Craig @craigraw this page in particular, we can watch the images load incrementally, over several seconds. It's painful 😄
Setup a Coldcard wallet

Here's an audit report on that page:
https://pagespeed.web.dev/analysis/https-sparrowwallet-com-docs-coldcard-wallet-html/egwz9rehch?form_factor=desktop
In particular, scroll to Serve images in next-gen formats and Properly size images
Properly sizing images is clutch. This is from a desktop browser.

Thanks - it's looking better now. Not perfect perhaps, but ok think:
https://pagespeed.web.dev/analysis/https-sparrowwallet-com-docs-coldcard-wallet-html/19etj6aeor?form_factor=desktop

That's a bit better Craig @craigraw.
Still opportunity for optimizing image loading for this page (and presumably others) on the order of 80%, shaving several seconds off page load time (according to the latest report at that URL ⬆)
But you get the idea; this is something to keep in-mind as you maintain and incrementally improve the site over time. If the site had a public repository, I'd PR that for 'ya.
Closing this issue now.


Support metadata in Import API

To make it easier to add metadata to a run created via the Import API, add a metadata field which can be applied to the run and the results.

[ ] Create metadata field in Import API spec
[ ] Add support for metadata field in Import controller
[ ] Apply metadata to run
[ ] Apply metadata to results

Going to take a look at this

This should do it: https://github.com/ibutsu/ibutsu-server/pull/194

Closing as #194 has been merged, thanks @jjaquish! Next step will be to add support to the UI.


⚠ pishem-otzivi has degraded performance

In 111d2d2, pishem-otzivi (https://пишем-отзывы.рф/) experienced degraded performance:

HTTP code: 200
Response time: 11080 ms

Resolved: pishem-otzivi performance has improved in 3b07343.


Does it make sense to put Date in transaction base class?

Hey, guys,
I am working on a rippled library implemented in go.
In this library, we defined a TxBase struct which is supposed to contain fields common to all types of transactions.
We are having a debate whether we should put Date in TxBase here https://github.com/rubblelabs/ripple/issues/36
Can someone chime in? Thank you!

@nbougalis

Just realized Date probably shouldn't belong to TxBase since it's a property of ledger, not transaction. I will close this one.

Thanks for the post. As you said, this is a property of the ledger, not of the individual transactions within it.


Datalog Souffle compilation at image build time

Builds Soufflé executables at build time of the docker image. Fixes #46

There seems to be a lot of boilerplate code that can be removed, such as the instruction count computation, the logging of the thresholds, etc. Should I take care of this?

There seems to be a lot of boilerplate code that can be removed, such as the instruction count computation, the logging of the thresholds, the Soufflé installation check (souffle is not actually required at runtime anymore), etc. Should I take care of this?

In a separate PR if you want, sure!

@jakobbeckmann can you look at the last commit, and see whether that's good enough for you? I quickly tested, it seems to work.
The main drawback is that now, running java -jar build/libs/securify.jar won't work without build/mayImplicit etc.

Well technically you will build build/mayImplicit etc. in order to get the .jar file. So as soon as you can launch the .jar file, the Datalog binaries should exist, unless you actually copy paste the .jar file somewhere or manually compile the Java code. Is that really a problem/do you expect people to do this in real life?
Other than that, everything seems fine and works.

@hiqua Well technically you will build build/mayImplicit etc. in order to get the .jar file. So as soon as you can launch the .jar file, the Datalog binaries should exist, unless you actually copy paste the .jar file somewhere or manually compile the Java code. Is that really a problem/do you expect people to do this in real life?

Yes this is what I meant, being able to copy-paste the .jar around is nice, and we actually do that on the webserver, although we can obviously adapt and also copy the compilation output / build and use the docker image instead.


Extremely inefficient in generating bitstream in Memory Bank Protocol

Describe the bug
A clear and concise description of what the bug is.

To Reproduce
Steps to reproduce the behavior:

Use any moderate size FPGA (in my case a 104x68 layout (I believe is 100K LE)
Try generate bitstream, XML as well as TestBench verilog
Should notice extremely high memory usage and long bitstream generation time

Here is the detail analysis:
(P/S: all the timing benchmark is done using Raptor 1GE100-ES1 device, which has 104x68 layout)

Device info/PC System

There is total of 5273 BL bits (Valid value range from 0 - 5272)
There is total of 3407 WL bits (Valid value range from 0 - 3406)
There is total of 10130859 configuration bits
PC with 32G Bytes RAM (8 Cores/16 Threads)

Fabric bitstream generation

Each configuration bit has a unique combination of BL value and WL value
Instead of storing configuration bit BL/WL info in two uint32_t (one for BL and one for WL), the FabricBitstream class store the information in a one hot of maximum bits (in vector of uint64_t)
For example: if BL value is 2, the code will store the data in b'00100000000000000…..000000 (total of 5273 bits) which require 660 Bytes [in vector of uint64_t]
For WL, if WL value is 3, the code will store the data in b'000100000000000……000000 (total of 3407 bits) which require 432 Bytes [in vector of uint64_t]
Each configuration bit store the data value and mask value (another redundant), hence for total of 10130859 configuration bits, the class used
= 10130859  * (660 + 432) Bytes * 2 (data and mask)
= More than 20 G Bytes
Device as big as Altera 14nm and 10nm series, only needs runtime > 4G Bytes RAM and < 8G Bytes RAM for entire bitstream processing (read the SOF file, encryption, signing, and generate final bitstream that can be loaded into device)
Planned fix: Two database being stored

First is used by XML generation: each configuration bit only store the value of Region, BL, WL (in uint32_t) and din (in bool/uint8_t)
= 10130859   * ((4 Byte) * 3 (BL, WL, Region) + 1 (din))
= 125 M Bytes
Second is used by bitstream generation

BL bits are represented in Byte vector. Each Byte store 8 bits. Hence to store BL with 5273 bits, it require 660 Bytes
WL remains as number
Since we have total 3407 WL, altogether it only use
= 3407 * 660 Bytes * 2 (data and mask)
= 4 M Bytes

A lot of unnecessary conversion happening in original code

When we build bitstream, from BL/WL size_t value --> long vector of char of '1', '0' and 'x' (5273 characters or 3407 characters ) -> a vector of uint64_t
When we want to use it (for example for writing), we do backward conversion. From a vector of uint64_t --> long vector of char of "1", "0", "x" --> to std::string
This is time wasting

Fabric bitstream text writing

Every configuration bits BL and WL which stored in vectors of unit64_t will be converted into string. Each character in the string represent a BL bit or WL bit.

Where WL string (in this case 3407 char) is used as std::map key to store BL string
This is because we want to arrange the data by WL

Since the both BL and WL are in string format:

For BL, instead of bit manipulation, it does a lot of string manipulation
For WL, to use the long string as map key introducing complexity in string comparison, and it also cause additional memory allocation each time an item is added to the container
Processing data is extremely inefficient in this way
You can search online how inefficient to use very long string as map key

TestBench Verilog generation

We used a lot of resource (memory and time) to build the bitstream, and eventually we only want to find the final WL addr count that we need to program
See https://github.com/lnis-uofu/OpenFPGA/blob/master/openfpga/src/fpga_verilog/verilog_top_testbench.cpp#L1066-L1068
We build_memory_bank_flatten_fabric_bitstream() and just to get the size()
Same for

https://github.com/lnis-uofu/OpenFPGA/blob/master/openfpga/src/fpga_verilog/verilog_top_testbench_memory_bank.cpp#L568-L570 and
https://github.com/lnis-uofu/OpenFPGA/blob/master/openfpga/src/fpga_verilog/verilog_top_testbench_memory_bank.cpp#L606-L607

There is more efficient way to do so

See the benchmark

Table below compare my local fix timing and original OpenFPGA timing when generating bitstream for same design using same device
The improvement in the time is significant yet it only use small footprint. Yet it generates identical Text, XML, TestBench Verilog
Currently I only enable this new technique for QL Memory Bank with Flatten BL/WL

@tangxifan

@chungshien, please submit your PR to address this issue.

Fixed via
https://github.com/lnis-uofu/OpenFPGA/pull/1259
https://github.com/lnis-uofu/OpenFPGA/pull/1287
Close issue


v1.0.3 is missing in Github releases

Version 1.0.3 is not available for downloads under releases on github. Could you fix it? It seems that it's enough to create tag.

This should be fixed now. Thanks for noticing!


[EventRequest] Codeunit 31020 "Purchase-Post Advances".PostVATCorrectionToGL

Please add new parameter to event
[IntegrationEvent(false, false)]
//----------------------------------------OnBeforePostVATCorrectionToGL:BEGIN
//local procedure OnBeforePostVATCorrectionToGL(var GenJournalLine: Record "Gen. Journal Line"; PurchAdvanceLetterLine: Record "Purch. Advance Letter Line")
local procedure OnBeforePostVATCorrectionToGL(var GenJournalLine: Record "Gen. Journal Line"; PurchAdvanceLetterLine: Record "Purch. Advance Letter Line"; VATAmtToDeduct: Decimal; BaseToDeduct: Decimal)
begin
end;
//----------------------------------------OnBeforePostVATCorrectionToGL:END

local procedure PostVATCorrectionToGL(PurchAdvanceLetterLine: Record "Purch. Advance Letter Line"; PurchInvHeader: Record "Purch. Inv. Header"; DocumentNo: Code[20]; LinkedEntryNo: Integer; BaseToDeductLCY: Decimal; VATAmountLCYDif: Decimal; BaseToDeductLCYDif: Decimal; VATAmountLCY: Decimal; VATAmtToDeduct: Decimal; BaseToDeduct: Decimal)
    var
        GenJournalLine: Record "Gen. Journal Line";
        SourceCodeSetup: Record "Source Code Setup";
    begin
        TempPurchAdvanceLetterEntry."VAT Identifier" := PurchAdvanceLetterLine."VAT Identifier";
        TempPurchAdvanceLetterEntry."Vendor Entry No." := LinkedEntryNo;
        TempPurchAdvanceLetterEntry."Letter No." := PurchAdvanceLetterLine."Letter No.";
        TempPurchAdvanceLetterEntry."Letter Line No." := PurchAdvanceLetterLine."Line No.";

        // Post VAT Correction
        PrepareInvJnlLine(GenJournalLine, PurchAdvanceLetterLine, PurchInvHeader);
        SourceCodeSetup.Get();
        GenJournalLine."Source Code" := SourceCodeSetup."Purchase Entry Application";
        GenJournalLine."Document No." := DocumentNo;
        SetPostingGroups(GenJournalLine, PurchAdvanceLetterLine, false);
        GenJournalLine."Account No." := PurchAdvanceLetterLine."No.";
        GenJournalLine."Advance VAT Base Amount" := BaseToDeductLCY;
        GenJournalLine."Advance Exch. Rate Difference" := VATAmountLCYDif;
        GenJournalLine.Validate(Amount, VATAmountLCY);
        GenJournalLine.Validate("Source Currency Amount", CalcAmtLCYToACY(GenJournalLine."Posting Date", GenJournalLine.Amount));
        GenJournalLine."Shortcut Dimension 1 Code" := PurchInvHeader."Shortcut Dimension 1 Code";
        GenJournalLine."Shortcut Dimension 2 Code" := PurchInvHeader."Shortcut Dimension 2 Code";
        GenJournalLine."Dimension Set ID" := PurchInvHeader."Dimension Set ID";

	//----------------------------------------OnBeforePostVATCorrectionToGL:BEGIN
        //OnBeforePostVATCorrectionToGL(GenJournalLine, PurchAdvanceLetterLine);
        OnBeforePostVATCorrectionToGL(GenJournalLine, PurchAdvanceLetterLine, VATAmtToDeduct, BaseToDeduct);
	//----------------------------------------OnBeforePostVATCorrectionToGL:END
        if BaseToDeductLCY <> 0 then
            GenJnlPostLine.RunWithCheck(GenJournalLine);

        if BaseToDeductLCY <> 0 then begin
            PurchAdvanceLetterEntryNo += 1;
            TempPurchAdvanceLetterEntry."Entry No." := PurchAdvanceLetterEntryNo;
            TempPurchAdvanceLetterEntry."Entry Type" := TempPurchAdvanceLetterEntry."Entry Type"::"VAT Deduction";
            TempPurchAdvanceLetterEntry.Amount := 0;
            TempPurchAdvanceLetterEntry.Insert();
            FillVATFieldsOfDeductionEntry(PurchAdvanceLetterLine."VAT %");
            TempPurchAdvanceLetterEntry."VAT Identifier" := PurchAdvanceLetterLine."VAT Identifier";
            TempPurchAdvanceLetterEntry."VAT Base Amount" := BaseToDeduct;
            TempPurchAdvanceLetterEntry."VAT Amount" := VATAmtToDeduct;
            OnPostVATCorrectionToGLOnBeforeModifyTempPurchAdvanceLetterEntry(PurchAdvanceLetterLine, BaseToDeductLCY, TempPurchAdvanceLetterEntry);
            TempPurchAdvanceLetterEntry.Modify();
        end;

        // VAT Offset Account
        if PurchAdvanceLetterLine."VAT Calculation Type" <>
           PurchAdvanceLetterLine."VAT Calculation Type"::"Reverse Charge VAT"
        then begin
            GenJournalLine."Account No." := GetPurchAdvanceOffsetVATAccount(PurchAdvanceLetterLine."VAT Bus. Posting Group", PurchAdvanceLetterLine."VAT Prod. Posting Group");
            GenJournalLine."Advance VAT Base Amount" := 0;
            SetPostingGroups(GenJournalLine, PurchAdvanceLetterLine, true);
            GenJournalLine.Validate(Amount, -VATAmountLCY);
            GenJournalLine.Validate("Source Currency Amount", CalcAmtLCYToACY(GenJournalLine."Posting Date", GenJournalLine.Amount));
            GenJournalLine."Shortcut Dimension 1 Code" := PurchInvHeader."Shortcut Dimension 1 Code";
            GenJournalLine."Shortcut Dimension 2 Code" := PurchInvHeader."Shortcut Dimension 2 Code";
            GenJournalLine."Dimension Set ID" := PurchInvHeader."Dimension Set ID";
            if BaseToDeductLCY <> 0 then
                GenJnlPostLine.RunWithCheck(GenJournalLine);
        end;

        // Gain/Loss
        if GenJournalLine."Advance Exch. Rate Difference" <> 0 then begin
            if PurchAdvanceLetterLine."VAT Calculation Type" <>
               PurchAdvanceLetterLine."VAT Calculation Type"::"Reverse Charge VAT"
            then begin
                if GenJournalLine."Advance Exch. Rate Difference" > 0 then begin
                    Currency.TestField("Realized Losses Acc.");
                    GenJournalLine."Account No." := Currency."Realized Losses Acc."
                end else begin
                    Currency.TestField("Realized Gains Acc.");
                    GenJournalLine."Account No." := Currency."Realized Gains Acc.";
                end;
                GenJournalLine.Validate(Amount, GenJournalLine."Advance Exch. Rate Difference");
                GenJournalLine."Shortcut Dimension 1 Code" := PurchInvHeader."Shortcut Dimension 1 Code";
                GenJournalLine."Shortcut Dimension 2 Code" := PurchInvHeader."Shortcut Dimension 2 Code";
                GenJournalLine."Dimension Set ID" := PurchInvHeader."Dimension Set ID";
                GenJnlPostLine.RunWithCheck(GenJournalLine);

                GenJournalLine."Account No." := GetPurchAdvanceOffsetVATAccount(PurchAdvanceLetterLine."VAT Bus. Posting Group", PurchAdvanceLetterLine."VAT Prod. Posting Group");
                GenJournalLine.Validate(Amount, -GenJournalLine."Advance Exch. Rate Difference");
                GenJournalLine."Shortcut Dimension 1 Code" := PurchInvHeader."Shortcut Dimension 1 Code";
                GenJournalLine."Shortcut Dimension 2 Code" := PurchInvHeader."Shortcut Dimension 2 Code";
                GenJournalLine."Dimension Set ID" := PurchInvHeader."Dimension Set ID";
                GenJnlPostLine.RunWithCheck(GenJournalLine);
            end;

            PurchAdvanceLetterEntryNo += 1;
            TempPurchAdvanceLetterEntry."Entry No." := PurchAdvanceLetterEntryNo;
            TempPurchAdvanceLetterEntry."Entry Type" := TempPurchAdvanceLetterEntry."Entry Type"::"VAT Rate";
            TempPurchAdvanceLetterEntry.Amount := 0;
            TempPurchAdvanceLetterEntry."VAT Base Amount" := 0;
            TempPurchAdvanceLetterEntry."VAT Amount" := 0;
            TempPurchAdvanceLetterEntry."VAT Base Amount (LCY)" := BaseToDeductLCYDif;
            TempPurchAdvanceLetterEntry."VAT Amount (LCY)" := VATAmountLCYDif;
            TempPurchAdvanceLetterEntry.Insert();
        end;
        if (PurchAdvanceLetterLine."VAT Calculation Type" =
            PurchAdvanceLetterLine."VAT Calculation Type"::"Reverse Charge VAT") and
           (BaseToDeductLCYDif <> 0) and (GenJournalLine."Advance Exch. Rate Difference" = 0)
        then begin
            PurchAdvanceLetterEntryNo += 1;
            TempPurchAdvanceLetterEntry."Entry No." := PurchAdvanceLetterEntryNo;
            TempPurchAdvanceLetterEntry."Entry Type" := TempPurchAdvanceLetterEntry."Entry Type"::"VAT Rate";
            TempPurchAdvanceLetterEntry.Amount := 0;
            TempPurchAdvanceLetterEntry."VAT Base Amount" := 0;
            TempPurchAdvanceLetterEntry."VAT Amount" := 0;
            TempPurchAdvanceLetterEntry."VAT Base Amount (LCY)" := BaseToDeductLCYDif;
            TempPurchAdvanceLetterEntry."VAT Amount (LCY)" := 0;
            TempPurchAdvanceLetterEntry.Insert();
        end;
    end;

@AlexanderYakunin - we need any reaction.
It is blocking our business and we need to resolve it as soon as possible.
Thanks
Jiří Bureš
CEO

@Jiribu73 - you don't need to copy/paste such kind of messages, as all events processed same way. Currently we are on release stage for next major and come branches are on code freeze, so we need to wait until we can submit required changes.
Please provide more information about your extension work and why it affects your business? Which version do you use? Do you have cloud or onprem customers in CZ? Are aware about rework on CZ localization to extensions?

We implementing new customers into the on-prem version and upgrading our current customers. We have a lot of modifications in the CZ localizations, especially in the Advances. We cannot go-live without them, therefore we need all events as soon as possible.
The specific situation is for the Advances, because we are waiting for the events for current version and in the new version (190) are Advances totally redesigned to the extensions - but with no documentation and with a lot of bugs - so we could not extend the new version (because we do not know its logic) of the Advances and have to redesign the old one.
I understand that you are on release stage, but if it means that all our request will be availaible in version 200, it will definetelly affect our business.
My questions are simple - we need to know if the events will be available and when - no reaction is not communications therefore I am escalating it.


Rebrand from CII to OpenSSF

The Core Infrastructure Initiative (CII) has been merged into the Open Source Security Foundation (OpenSSF), and the badging project is part of the OpenSSF Best Practices WG. It would be sensible to rebrand the CII Best Practices Badge to match.
HOWEVER! Rebranding takes a lot of time and effort, and it will have nontrivial costs. So it's important that this rebranding happen exactly once if it happens at all.
So the OpenSSF must FIRST agree on the rebranding, including the new name & proposed new URLs for the GitHub site and public URLs. I would like the OpenSSF Best Practices WG, Technical Advisory Council (TAC), and Governing Board (GB) to all agree to the specific changes, since this impacts the working group, technology, marketing, and so on.
Proposed changes:

Name: "CII Best Practices Badge" → "OpenSSF Best Practices Badge"
Repo (GitHub) site: https://github.com/coreinfrastructure/best-practices-badge → https://github.com/openssf/best-practices-badge/
Website: https://bestpractices.coreinfrastructure.org/ → https://bestpractices.dev/ (the goal is to have a much shorter URL; the long domain name has been a complaint in the past).
Badge display (small image): "cii best practices" → "openssf best practices"

It will be very important to automatically redirect users of the current repo site and website to the new site location. For the website this will probably need to happen for quite some time, probably 3+ years.
The current badge image says "cii best practices". I propose changing that to "openssf best practices", as that is clear even though that is extremely long. Shorter versions have their own problems:

"ossf best practices" is shorter, but that invites confusion if the name is really the "OpenSSF Best Practices Badge".
"openssf" in many ways is best, as that is similar to the length of most other badge names. However, that doesn't hint at its purpose (best practices) & could be a problem later if the OpenSSF creates another badge.

There are a lot of things that will need to change if this occurs. The logo will have to be redone, which is costly. We'll also have to modify code & configurations in a number of places to deal with this change. I'll have to coordinate with LF IT to make the transition quick & transparent. We'll probably do name changes, then URL changes, so that people will get hints that the URL changes are coming.
Comments welcome!

Thanks David! I agree there's no rush here. As an engineer that's been asked to rename things frequently, I would much rather we take our time and get this right the first time!

I like the new website url bestpractices.dev
I don't care about renaming from CII to OpenSSF, which makes the name even longer. How about removing CII and calling it the "Best Practices Badge" only?

@GeorgLink - "Best Practices Badge" would be simpler. My concern is that I expect that there are (and will be) many organizations that "badge" best practices. But I'm open to making it shorter if people agree to it.
BTW, I know we at least used to have bestpractices.dev, but I need to make sure that we still own the domain. Hopefully we do, but I'm not going to switch until we are certain that we still own it :-).

Counter arguments to the above:

CII has always been "Core Infrastructure Initiative", whereas "OpenSSF" is "Open Source Security Foundation". Since CII covers a variety of areas BEYOND just security, "OpenSSF BP Badge" seems to be more limiting in scope.

There are many things that you can have best practices for, and OpenSSF might even in the future want to have other best practice badges for things orthogonal to "core infrastructure".

I think "Open Source Best Practices" or similar would be even better. The CII there always looked weird as people simply don't know what CII is (and the practices are for open source in general, not for CII). I don't think "OpenSSF" makes it any better than CII in that regard, as it is a rather new organization that to most people hasn't had any impact or importance and remains just-another-org with a name starting with "Open".

I think "Open Source Best Practices" or similar would be even better.

It'd be easy for people to understand, agreed. But I'm sure there are many lists of Open Source Best Practices, and I'm concerned that they would be too-easily confused. There'd be no practical way to quickly distinguish between them.

Right, that's certainly true...

Just to throw this out there: When I google "open source best practices", we are not on the first page. When I google "best practices badge" the first page is exclusively about us. At least for now, we "own" that name, with or without CII or OpenSFF.

@GeorgLink - that search shows that people can easily find the name only if they include the word "badge". Other people can create badges about open source software in the future, we can't stop them - nor would we want to. I'd like to have a more distinctive "official" name so that even if another badge is created later there's little risk of confusion.
But your search does suggest that we'd better include the word "badge" in the official name. I think we should anyway, but I think your search confirms it.

I feel there is value in the rename for clarity and agree with the proposed changes:

Name: "OpenSSF Best Practices Badge"
Repo: https://github.com/openssf/best-practices-badge/
URL: https://bestpractices.dev/
Badge display w/"openssf best practices"

I feel there is value in the rename for clarity and agree with the proposed changes:

Name: "OpenSSF Best Practices Badge"
Repo: https://github.com/openssf/best-practices-badge/
URL: https://bestpractices.dev/
Badge display w/"openssf best practices"

From a marketing/branding perspective, I think I would prefer the following URL:
https://openssf.org/best-practices-badge
Two reasons:

This keeps the website organizational structure in line with the github structure, making it easier for anyone who is familiar with one to find the other.

I suspect we will want to follow a consistent pattern with other OpenSSF projects. For example, we have been discussing exposing the security metrics dashboard at the following URL:

https://openssf.org/metrics
This will be a good question to discuss with our marketing committee (once we have this established. :-))

From a marketing/branding perspective, I think I would prefer the following URL:
https://openssf.org/best-practices-badge
Two reasons:

This keeps the website organizational structure in line with the github structure, making it easier for anyone who is familiar with one to find the other.

I suspect we will want to follow a consistent pattern with other OpenSSF projects. For example, we have been discussing exposing the security metrics dashboard at the following URL:

https://openssf.org/metrics
This will be a good question to discuss with our marketing committee (once we have this established. :-))

https://openssf.org/best-practices-badge

That won't work; it needs its own domain. The best practices badge runs on a different computer system, uses a different programming language, has its own database, etc. We could try to hide that, but that would create a lot of inefficiencies & effort for no obvious gain. It'd be a leaky abstraction anyway, so we're just creating problems.
Since it must have its own domain, there are several options:

Do nothing (always an option).
Something short like "bestpractices.dev".
Something under openssf.org, e.g,. "bestpractices.openssf.org". The problem with this is that the URL is very long. A big complain about the current system is that its URLs are too long.

https://openssf.org/best-practices-badge

That won't work; it needs its own domain. The best practices badge runs on a different computer system, uses a different programming language, has its own database, etc. We could try to hide that, but that would create a lot of inefficiencies & effort for no obvious gain. It'd be a leaky abstraction anyway, so we're just creating problems.
Since it must have its own domain, there are several options:

Do nothing (always an option).
Something short like "bestpractices.dev".
Something under openssf.org, e.g,. "bestpractices.openssf.org". The problem with this is that the URL is very long. A big complain about the current system is that its URLs are too long.

Perhaps 'badge.openssf.org' (and also 'badge' as github repo name)?  We can describe as 'best practices badge' in the text? A question might be, what if we want to introduce another sort of badge later?  We can deal with that at the time, but in general, for simplicity, focus and impact, I think we might want only one badge sponsored by the OpenSSF.  Just thoughts for consideration.
From: David A. Wheeler<EMAIL_ADDRESS>Sent: Thursday, January 7, 2021 8:04 AM
To: coreinfrastructure/best-practices-badge<EMAIL_ADDRESS>Cc: Kay Williams<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [coreinfrastructure/best-practices-badge] Rebrand from CII to OpenSSF (#1515)
https://openssf.org/best-practices-badgehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenssf.org%2Fbest-practices-badge&data=04|01|kayw%40microsoft.com|56a36c0b05f84037bd3a08d8b325e1f7|72f988bf86f141af91ab2d7cd011db47|1|0|637456322574037302|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=W57pK3bj%2B%2BbmS9OPrAyzKvoXLZOhZksIoR77fwewKwI%3D&reserved=0
That won't work; it needs its own domain. The best practices badge runs on a different computer system, uses a different programming language, has its own database, etc. We could try to hide that, but that would create a lot of inefficiencies & effort for no obvious gain. It'd be a leaky abstraction anyway, so we're just creating problems.
Since it must have its own domain, there are several options:

Do nothing (always an option).
Something short like "bestpractices.dev".
Something under openssf.org, e.g,. "bestpractices.openssf.org". The problem with this is that the URL is very long. A big complain about the current system is that its URLs are too long.

You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcoreinfrastructure%2Fbest-practices-badge%2Fissues%2F1515%23issuecomment-756208831&data=04|01|kayw%40microsoft.com|56a36c0b05f84037bd3a08d8b325e1f7|72f988bf86f141af91ab2d7cd011db47|1|0|637456322574037302|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=MrlaczIxLYpYw0hc%2B8ax3RfvLjfzfZp8kezLi3lWKPw%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAB3QCOGDPUEWJ27JGN6XRGDSYXLP7ANCNFSM4U3GDDUA&data=04|01|kayw%40microsoft.com|56a36c0b05f84037bd3a08d8b325e1f7|72f988bf86f141af91ab2d7cd011db47|1|0|637456322574047293|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=9QI65ZFurozW8BKX8eDxfHaQWoDGdBJ6jhMZRWRrtPY%3D&reserved=0.

Perhaps 'badge.openssf.org' (and also 'badge' as github repo name)?  We can describe as 'best practices badge' in the text? A question might be, what if we want to introduce another sort of badge later?  We can deal with that at the time, but in general, for simplicity, focus and impact, I think we might want only one badge sponsored by the OpenSSF.  Just thoughts for consideration.
From: David A. Wheeler<EMAIL_ADDRESS>Sent: Thursday, January 7, 2021 8:04 AM
To: coreinfrastructure/best-practices-badge<EMAIL_ADDRESS>Cc: Kay Williams<EMAIL_ADDRESS>Comment<EMAIL_ADDRESS>Subject: Re: [coreinfrastructure/best-practices-badge] Rebrand from CII to OpenSSF (#1515)
https://openssf.org/best-practices-badgehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fopenssf.org%2Fbest-practices-badge&data=04|01|kayw%40microsoft.com|56a36c0b05f84037bd3a08d8b325e1f7|72f988bf86f141af91ab2d7cd011db47|1|0|637456322574037302|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=W57pK3bj%2B%2BbmS9OPrAyzKvoXLZOhZksIoR77fwewKwI%3D&reserved=0
That won't work; it needs its own domain. The best practices badge runs on a different computer system, uses a different programming language, has its own database, etc. We could try to hide that, but that would create a lot of inefficiencies & effort for no obvious gain. It'd be a leaky abstraction anyway, so we're just creating problems.
Since it must have its own domain, there are several options:

Do nothing (always an option).
Something short like "bestpractices.dev".
Something under openssf.org, e.g,. "bestpractices.openssf.org". The problem with this is that the URL is very long. A big complain about the current system is that its URLs are too long.

You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcoreinfrastructure%2Fbest-practices-badge%2Fissues%2F1515%23issuecomment-756208831&data=04|01|kayw%40microsoft.com|56a36c0b05f84037bd3a08d8b325e1f7|72f988bf86f141af91ab2d7cd011db47|1|0|637456322574037302|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=MrlaczIxLYpYw0hc%2B8ax3RfvLjfzfZp8kezLi3lWKPw%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAB3QCOGDPUEWJ27JGN6XRGDSYXLP7ANCNFSM4U3GDDUA&data=04|01|kayw%40microsoft.com|56a36c0b05f84037bd3a08d8b325e1f7|72f988bf86f141af91ab2d7cd011db47|1|0|637456322574047293|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=9QI65ZFurozW8BKX8eDxfHaQWoDGdBJ6jhMZRWRrtPY%3D&reserved=0.

badge.openssf.org would certainly work, it meets the "must have its own domain" criterion. It also clearly associates it with OpenSSF, which is a plus.
It does have some potential downsides:

It's longer than "bestpractices.dev".
As you noted, there is a potential problem if OpenSSF eventually adds more badges.
I suspect lacking "bestpractices" will make it harder to find via search engines when typing "best practices".
It's been mooted that this should submitted for formal standardization. I'm not sure it's the right thing to do, but if we do, having its own domain name like bestpractices.dev might be an advantage.

badge.openssf.org would certainly work, it meets the "must have its own domain" criterion. It also clearly associates it with OpenSSF, which is a plus.
It does have some potential downsides:

It's longer than "bestpractices.dev".
As you noted, there is a potential problem if OpenSSF eventually adds more badges.
I suspect lacking "bestpractices" will make it harder to find via search engines when typing "best practices".
It's been mooted that this should submitted for formal standardization. I'm not sure it's the right thing to do, but if we do, having its own domain name like bestpractices.dev might be an advantage.

Arguably, the current badge program is slanted towards security/integrity topics (rather than, say, usability/UI, or software documentation best practices etc.); at the same time, the current badge is really not only about the core infrastructure. So associating with OpenSSF make sense to me, and "OpenSSF Best Practices Badge" looks spot on.
As for the website name - badge.openssf.org implies the one and only OpenSSF badge, which is not scalable; moreover, it doesn't even say anything about software development, it's somewhat encrypted in the organisation name instead. bestpractices.dev might be a bit too generic but looks pretty cool and very descriptive.

Arguably, the current badge program is slanted towards security/integrity topics (rather than, say, usability/UI, or software documentation best practices etc.); at the same time, the current badge is really not only about the core infrastructure. So associating with OpenSSF make sense to me, and "OpenSSF Best Practices Badge" looks spot on.
As for the website name - badge.openssf.org implies the one and only OpenSSF badge, which is not scalable; moreover, it doesn't even say anything about software development, it's somewhat encrypted in the organisation name instead. bestpractices.dev might be a bit too generic but looks pretty cool and very descriptive.

I have confirmed that we still have the bestpractices.dev domain. It's generic, but it's short & clear, and that has advantages.

I have confirmed that we still have the bestpractices.dev domain. It's generic, but it's short & clear, and that has advantages.

Just to be clear, will the BadgeApp site https://bestpractices.coreinfrastructure.org/en/projects be maintained under the new OpenSSF organization (under a new domain related to OpenSSF perhaps)?
The current status seems a little concerning since when you go to:

https://bestpractices.coreinfrastructure.org/en

it still says "CII Best Practices Badge Program" but at:

https://www.coreinfrastructure.org/

it says:

The Core Infrastructure Initiative (CII) was an effort to improve the security of open-source software.
The CII has been replaced by the Open Source Security Foundation (OpenSSF). Please go to the OpenSSF site for current activities in securing open source software.
This CII website is being retained to preserve historical information and to help with transition to the OpenSSF.

That makes it sound like the CII is no more and the OpenSSF is something new.  It does not suggest that efforts started under the CII will be transitioned to the OpenSSF.
When you go to the site:

https://openssf.org/

and search "Best Practices", there are no hits that mentions this badge program.  The only mention to "Best Practices" that I can find (other than "Security Best Practices") is under the FAQ section "What is the scope of OpenSSF?" at:

https://openssf.org/#faq

which says:

OpenSSF is focused on improving the security of open source software (OSS) by building a broader community with targeted initiatives and best practices. It will start with a focus on metrics, tooling, best practices, developer identity validation and vulnerability disclosures best practices. ...

Does this mean that a new best practices effort will be started under the OpenSSF or will the existing BadgeApp site really get transferred over to OpenSSF?   Given that there have not been any comments in this GitHub Issue since Jan 27, 2021, that might seem to be a little concerning to an outsider.
Just looking for clarification.
Thanks!

As for the website name - badge.openssf.org implies the one and only OpenSSF badge, which is not scalable; moreover, it doesn't even say anything about software development, it's somewhat encrypted in the organisation name instead. bestpractices.dev might be a bit too generic but looks pretty cool and very descriptive.

I have confirmed that we still have the bestpractices.dev domain. It's generic, but it's short & clear, and that has advantages.

There is a strong emphasis on security practices currently on https://bestpractices.coreinfrastructure.org/en/projects but the set of practices is so comprehensive that I think it could justify a more generic title and URL domain.  But I think it would be good to have "opensource" in the name if possible since "bestpractices.dev" is likely too generic.

Well, if there is any ambiguity as to the fate of https://bestpractices.coreinfrastructure.org/en/projects it does not seem to be impacting the usage of the site.  When I look at this back on 6/15/2021, there were 3380 total projects on the site and just now on 8/24/2021 that is up to 4015 and the number of projects listed as "Passing 100%" has grown from 582 to 610 so usage of this site seems to be growing significantly even over the last 2 months.

@bartlettroscoe - thanks for commenting. Some thoughts.

Just to be clear, will the BadgeApp site https://bestpractices.coreinfrastructure.org/en/projects be maintained under the new OpenSSF organization (under a new domain related to OpenSSF perhaps)?

Just to be clear :-), the CII Best Practices badge is already under the OpenSSF organization. It says so directly in both the active website & the README of the code. For example, the website says:

This project was originally developed under the CII, but it is now part of the Open Source Security Foundation (OpenSSF) Best Practices Working Group (WG).

Going further...

https://www.coreinfrastructure.org/
That makes it sound like the CII is no more and the OpenSSF is something new. It does not suggest that efforts started under the CII will be transitioned to the OpenSSF.

The CII really is no more. I originally didn't want to say "everything in the CII transitioned to the OpenSSF" because the OpenSSF could decide what it wanted to take; not everything transitioned. For example, the "grants" program was a timesink & that did NOT transition. It turns out that saying "send us a request if you want money" led to a huge number of people asking for money, but the ones who most needed money often didn't ask.
But I see the current text could be confusing, I'll try to improve it. I think what I'll do it add, "Most CII work, such as the CII Best Practices badge and the research by Harvard, has been transitioned to the OpenSSF".

When you go to the site:
https://openssf.org/
and search "Best Practices", there are no hits that mentions this badge program. The only mention to "Best Practices" that I can find (other than "Security Best Practices") is under the FAQ section "What is the scope of OpenSSF?" at:
https://openssf.org/#faq
OpenSSF is focused on improving the security of open source software (OSS) by building a broader community with targeted initiatives and best practices. It will start with a focus on metrics, tooling, best practices, developer identity validation and vulnerability disclosures best practices. ...
Does this mean that a new best practices effort will be started under the OpenSSF or will the existing BadgeApp site really get transferred over to OpenSSF? Given that there have not been any comments in this GitHub Issue since Jan 27, 2021, that might seem to be a little concerning to an outsider.

If you go to the OpenSSF Best Practices WG site, here:

https://github.com/ossf/wg-best-practices-os-developers

You clearly see that the CII Best Practices badge is a part of it.
The OpenSSF FAQ covers the OpenSSF as a whole; it intentionally doesn't try to repeat what each working group is doing. However, we could make it easier. One way would be to add links (in several places) from the FAQ to the individual working groups. Then it'd be easier to follow the chain.

the CII Best Practices badge is already under the OpenSSF organization. It says so directly in both the active website & the README of the code.

@david-a-wheeler, thanks, that is great to hear.  I should have search for "OpenSSF" on the page https://bestpractices.coreinfrastructure.org/en. It is right there at the bottom of the second paragraph.
However, it is a little confusing with the big "CII" branding on that page and that site and the upper right:

and the first paragraph mentions the "CII" in the present tense:

The Linux Foundation (LF) Core Infrastructure Initiative (CII) Best Practices badge is a way for Free/Libre and Open Source Software (FLOSS) projects to show that they follow best practices.

At first glance that might suggest that that page is out of date when you compare it to the page https://www.coreinfrastructure.org/ which uses "CII" the past tense.

The Core Infrastructure Initiative (CII) was an effort to improve the security of open-source software.

What is confusing here is that the form page is descripting the CII Best Practices Badge in present tense while the latter page is describing the *CII (which is a different thing) is past tense.
Branding is a hard thing I guess.  If you rebrand the current site/project as something other than CII Best Practices (Badge Program), then people who knew it as the "CII Best Practices (Badge Program)" will not be able to easily find it.  But if you keep the CII branding, it might confusing people like it confused me and think it is part of a now-defunct initiative.
I guess my suggestion would be to play down "CII" and come up with new branding that is somewhat more generic if possible.  Or, keep "CII" but don't ever spell out "Core Infrastructure Initiative" initially except to mention what it used to send for.  Otherwise, I don't know.

Yes, branding is hard. There are literally thousands of documents & sites that refer to the "CII Best Practices badge"; making that happen represents thousands of hours of effort. Renaming everything risks throwing all that work away. And we're having success getting people to use it :-).
I've modified https://www.coreinfrastructure.org/ to say:

In particular, the CII Best Practices badge work continues as part of the OpenSSF Best Practices Working Group, while the CII research conducted via Harvard continues as part of the OpenSSF Securing Critical Projects Working Group.

...with various links. I have hopes that will reduce confusion.
Modifying the enlarged badge image is harder than you think; that requires paying an artist. But it's probably a good thing to do long-term. We could then tweak it to "OpenSSF CII" instead of what's currently spelled out. But let's try to eliminate confusion right now, instead of waiting for that.

I've modified https://www.coreinfrastructure.org/ to say:

In particular, the CII Best Practices badge work continues as part of the OpenSSF Best Practices Working Group, while the CII research conducted via Harvard continues as part of the OpenSSF Securing Critical Projects Working Group.

...with various links. I have hopes that will reduce confusion.

@david-a-wheeler, thanks, that actually helps a lot.  That updated text would have set me at ease immediately with no need for further investigation.
And thanks again for the great work that you and others have done with the CII Best Practices Badge Program!  I was going to be super bummed with the thought that it might not be continued.  I just hope I can be successful in selling it in my little part of the world (I am working on a short article on it right now actually).

I've made a number of additional edits to the CII website so that visitors to the CII website will quickly realize that things have transitioned over to the OpenSSF, and that the badging & research work continue. For example, I went through the FAQ and edited its entries so it's clearly past tense & points people to the OpenSSF. I think that will reduce the likelihood of confusion in the future.

I just posted the following mail to the CII Best Practices badge mailing list and the OpenSSF Best Practices WG mailing list, with a "cc" to the OpenSSF TAC:
=====
I propose renaming “CII Best Practices Badge” to the “OpenSSF Best Practices Badge”,
as discussed here: https://github.com/coreinfrastructure/best-practices-badge/issues/1515
The "CII Best Practices badge” name has a problem: the
Core Infrastructure Initiative (CII) no longer exists.
For example, at the last OpenSSF governing board (GB) meeting I was asked to
please remove CII from the name since CII doesn’t exist any more.
In addition, searching for “CII Best Practices” is likely to lead you to
Best Practices of the Construction Industry Institute (CII)... which is confusing.
This project as been part of the OpenSSF Best Practices Working Group for a while,
so using the OpenSSF name makes sense. I had worried that this simple name might
be confused with other best practices efforts, but the other efforts have been creating
names that make them easily distinguished anyway (Scorecard, SLSA, etc.). So I think
the risk of confusion isn’t great.
No name is perfect. If someone has a strong objection, though, I’d like to hear it now.
Note: we’ll change the text, and later the logo. We’ll want to eventually switch to a new
shorter domain, with forwarding from the current one, but that’s a separate topic.

Sounds good to me.

I propose an alternate name OpenSSF Practicing Open Source Security Badge.    Both the "CII Best Practices Badge" and "OpenSSF Best Practices Badge" fail to indicate what is being practiced.

@jaltman said:

I propose an alternate name OpenSSF Practicing Open Source Security Badge

I'm not a fan of this. The "Practicing..." phrase is pretty awkward. It looks like we're practicing on unused software so we can someday learn to be secure. This might imply that the criteria are a strict subset of security-specific criteria, but in fact we have criteria about general quality and sustainability (because low-quality or non-sustainable projects end up being driven toward poor security).
Finally, we've used the phrase "Best Practices" everywhere; keeping that phrase will make it easier for people to see a continuation (and also make it easier to find the project if they know the old name).

@jaltman said:

I propose an alternate name OpenSSF Practicing Open Source Security Badge

I'm not a fan of this. The "Practicing..." phrase is pretty awkward. It looks like we're practicing on unused software so we can someday learn to be secure. This might imply that the criteria are a strict subset of security-specific criteria, but in fact we have criteria about general quality and sustainability (because low-quality or non-sustainable projects end up being driven toward poor security).
Finally, we've used the phrase "Best Practices" everywhere; keeping that phrase will make it easier for people to see a continuation (and also make it easier to find the project if they know the old name).

Just because "Best Practices" has been used previously doesn't make it a good name.   Neither "CII Best Practices Badge" nor "OpenSSF Best Practices Badge" describes what the practices are?   Are they best practices for baking chocolate chip cookies?  Or best practices for project marketing?   I think we can do better and name the badge in a way which indicates that its presence means that the project is "practicing" (adjective, "actively working at a profession" or "actively following a way of life or philosophy") that helps secure the open source software ecosystem.
Another suggestion:  "OpenSSF Securing Open Source Badge".

Another suggestion: "OpenSSF Securing Open Source Badge".

Just my two cents but by putting too strong an emphasis on security right in the title, you may turn off projects that are not as security critical (or don't think they are as security critical).  The advantage of the current "CII Best Practices Badge" title is that it  it can attract a wide range of projects and it is not until they dig deeper that they find the high emphasis on security (at which point they have hopefully seen the breath of the practices to know this goes way beyond just security).  And OpenSSF stands for "Open Source Security Foundation" so listing "security" again is just redundant?

@jaltman said:

Just because "Best Practices" has been used previously doesn't make it a good name. Neither "CII Best Practices Badge" nor "OpenSSF Best Practices Badge" describes what the practices are? ...
Another suggestion: "OpenSSF Securing Open Source Badge".

I like this suggestion more.
However, the OpenSSF is itself focused on open source software security, so I think including OpenSSF in the name is enough. That doesn't make it true, but that's my thinking anyway :-).

@.*** @.***>
As stated in the issue, the primary driver of this name change is to rebrand from CII to OpenSSF.  Let's stick with rebranding for now. We can discuss potential renaming in the future as we think more deeply about the relationship of Best Practices Badge, Scorecard, SLSA and other types of software 'labeling' in the future.
One step at a time.
David Wheeler, Brian Behlendorf, I recommend moving forward expeditiously with rebranding the Best Practices Badge from CII to OpenSSF.  The decision to transition CII assets into OpenSSF was made more than one year ago by the OpenSSF GB, TAC and Best Practices WG. This change is non-controversial.  Let's move forward.
From: David A. Wheeler @.>
Sent: Friday, November 12, 2021 10:03 AM
To: coreinfrastructure/best-practices-badge @.>
Cc: Kay Williams @.>; Comment @.>
Subject: Re: [coreinfrastructure/best-practices-badge] Rebrand from CII to OpenSSF (#1515)
@jaltmanhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fjaltman&data=04|01|kayw%40microsoft.com|2c30d8bc4f534d6aa3da08d9a6069de2|72f988bf86f141af91ab2d7cd011db47|1|0|637723369633684810|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=Guk10ugdoDTarAZmRPJ9mruFD6hwRWuOhihZkwFBkis%3D&reserved=0 said:
Just because "Best Practices" has been used previously doesn't make it a good name. Neither "CII Best Practices Badge" nor "OpenSSF Best Practices Badge" describes what the practices are? ...
Another suggestion: "OpenSSF Securing Open Source Badge".
I like this suggestion more.
However, the OpenSSF is itself focused on open source software security, so I think including OpenSSF in the name is enough. That doesn't make it true, but that's my thinking anyway :-).

You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcoreinfrastructure%2Fbest-practices-badge%2Fissues%2F1515%23issuecomment-967311150&data=04|01|kayw%40microsoft.com|2c30d8bc4f534d6aa3da08d9a6069de2|72f988bf86f141af91ab2d7cd011db47|1|0|637723369633694798|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=TmKU0GmolQDlh%2FENbYhRCxvMUOiiiLAxWUmBdWxYFzo%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAB3QCOEIXFMO5HR4BP4LDBDULVJD5ANCNFSM4U3GDDUA&data=04|01|kayw%40microsoft.com|2c30d8bc4f534d6aa3da08d9a6069de2|72f988bf86f141af91ab2d7cd011db47|1|0|637723369633694798|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=3%2FzUsDNMbRrRfUYZx%2Bqz%2FZ8qoxbAFVOaONg77oo0gDk%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01|kayw%40microsoft.com|2c30d8bc4f534d6aa3da08d9a6069de2|72f988bf86f141af91ab2d7cd011db47|1|0|637723369633704800|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=fOxqdTrIjL7CwNxpO8OcR5k4dizmgs6T9t9n930jpeM%3D&reserved=0 or Androidhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04|01|kayw%40microsoft.com|2c30d8bc4f534d6aa3da08d9a6069de2|72f988bf86f141af91ab2d7cd011db47|1|0|637723369633714793|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|1000&sdata=%2BI%2Bhoo7aTMASzCpaaAUCHUhqKaMcDGQOlAb9nB8d94U%3D&reserved=0.

@.*** @.***> As stated in the issue, the primary driver of this name change is to rebrand from CII to OpenSSF. Let's stick with rebranding for now.

My suggestion of alternate names was in the hope there could be quick consensus.   As there is not, Please move ahead with "CII" -> "OpenSSF".

OpenSSF Open Source Best Practices Badge
Gets the rebranding to "OpenSSF", and ADDS the information as to WHAT it is that the best practices are for.

OpenSSF Open Source Best Practices Badge

This gets my vote as the best one so far. :100:

We can discuss potential renaming in the future as we think more deeply about the relationship of Best Practices Badge, Scorecard, SLSA and other types of software 'labeling' in the future.

There's little functional difference between "rebranding" & "renaming", and it's important that we do a rename exactly once and never again. There's a lot of work to rename a project like this. For example, a new logo needs to be created by a graphics designer, the new badge display has to get created & everyone who forces image sizes has to change their codes, and all the natural language translators have to make many changes. The biggest effort, though, is getting the word out. I've spent many months getting the word out using this particular name, and it will take many months of effort to get people aware of the new name. Every rename has the risk of losing people; we don't want to lose people twice.

Too bad the core infrastructure initiative wasn't just subsumed into OpenSSF as a sub-initiative. That way we could have just stamped "OpenSSF" onto the logo, added OpenSSF in front of "CII" everywhere it was already printed, and left everything else the same.

@TonyLHansen - can't change the past :-). In any case, changing the name (even just CII to OpenSSF) is a big deal, because it's going to take a lot of work to get that information out to everyone.

If there's a lesson to be made here, isn't that to not embed the org name in the product name? Or are we in a "this will never happen again" mood?

This discussion has become longer, but I guess that's expected.
This discussion led to several possible names:

OpenSSF Best Practices Badge
OpenSSF Open Source Best Practices Badge
OpenSSF Securing Open Source Badge
OpenSSF Practicing Open Source Security Badge

I would definitely prefer the first two names over the others. Would it be okay to put just those two out for a vote? We could include all 4, but then I'd probably want to use ranked voting and that's more complicated.

@bagder said:

If there's a lesson to be made here, isn't that to not embed the org name in the product name? Or are we in a "this will never happen again" mood?

Ouch! Yes, that's possibly a good lesson to learn. But there's a strong desire in everyone I've at the OpenSSF I've talked to that it should include the foundation name, if nothing else because it clearly distinguishes it.
"Never again" is hard to prove :-). But I don't think a new org is likely in the forseeable future. It turns out to be really hard to get many different organizations to work together & I doubt anyone will want to re-do the work. Also, the CII had some crazy rules about unanimous agreement before some things could happen - and trust me, it's hard to get unanimous agreements about anything. The OpenSSF is imperfect, like all things involving humans, but they've avoided that & learned other lessons.

By the way, if we name the project "OpenSSF Best Practices Badge" or "OpenSSF Open Source Best Practices Badge", we would probably have the short badge show text like this:
openssf best practices | passing
The badge is currently wide, and this would make it slightly wider, but it should still be acceptable.

it should include the foundation name

Yeah, I totally understand where that is coming from. I should probably have used some kind of tongue in cheek emoji... :grin:

Option #2 feels redundant.  If we were to expand OpenSSF, the name would be:
Open Source Security Foundation Open Source Best Practices Badge.
#1 says the same thing as #2, but with fewer words.
My recommendation would be to go with #1 (and avoid the vote).
From: David A. Wheeler @.>
Sent: Friday, November 19, 2021 9:19 AM
To: coreinfrastructure/best-practices-badge @.>
Cc: Kay Williams @.>; Comment @.>
Subject: Re: [coreinfrastructure/best-practices-badge] Rebrand from CII to OpenSSF (#1515)
This discussion has become longer, but I guess that's expected.
This discussion led to several possible names:

OpenSSF Best Practices Badge
OpenSSF Open Source Best Practices Badge
OpenSSF Securing Open Source Badge
OpenSSF Practicing Open Source Security Badge

I would definitely prefer the first two names over the others. Would it be okay to put just those two out for a vote? We could include all 4, but then I'd probably want to use ranked voting and that's more complicated.

You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcoreinfrastructure%2Fbest-practices-badge%2Fissues%2F1515%23issuecomment-974258178&data=04|01|kayw%40microsoft.com|c979470f82184e4999bb08d9ab80a4c5|72f988bf86f141af91ab2d7cd011db47|1|0|637729391281161896|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=WFxq0W94QfTxRmzUeVRX%2F8QpSy58s8dh%2FyFSFpiZs8g%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAB3QCOHIP22N3R2OPX4X42LUM2BHLANCNFSM4U3GDDUA&data=04|01|kayw%40microsoft.com|c979470f82184e4999bb08d9ab80a4c5|72f988bf86f141af91ab2d7cd011db47|1|0|637729391281171890|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=Zt6h4Q7gKuL%2BN7A1Psnbi2uQknJL%2F6N3Fx0Q4CF7HFo%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01|kayw%40microsoft.com|c979470f82184e4999bb08d9ab80a4c5|72f988bf86f141af91ab2d7cd011db47|1|0|637729391281181886|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=5kEuIT3ngVw8nSzJKG4t%2BGueM1hfQfexn468dqML8Nc%3D&reserved=0 or Androidhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04|01|kayw%40microsoft.com|c979470f82184e4999bb08d9ab80a4c5|72f988bf86f141af91ab2d7cd011db47|1|0|637729391281181886|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=wz0MpnQp%2Fv9eZ90OTiTdQmZ%2F2Opi5RuAEWpB1iu%2BL88%3D&reserved=0.

I thought about the redundancy aspect when I suggested "OpenSSF Open Source Best Practices." Despite that, I still think it is superior. The term "open source" can be though of as an adjective used in two entirely different contexts. But the problem pointed out several times above is that we need to have something descriptive for "Best Practices", and "OpenSSF" is definitely not a good descriptor for the best practices that the badge is about.

After thinking it over, I'd rather just have as the name "Open Source Security Foundation (OpenSSF) Best Practices Badge", aka OpenSSF Best Practices Badge. I think long names are a problem; we want a name that's short & unique. The phrase "Open Source" is part of OpenSSF; I don't think we should say it twice. Just imagine what GitHub badge would look like if we wanted to have the full name in there; it's already one of the longest in the world (yes, I know the image could be shortened, but it's easier to justify if the name isn't as long).
How strongly do some people prefer the longer name?
(Sorry I haven't been as responsive, I've been busy on the Great MFA Distribution Project.)

+1 to OpenSSF Best Practices Badge
From: David A. Wheeler @.>
Sent: Tuesday, December 14, 2021 3:43 PM
To: coreinfrastructure/best-practices-badge @.>
Cc: Kay Williams @.>; Comment @.>
Subject: Re: [coreinfrastructure/best-practices-badge] Rebrand from CII to OpenSSF (#1515)
After thinking it over, I'd rather just have as the name "Open Source Security Foundation (OpenSSF) Best Practices Badge", aka OpenSSF Best Practices Badge. I think long names are a problem; we want a name that's short & unique. The phrase "Open Source" is part of OpenSSF; I don't think we should say it twice. Just imagine what GitHub badge would look like if we wanted to have the full name in there; it's already one of the longest in the world (yes, I know the image could be shortened, but it's easier to justify if the name isn't as long).
How strongly do some people prefer the longer name?
(Sorry I haven't been as responsive, I've been busy on the Great MFA Distribution Project.)

You are receiving this because you commented.
Reply to this email directly, view it on GitHubhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcoreinfrastructure%2Fbest-practices-badge%2Fissues%2F1515%23issuecomment-993970611&data=04|01|kayw%40microsoft.com|30e46fa69096401e472d08d9bf424386|72f988bf86f141af91ab2d7cd011db47|1|0|637751113598543496|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=4ks55mvgOCGZPazotn7DO7WmqEeNrzwu9O2koIsxzU0%3D&reserved=0, or unsubscribehttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FAB3QCOBIL3JB5NA2O3UM75DUQ6T3ZANCNFSM4U3GDDUA&data=04|01|kayw%40microsoft.com|30e46fa69096401e472d08d9bf424386|72f988bf86f141af91ab2d7cd011db47|1|0|637751113598593473|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=BMslO0wpTTe%2BNqHmDbr5rQ3koX0GORRHPTNsz3%2BWxE4%3D&reserved=0.
Triage notifications on the go with GitHub Mobile for iOShttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fapps.apple.com%2Fapp%2Fapple-store%2Fid1477376905%3Fct%3Dnotification-email%26mt%3D8%26pt%3D524675&data=04|01|kayw%40microsoft.com|30e46fa69096401e472d08d9bf424386|72f988bf86f141af91ab2d7cd011db47|1|0|637751113598593473|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=%2FhSRHtPZItA5W%2BnbhoIN4AYZNs4PcXpC3NflMkygqY8%3D&reserved=0 or Androidhttps://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fplay.google.com%2Fstore%2Fapps%2Fdetails%3Fid%3Dcom.github.android%26referrer%3Dutm_campaign%253Dnotification-email%2526utm_medium%253Demail%2526utm_source%253Dgithub&data=04|01|kayw%40microsoft.com|30e46fa69096401e472d08d9bf424386|72f988bf86f141af91ab2d7cd011db47|1|0|637751113598593473|Unknown|TWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D|3000&sdata=t5w%2FqbnJVEMLnisoeVwKm8VLpdovHGX%2Fcb9HmwE3p0Q%3D&reserved=0.

concensus rules. (Perhaps the badge or the "shortened form" can emphasize the "Open Source" part?)

BTW, I definitely plan to include on the website "(formerly named the CII Best Practices badge)" so that someone looking for it will figure it out :-).

+1 I definitely still agree with that

The first step is here, this just changes the text:
https://github.com/coreinfrastructure/best-practices-badge/pull/1713
Changing logos, the badge image, URLs, and such will need to be separate steps.

As of 2021-12-24 we have renamed on the production site.
I'm closing this one. We will want to move to a new URL (probably bestpractices.dev) with a redirect, but that's a separate matter.


XCB setMouseCursor

Adds setMouseCursor() function for linux as per issue #269. Please tell me what to put for doxygen comments and anything else to change.
#include <SFML/Graphics.hpp>

int main()
{
    sf::RenderWindow window(sf::VideoMode(800, 600), "My window");
    window.setMouseCursor(142);

    while (window.isOpen())
    {
        sf::Event event;
        while (window.pollEvent(event))
        {
            if (event.type == sf::Event::Closed)
                window.close();
        }
        window.clear(sf::Color::Black);
        window.display();
    }

    return 0;
}

Can you please squash you two commits into one and use a proper commit message?
The discussion on this PR or the feature itself can be found on the forum.

No idea how to do either of those things.

http://git-scm.com/book/en/v2/Git-Tools-Rewriting-History

Well, I only made things worse. I give up.

Your implementation uses the built-in cursor font instead of the themed font. You should look into how to use the themed font, or simply use xcb-cursor.
Also, what does 142 mean? You should have an enum or something with the common cursor types.

I updated it to use xcb-cursor. Also I implemented setting cursor to image
xcb-cursor takes strings so new syntax is:
window.setMouseCursor("watch");

For images:
 sf::Image cursor;
	if (cursor.loadFromFile("pencil_1.png"))
		window.setMouseCursor(cursor.getSize().x, cursor.getSize().y, cursor.getPixelsPtr());

I dunno if i got all the tabs. I can't tell. Still no idea where / how I put / make enum so any guidence on that would be appricated.

Windows and Linux now work. I'm having trouble figuring out os x...

Superseded by #827.


Deprecate _py2_no_more_posargs

Description
Deprecate the use of _py2_no_more_posargs
Fixes #324
How Has This Been Tested?
Travis-ci tests.
Checklist

[ ] I have added tests that prove my fix is effective or that my feature works
[x] I have updated the README.md and other documentation, or I am sure that this is not necessary
[x] I have added a consice human-readable description of the change to CHANGELOG.md
[ ] I have added docstrings to newly created methods and classes
[ ] I have optimized the code at least one time after creating the initial version

Related to #301


Handled sinatra errors being reported to Appsignal

In Sinatra, env['sinatra.error'] is set when an error is encountered. However, this is never unset by Sinatra. The result is that all errors are sent to appsignal, including the handled ones.
This is difficult to work around, as unsetting env['sinatra.error'] causes some error handlers (example: not_found to be run twice. (Sinatra does not expect you to unset this variable).
IMO, the fix is to remove this line from the Appsignal agent, and recommend users put enable :raise_errors in their Sinatra app. This will ensure that unhandled exceptions are raised, and subsequently caught, by the Appsignal agent.
There's no way (as far as I know) to figure out whether raise_errors is on for any particular app. So something like this wouldn't work: transaction.set_error(env['sinatra.error']) if env['sinatra.error'] && !raise_errors

I take back the part where users should enable raise_errors. The correct approach (again, IMO) is to add Appsignal.add_exception(env['sinatra.errors']) to your error handler that shows your 500 page.

Also, on a minor note, I think your sinatra instructions are out of date in your app. It still says to include this line: use Appsignal::Rack::Listener, but Appsignal::Rack::Listener disappeared somewhere pre-1.0.

Thanks for the report @derekkraan! I'm doing some research on this later this week and will get back to you.

I'm not sure how to handle this issue yet. I agree with you that encouraging raise_errors is probably a better approach.
The problem is that I have no way of knowing which customers rely on the existing behaviour. So if we remove this line error reporting might stop when they upgrade without them noticing. I'm thinking we could introduce a config option to disable this. Would that work for you?

Actually, I think raise_errors is not the way to go. With Rails, the problem is easy to solve: you put your error-reporting middleware somewhere underneath the Rails error page middleware. Sinatra doesn't handle error pages with middleware: error pages are handled within the app, before you go back up the middleware stack. So there is no "after the error is generated, but before the error is caught by the error pages" place in the middleware stack to put your middleware.
Therefore, the most correct way (IMO) is for users to add Appsignal.add_exception(env['sinatra.errors']) to their error page handler and for the gem to do no further detection.
I suspect that all your Sinatra users are reliant on the current behaviour of the gem. Otherwise, they are silently using a monkeypatched version of your gem, which seems unlikely. There is apparently a way to print a message on the screen when the user installs or upgrades a gem (at least, I see many gems doing this, so it must be possible).
Anyways, a config option would work for us. It's certainly better than maintaining a monkeypatched version of the gem.

I've finally had some time today to dive into this. It turns out the raise_errors setting is accessible from the middleware. Could you take a look at #111? Does that fix the issue for you?

I don't think so. In our setup, we have raise_errors turned off, which means that we use sinatra's error handling mechanism to show error pages when an error occurs. So Sinatra does not propagate exceptions up through to the middleware (except through env['sinatra.error']).
This is pretty typical of a Sinatra app, I think, which is why you guys have added the line
          transaction.set_error(env['sinatra.error']) if env['sinatra.error']
in the ensure block of your error-reporting middleware.
The problem with this approach is that Sinatra never clears env['sinatra.error'] even when the error is handled. In fact, if the user has raise_errors turned off, there is no way for you to know in the middleware whether a particular error has been handled or not by the application.
The main architectural issue (at least, the reason why this approach does work in Rails but not in Sinatra) is that Rails does error pages in a middleware (so you can put your middleware between the app and the error pages middleware), but Sinatra does error handling (if raise_errors is false) in the app, so there is no way for you to get your middleware between the app and the error pages.
That's why I suggested that your users might have to add Appsignal.add_exception(env['sinatra.errors']) to their error page handler when applicable (we have this line in our "500" error handler but not in our "404" error handler for example).
The other possible solution for us would be to turn on raise_errors, extract our error_pages handler to a middleware and insert that higher in the middleware stack than the AppSignal middleware. In that case, your fix would be sufficient.

I understand the issue you're describing, I just don't have a clear fix for it at the moment. We cannot change the current behaviour since I have no way of knowing who is relying on the current behaviour and we would completely break their error reporting next time they do a bundle update.
I actually got the idea for this fix from the last paragraph of the original issue text.  Did anything change about this possible solution in the meantime?

I agree, there is no obvious good fix. To be clear: I think your fix is an improvement (for those with raise_errors enabled), but with raise_errors disabled, it still won't work properly.
We also tried clearing env['sinatra.errors'] in our error handler, so it's definitely not a dumb question. This is already a while ago, so I don't remember the details completely, but apparently Sinatra doesn't like it when you do that and will run some error handlers twice.
I could look at this again, but I think what we will do when you release a version of the gem with this fix in it is to enable raise_errors, extract our error handlers to a middleware, and place that above the AppSignal middleware in the stack. Then at least we will have a workable solution with the stock Appsignal gem.

There is one other solution: We could add unless env['sinatra.skip_appsignal_error'] to the ensure block. You could then set this to true to skip the error. Would that be a better solution for you?

This would help us out, yes. Then we could go back to the vanilla appsignal gem.

@derekkraan I've implemented this mechanism, does this work for you?

@thijsc yes, this will work for us. Thanks!

This has now been released in 1.2.1.beta.2. Could you give it a try @derekkraan?

This has now been released in 1.2.1.


Reduce timeout for 429 errors?

Since imgur apparently returns HTTP error 429 for nearly everyone trying to download MP4s, would it be a good idea to drop the retry count drastically?
Right now almost everyone is wasting time waiting for the 429 to timeout after like 10 attempts, instead of focusing on the JPGs and PNGs that can still be downloaded.

This problem was specifically for mp4s, and is handled in commit https://github.com/ArchiveTeam/imgur-grab/commit/aed938aab47fb56d4dfefe0e08791b1c60b22e1f. Therefore I'm closing this PR. Feel free to make another PR/issue if the 429s are problematic for another aspect other than bans in case of too high concurrent.


Set higher limits to the requests

Description
Changes proposed in this pull request:

...
...
...

Related issue(s)

/retest


Multiframe

Codecov Report

Merging #268 into master will decrease coverage by 0.26%.
The diff coverage is 93.78%.

@@            Coverage Diff             @@
##           master     #268      +/-   ##
==========================================
- Coverage    92.5%   92.23%   -0.27%
==========================================
  Files         190      193       +3
  Lines        9689    10335     +646
==========================================
+ Hits         8963     9533     +570
- Misses        726      802      +76

Impacted Files
Coverage Δ

malcolm/modules/ADCore/parts/__init__.py
100% <ø> (ø)
:arrow_up:

malcolm/core/controller.py
96.09% <ø> (+0.97%)
:arrow_up:

malcolm/imalcolm.py
16.11% <0%> (-2.83%)
:arrow_down:

malcolm/core/__init__.py
20.83% <0%> (ø)
:arrow_up:

...modules/scanning/controllers/runnablecontroller.py
90.99% <100%> (-2.3%)
:arrow_down:

malcolm/modules/ADCore/util.py
100% <100%> (+3.09%)
:arrow_up:

malcolm/modules/demo/parts/filewritepart.py
100% <100%> (ø)
:arrow_up:

malcolm/modules/ADAndor/parts/andordriverpart.py
100% <100%> (ø)
:arrow_up:

malcolm/modules/ADPandABlocks/parts/__init__.py
100% <100%> (ø)
:arrow_up:

malcolm/modules/scanning/parts/__init__.py
100% <100%> (ø)
:arrow_up:

... and 32 more

Continue to review full report at Codecov.

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


[feature request] Make :first-dispatch optional?

Thanks for this useful library.
I ran into a usecase where I definitely want to use this to wait for the completion of several concurrent events that does not have a concrete initiator. and thought it would be nice to make :first-dispatch optional.
Just throwing this out there, and have not thought through whether more people would shoot their own foot or not in this case.

I also would like first-dispatch to be optional.  Currently I am forced to use it when it is not needed for my application. I am merely using this library to trigger some events when other events occur.


GH-2812 set scope for commons-codec in actual dep, not mgmt

GitHub issue resolved: #2812
Briefly describe the changes proposed in this PR:

removed scope declaration for commons-codec from root pom dependencyManagement section, moved to specific dependency usages in module poms
removed old version number for commons-codec 1.11 from tools module

PR Author Checklist (see the contributor guidelines for more details):

[ ] my pull request is self-contained
[ ] I've added tests for the changes I made
[ ] I've applied code formatting (you can use mvn process-resources to format from the command line)
[ ] I've squashed my commits down to one or a few meaningful commits
[ ] every commit message starts with the issue number (GH-xxxx) followed by a meaningful description of the change
[ ] every commit has been signed off

This change looks trivial enough but I'm a little panicky about it unintentionally breaking things. I know we've had some difficulties with incompatible versions of various commons libraries in the past. @barthanssens I believe you may have some experience with that?

We may want to do this more generally for the managed dependencies in the root pom: get rid of the scope tags, and move them to the appropriate places in the dependencies.

@hmottestad @barthanssens I have done a general cleanup of dependency management: a lot of our managed dependencies were declared  twice (both in the root pom and the tools pom) - probably a leftover from merging the multi-repo setup. I've also removed the scope declaration from all managed dependencies. As @reckart pointed out it is better practice to only manage versions, and let scope handling be done at the point where the actual dependency is declared (to avoid weird surprises in downstream projects).
I've ran the project locally and this all works as expected as far as I can tell. I do want to run a quick distribution build to make sure no dependencies that shouldn't be there have now sneaked into the SDK archive or the onejar.

If there are no objections I will merge this today.


Resource Spawner plugin showing owner's name twice

Environment

OS Version: Ubuntu 20.04 Focal
Source or binary build?
both

Description

Expected behavior: Under "Fuel resources" expected to see owner's name appear in list once.
Actual behavior: Owner's name appears twice but when one name is clicked it highlights both (the same owner name).

This was tested in both source and binary builds and does not happen on Ubuntu Bionic.
Steps to reproduce

ign gazebo
Add "Resource Spawner" from plugin menu
Wait for fuel resources to be finished loading

Output

Fixed by #1962


Openupgradelib not compatible (caused by new rename_fields method)

Hello,
first of all I would like to thank you for this great piece of software. While the learning curve was steep and not everything is working perfectly in my case yet, it is still tremendously valuable.
For the issue I am not sure where it fits best. It involves OpenUpgrade, openupgradelib and (docker-odoo-base)[https://github.com/Tecnativa/docker-odoo-base]. Because I was able to bugfix it in docker-odoo-base, I am posting it here.
Since introduction of the "rename_fields" in openupgradelib and changes in migration scripts, OpenUpgrade crashes with an error "'module' object has no attribute 'rename_fields'". The problem is caused by https://github.com/Tecnativa/docker-odoo-base/blob/master/8.0.Dockerfile#L120 which installs the latest version of openupgradelib from pip. This release does not yet contain the "rename_fields" method.
I was able to fix this issue by creating my own copy of 8.0.Dockerfile and replacing "openupgradelib" with "git+https://github.com/OCA/openupgradelib.git@master".
Best Regards.

That's not needed. Simply put in your pip.txt file of your scaffolding:
git+https://github.com/OCA/openupgradelib.git@master

And it will be used as the final version in your Docker instance.

Ok, learned something new again. Thank you for the solution and the very fast reply!

Yeah, we have found the same problem in the past, but since the fix is so simple, we decided that it's better to bundle the latest officially released version of the library instead, and let individual implementations that need the master version just add it to the project's requirements.
Glad you found this useful @sfeilmeier, if you think any part of the docs can be improved, please open a PR for the README and we can consider it 😉


TO API - profiles route no longer supports "includeParams" query param

For example
GET /api/1.2/profiles/417?includeParams=true (perl) returns the parameters associated with the profile
whereas
GET /api/1.3/profiles/417?includeParams=true (golang) does not.

IMO just include the params with the GET /api/1.3/profiles/:id so the ?includeParams query param can be deprecated.

Yes just ignore the includeParams because /api/1.2/profiles/417 will always return it.  Retrieving a Profile without it's parameters seems silly.


Does anybody want to develop a ruleset for umatrix?

I am currently developing a rule-set for umatrix, given all the thirdparty tracking sites. Does anybody want to contribute to it?
We can do this in this repository (if drduh is ok with it) or outside
I didn't find too many good rule-sets for umatrix
Do the blacklists already block these tracking sites?

Has anybody verified the blocklists mentioned in the main article are blocking the trackers on most of the websites?
umatrix shows a huge number of trackers

umatrix is no more maintained (status: public archive), must use ublockorigin
https://www.ghacks.net/2021/07/15/umatrix-has-an-unfixed-vulnerability-here-is-a-workaround/

Badness enumeration don’t work.
you will end in endless maintenance and a lot broken sites.
This can also be done with DNS and lists like OISD in a lot better way.

Yes, for sure, you can do it one at a time and also specifically block loading from sources on per site basis. The advantage of uMatrix is that it shows all the sites that are loading right on the interface, which makes it much more convenient to block sites that are not relevant.
Do you have a way to do that using uBlockOrigin, WireShark etc, as quickly?
I have seen that certain resources that are necessary for certain websites to render correctly, are not necessary for others. uMatrix allows you to do per site blocking, which speeds up loading sites a lot.
Does uBlockOrigin/OISD allow you to do that, as quickly?

Badness enumeration don’t work.
you will end in endless maintenance and a lot broken sites.

Its not that bad. I have had a fixed configuration for a while for sites that are well-tested, and it works very well repeatedly. Ofcourse overtime, certain sites could add other sources, which would requires some maintenance

This repo in general I believe manages to stay very relevant by staying up to date with this information it provides. While I do see blocklists as a useful tool and technology as pointed out about the uMatrix repo has been archived. Instructing use of outdated tools in the security leads to all kinds of problems. If there is an active tool being used that has these same features I think that could be useful but otherwise I would leave uMatrix out

Thats a good point @johnsoga. uBlockOrigin is mostly an adblocker. Do you know anything else like uMatrix? Which is more like a web firewall with granular permissions?

@AndrewtheCanon so admittedly I cannot say I was well versed with the uMatrix utility so I took a bit of time to take a look at the repo. Looking it over I have to say I really don't see the difference compared to UBlockOrigin. I kind of disagree with this idea of calling it a "web firewall" but maybe I'm just missing what this particular functionality is that it has to be called such.

I am currently developing a rule-set for umatrix, given all the thirdparty tracking sites. Does anybody want to contribute to it?

Sounds like your trying to build a block list for ads/trackers which is what uBlockOrigin allows. Which I'd be more than happy to help contribute towards. Let me know how I can help.

Yes, for sure, you can do it one at a time and also specifically block loading from sources on per site basis. The advantage of uMatrix is that it shows all the sites that are loading right on the interface, which makes it much more convenient to block sites that are not relevant.
Do you have a way to do that using uBlockOrigin, WireShark etc, as quickly?

Clicking on the UBlockOrigin plugin icon it looks there is a "Open the Logger" option that seemed to do what you were asking for when I tried it. It showed all the elements/domains being loaded on the web page I was on. I think this might be what you are looking for. I don't think wireshark would be necessary here and would probably be a lot harder to filter through to get the result you are looking for.

I have seen that certain resources that are necessary for certain websites to render correctly, are not necessary for others. uMatrix allows you to do per site blocking, which speeds up loading sites a lot.
Does uBlockOrigin/OISD allow you to do that, as quickly?

UBlockOrigin seems to support Dynamic Filtering which I think supports what you are asking for using local dynamic filtering rules


Need documentation on programmatically adding data sources

I have a list of a few hundred data sources to add.  How do I do that without tippy-tapping every one of them in manually?

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

ID: 58eaf5cf-f2f4-785c-a766-38e1868bf820
Version Independent ID: 5f8db39f-c5bd-c7ce-5258-c8b47cb83c7f
Content: Manage your data source - SQL - Power BI
Content Source: powerbi-docs/service-gateway-enterprise-manage-sql.md
Service: powerbi
GitHub Login: @mgblythe
Microsoft Alias: mblythe

Adding @arthiriyer to comment on whether you can add datasources programmatically. Also adding @markingmyname in case we cover this in the dev docs.

Okay, so I know you can create manage data sources programmatically.  If you waste enough time searching, you can eventually find incomplete documentation: https://docs.microsoft.com/en-us/rest/api/power-bi/gateways/createdatasource
I don't know if detail should go here or there.  A link to the REST API documentation might help here, but only if that REST API documentation is completed.  What I've noticed is missing so far are details on the composition and construction of the credentials object and working with gateway clusters instead of individual gateways.  I'm sure there's lots more.

@jordanmills thats correct- the APIs should help to create it programatically. Thanks for your feedback- we are working on enhancing the gateway documentation.

We added a link to the REST API, and I will share your feedback with the team that maintains the REST API docs. Thanks!