Truncate long commit message header

Make the message-wrapper style no longer require being inside a commit-list.

Hmm... If I stick this style on the appropriate element in templates/repo/view-list.tmpl then we get appropriate sizes.
style="max-width: min(calc((max(100vw, 768px) - 768px) * 800 + 20rem), calc((max(100vw, 992px) - 992px) * 800 + 360px), calc((max(100vw, 1200px) - 1200px) * 800 + 500px), calc((min(100vw, 1200px) - 1200px) * (0 - 800) + 700px));"

Current problems:

OK I think it's fixed.
@silverwind could you take a look? I've used 90vw - I dunno if that's allowed?

Does it work with the CI icon shown? I'm still not a fan of CSS truncation here in general, it's always rather hackish because it's a table, not a flexbox. We could opt to do what GitHub does and make the header line a flexbox but that'd require a quite a few changes.

90vw seems like an arbitrary value but if works in most cases, I guess I'm fine with such hacks until we can convert it to flexbox (then it's just flex: 1 on the parent and a wrapping <div> with overflow: hidden + ellipsis).

@silverwind I guesss calc(100vw - 50px) might work better?

Codecov Report

Merging #10301 into master will decrease coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master   #10301      +/-   ##
==========================================
- Coverage   43.74%   43.71%   -0.03%
==========================================
  Files         585      585
  Lines       81015    81015
==========================================
- Hits        35441    35419      -22
- Misses      41179    41212      +33
+ Partials     4395     4384      -11

Impacted Files
Coverage Δ

modules/markup/markup.go
76.81% <ø> (ø)
:arrow_up:

modules/markup/markdown/goldmark.go
66.07% <ø> (ø)
:arrow_up:

services/pull/check.go
35.97% <0%> (-17.08%)
:arrow_down:

services/pull/temp_repo.go
29.05% <0%> (-2.57%)
:arrow_down:

services/pull/patch.go
60.37% <0%> (-2.52%)
:arrow_down:

models/notification.go
63.29% <0%> (-1.9%)
:arrow_down:

models/pull.go
41.82% <0%> (-0.56%)
:arrow_down:

modules/log/event.go
65.64% <0%> (+1.02%)
:arrow_up:

... and 6 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 2d4edcd...fe4baa0. Read the comment docs.


the parameters are only 43196001, instead of 43524961

I run the default Conddetr-r50, but the num of parameters is different from that in the provided log.
Also, after training for 1 epoch, the eval results are
[0.04369693586567375, 0.12083834673558262, 0.023675111814434113, 0.01864211602467282, 0.052261665895792626, 0.07171156446634068, 0.09023536974930606, 0.18654859799415718, 0.22196121793196433, 0.04610799601904764, 0.21023391350986004, 0.3797766209046455],
which is weaker (about 0.7AP) than that in the provided log
[0.0509964214370242, 0.13292741190993088, 0.030383986414032393, 0.015355903493298791, 0.05914294278060285, 0.08176101640052409, 0.10028554935230335, 0.2012481198582593, 0.23517722389597043, 0.04296950016312112, 0.23670937055006003, 0.40016568706711353].

Hi,
Did you enable the '--no_aux_loss' flag? We use aux_loss in training, and disabling this flag might cause fewer parameters as well as weaker performance. Moreover, the AP in the early training stage is unstable. +/- 0.7 AP at epoch 1 is not informative. Consistent lower performance in training  (maybe epoch 1 to epoch 10) might indicate that the training has some problem.

Thanks for your answer.
I did not change the args. And I used aux loss during the training. The args are:
Namespace(aux_loss=True, backbone='resnet50', batch_size=2, bbox_loss_coef=5, clip_max_norm=0.1, cls_loss_coef=2, coco_panoptic_path=None, coco_path='/mnt/lustre/share/DSK/datasets/mscoco2017/', dataset_file='coco', dec_layers=6, device='cuda', dice_loss_coef=1, dilation=False, dim_feedforward=2048, dist_backend='nccl', dist_url='env://', distributed=True, dropout=0.1, enc_layers=6, epochs=50, eval=False, focal_alpha=0.25, frozen_weights=None, giou_loss_coef=2, gpu=0, hidden_dim=256, is_slurm_job=True, lr=0.0001, lr_backbone=1e-05, lr_drop=40, mask_loss_coef=1, masks=False, nheads=8, num_queries=300, num_workers=2, output_dir='output/default', position_embedding='sine', pre_norm=False, rank=0, remove_difficult=False, resume='', seed=42, set_cost_bbox=5, set_cost_class=2, set_cost_giou=2, start_epoch=0, tcp_port='29550', weight_decay=0.0001, world_size=8)
number of params: 43196001
BUT, after 5 epoch training, the model performs just the same as that in the provided logs. So, it might just be the performance fluctuation in the early stage caused by random seeds.
I will keep tracking the performance during the training and update the comment if some other problems happen.

I also encountered the problem of inconsistency in the amount of parameters.


Best approach for adding band QSO filter to map view

For a given frequency band, some summits are much more difficult to activate than other summits. For example, a low-lying peak surrounded in all directions by higher peaks would be much trickier to make VHF contacts on than a summit with high prominence (and better line-of-sight to population areas). I think that adding a filter which allows potential activators to e.g. only look at peaks with a large number of QSOs on the 2 meter band would be helpful for people trying to scout out peaks they can activate with the radios they have. I'm willing to implement the code for this, but as I'm not familiar with the architecture of this repository, I'm hoping for some guidance on how to practically implement this feature.
Rough UI draft:

What I know from skimming the code:

Map view is at src/views/Map.vue
Current filter implementations are at src/components/MapFilterControl.vue

updateFilter() creates an array of all the activated filters, then applies them using setSummitFilter()
setSummitFilter() uses the setFilter() function from mapbox (link) on each of the 5 layers of UI elements for summits: 'summits_circles', 'summits_names', 'summits_activations', 'summits_inactive_circles', and 'summits_inactive_names'

Each of the layers is specified in an asset file for the map type (e.g. src/assets/openmaptiles.json), which in turn uses data from the "summits" source layer

The summit source layer comes from a map server (e.g. for my region https://1.us.map.sotl.as/data/summits.json) which has tiles (e.g. https://1.us.map.sotl.as/data/summits/0/0/0.pbf) which come in PBF format (can be opened with the OSM plugin for QGIS)
Viewing the pbf files confirms that data source stores the summit attributes that the current filters are using (e.g. act, points, alt) but not QSO counts
I'm assuming the PBF files are generated from the summit csv list (link), which has all the summits but no QSO data. Please correct me if this assumption is wrong

Looking at src/components/SummitActivations.vue, I see the https://api2.sota.org.uk/api/bandstats/ endpoint has the data we want but is queryable 1 summit at a time. It's infeasible to call out to SOTA for every summit on the page while panning around.
I poked around the api2 and api-db2 SOTA APIs and didn't find any other endpoints that provide the QSO data for every summit

So, what do you think? Should I reach out to the SOTA folks and convince them to include some QSO data in the summitlist csv, then get that into the map tiles to query just like the other filters? Or is there a better way? If the SOTA admins are worried about increased bandwidth, I think it would still be helpful if the QSO data was combined into 2 groups (HF- and VHF+) as opposed to each individual band.

Hello Kyle,
Apologies for the late reply; I've been busy moving house. Thanks for considering to contribute to the SOTLAS codebase!
Your observations on the inner workings of the map filter are correct. The code that generates the map tiles would need to obtain the per-band QSO counts from the SOTA database (without making a separate request for each and every summit), and include them as properties in the tiles, so that they can be filtered via MapBox GL. So the first step would be to convince the people who maintain the SOTA database and APIs to make the required information available in a bulk format.
For the UI, instead of a long list of checkboxes for selecting bands, perhaps a Buefy Dropdown with multiple selection could be used.
73,
Manuel HB9DQM

No worries Manuel, hope the move goes well! I've filed a request to the SOTA management team on the reflector (link). And thanks for the UI idea too, that sounds a lot cleaner.


No 'diff' command on any of our build images

Currently the automated tests do not do the template comparison, because there is no diff on these images (i.e. diffutils not installed?)

Forum question

Fixed in 1c8206088834c442fcb37466bf81320fd83979a1


add option to show namespaces

two namespaces, same repo name.
it would be nice to have a toggle that also displays the namespace in front of the repository name.

Great point! Plus working on open source repos lends itself to forks.
I'm curious - are those just links directly to the repos, not specific issues or PRs?

Great point! Plus working on open source repos lends itself to forks.

and creating issues tends to lead towards product improvements.
I tend to also create pull requests but in this case I had to go to bed.

I'm curious - are those just links directly to the repos, not specific issues or PRs?

yes indeed. I have a couple link collection notes and just noticed it when scrolling through.
I have also thrown yesterday's GitHub interactions into my primary index, which is what guided me to this answer today :)
now that I think about it, making it possible to see the last comment author name could be another viable feature..
I'll dig into that later.

@GottZ available in v0.7.0


Weird CPUParticles rendering bug

Godot version:
Godot 3.1 RC2, RC3 and stable
OS/device including version:
Manjaro Linux
Issue description:
There's a very weird CPUParticles rendering bug in Godot 3.1. Some particle effects show a single huge particle, even when they are not emitting. Sometimes it goes away when the partcile effect is emitting for the first time. I haven't yet found out why some particle effects do this and others don't. It's difficult to tell what exactly tiggers this behaviour, but I'll try to create a simple example scene that reproduces it reliably.
I've tried the most recent versions and this bug appears to have been introduced in RC2. It doesn't happen in RC1, which was the last version I tested before the 3.1 release. Sadly the other release candidates came so fast that I didn't have a chance to test them in time.
This is what happens in my game since RC2:

This is what should happen:

Can you make a small example with the problem? Also add details about graphics card and driver.

I wonder if its from this commit https://github.com/godotengine/godot/commit/1edc2134c99184f3714c806b7a494026e8f029b2

Graphics card is a Radeon RX 560, and I'm using the open source AMDGPU driver.
At first I didn't have any success making an example project, so I took the scene from my game and removed nodes from it until I could reproduce it in a tiny scene:
CPUParticlesBug.zip
And yes, it looks like it has to do with invisible/inactive particle effects. The scene starts with an invisible CPUParticles node. After a second it becomes visible, and a single huge particle appears. Two seconds later, when the effect starts emitting, it disappears again.
It can even be reproduced in the editor. Load the scene, then make the particle effect visible, then start emitting.


Upload inventory file failed

Describe the bug
An error occured when uploading inventory file
The error:
0		90012	Fatal	The required sku field is missing from the file. To correct this error, download the template again and use the new copy, or insert the required field into your existing file.
Actually I gave it the sku field.
To Reproduce
Steps to reproduce the behavior:
Make a inventory file and use feeds api upload it.
In my case, I uploaded the inventory file with two fields: sku and add-delete.
I want to delete the inventory using api.
Expected behavior
The related inventory can be deleted
Desktop (please complete the following information):
Linux

Hi kunwuliu,
I suggest you use the ListingsItems api then you don't need to upload a feed just with the sku you may be able to delete the listing from your inventory:
from sp_api.api import ListingsItems
from sp_api.base import SellingApiException
from sp_api.base import Marketplaces
import logging

sku_delete = "4X-5ISB-82J1"
seller_id = "yoursellerid"
issue_locale = "es_ES"
marketplace_id = "yourmarketplaceid"

try:

    res = ListingsItems(account=store, marketplace=Marketplaces.ES).delete_listings_item(
        sellerId=seller_id,
        sku=sku_delete,
        marketplaceIds=marketplace_id,
        issueLocale=issue_locale
    )

    logging.info(res)
    result = res.payload
    logging.info(result)

    # This Values are hardcoded

    path = "/delete_listings_item"
    value = 'DELETE'

    logging.info(base.store_data(result, path, value))

except SellingApiException as ex:
    logging.info(ex)

Let me know if it works for you.


Update README.md

Removed Cybersecurity Fundamentals from curriculum

Closes #1055

Please do see the contribution guidelines of the community and don't blindly create pull request. The issue RFC #1055 is there so that we can discuss replacement of CyberSecurity course.

Sorry will do,it is my first time contributing so I created one without much thought😅.

Perfectly fine 😄 OSSU thrives from contributors. Do refer Contribution guidelines bedtime when you contribute.
https://github.com/ossu/computer-science/blob/master/CONTRIBUTING.md

Sure ! Will do thanks a lot for helping out :D


Provide better feedback when the YAML is invalid

We should e.g. post a comment of the error from the validator.

This is done now in https://github.com/jlebon/redhat-ci/commit/f8c2a1ae1ac93f25b5c3560856976f2b50e35583.


Assigning slug & parent to tab/groups

How do you assign the slug & parent fields to tab groups?

It's unfortunate that there's no option for this but what I did was re-export the definePageType and map the fields in the pageTreeType and assign the group to the slug and parent component.
On top of that I've also added a validation for the parent field so that if the current document language is english and you're trying to add a parent a page with french language it will give a validation error. This is optional and you can remove it if you wish.
import {definePageType as _definePageType} from '@q42/sanity-plugin-page-tree'

import {apiVersion} from '../env'
import {Reference, Rule, ValidationContext} from 'sanity'

type Props = Parameters<typeof _definePageType>
type Return = ReturnType<typeof _definePageType>

const DEFAULT_GROUP = 'main'

/**
 * Validates that the parent document has the same language as the current document.
 */
const validateParent = async (parent: Reference | undefined, context: ValidationContext) => {
  if (!parent || !context.document) return 'Parent is required'

  const client = context.getClient({
    apiVersion: apiVersion,
  })

  const document = await client.fetch(`*[_id == $parentRef][0] {language}`, {
    parentRef: parent._ref,
  })

  if (document.language !== context.document.language)
    return 'Parent language does not match the language of this document'

  return true
}

/**
 * Extends the page tree type definition. Adds slug and parent fields to the main group
 * and adds validation to the parent field to ensure that the parent document
 * has the same language as the current document.
 */
export function definePageType(...props: Props): Return {
  const pageTreeType = _definePageType(...props)

  const fields = pageTreeType.fields.map((field) => {
    if (field.name === 'slug') {
      return {
        ...field,
        group: DEFAULT_GROUP,
      }
    }

    if (field.name === 'parent') {
      return {
        ...field,
        group: DEFAULT_GROUP,
        // you can remove this if you wish
        validation: (Rule: Rule) => Rule.custom(validateParent),
      }
    }

    return field
  })

  return {
    ...pageTreeType,
    fields,
  }
}

So for usage it's just like before but you're using your own definePageType instead of the one from the library.

- import {definePageType} from "@q42/sanity-plugin-page-tree"
+ import {definePageType} from "src/utils/definePageType.ts"
import {pageTreeConfig} from 'src/utils/pageTreeConfig'

...
...
export const page = definePageType(_page, pageTreeConfig)

Hope this helps.

@edustef Thanks for providing your workaround, but this should be possible already with the fieldsGroupName option for definePageTree.
@praveensewak I would expect the following to achieve the same:
definePageType('homePage', config, {
  fieldsGroupName: 'main'
})

Also @edustef I see you have made a custom parent validator to help content editors to not configure mismatching parent-child relations with different languages. Great idea! I'll create an issue for this if you don't mind. If you want you can also make a PR for it, otherwise I might add this when I have the time 😄

Hey @djohalo2 thanks for letting us know about the option I had no idea! I think it should be mentioned in the readme somewhere because it's really useful.
As for the parent validator not sure how great the core is as I didn't spend a lot of time on it 😄 but I think it would be awesome to have this into the plugin itself


Get rid of the requirement to manually provision procdump.exe

It is absolutely essential that the ability to collect dumps on test host process crashes can be turned on as simple as possible. It's a huge drain on productivity if every user who wants to do this has to go on a wild goose chase to figure out how to deploy it and add it to the path.
Let's find a way to ensure procdump.exe is included in the agent image, and just use that.

VSTest task carries procdump with it in both yaml and classic pipeline and allows crash dumps to be collected by selecting ""

(input in yaml: diagnosticsEnabled: true)
Debugging issues with setting up procdump can be difficult. When running your pipeline, select to enable diagnostics. The VSTest task will detect this and enable diagnostic run, and upload your logs.

Later you can download them by clicking on your run, and in upper right corner clicking on ... and selecting Download logs.

All our diag logs have extension .diag, and in datacollector.diag you will find additional information about what exactly happened.

When using dotnet test directly for example for testing locally.
On modern frameworks (.NET 5+) you don't need procdump to collect crash dumps, because that ability is built in natively into the runtime. For older frameworks, e.g. .NET Framework 4.7.2 you do need to install procdump.
To still use dotnet test --blame-crash in azdo, without using the task above you can use chocolatey to install it. It is installing into PATH and we check PATH for procdump.
As you shown in other issue you can install procdump using choco reasonably easy (but make sure to only run it on windows):
https://github.com/microsoft/vstest/issues/2957#issuecomment-869059872
- powershell: |
    choco install procdump -y
  displayName: Install Procdump
  condition: and(succeeded(), eq(variables['Agent.OS'], 'Windows_NT'))

Or if you prefer checking OS in powershell directly:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: 'if ($IsWindows) { choco install procdump -y }'
    pwsh: true
  displayName: 'Install Procdump'

On modern frameworks (.NET 5+) you don't need procdump to collect crash dumps, because that ability is built in natively into the runtime. For older frameworks, e.g. .NET Framework 4.7.2 you do need to install procdump.

This is valuable information, it's absolutely not clear from the docs. I shouldn't have messed with procdump since I also updated to 5.0.
Yes I've already figured out the incantations to install Procdump, but unfortunately the process doesn't seem to be crashing when procdump is installed :(
But I understand now that the issue as I filed it doesn't make much sense, because it's unclear whether dotnet test should bring procdump with it. Since the VSTest task already does that, then maybe the right workaround is just to switch to the VSTest task.

Perhaps the DotNetCoreCLI@2 task should be more equivalent to the VSTest task, including bringing procdump with it.
Maybe that's how we should interpret this issue. Using DotNetCoreCLI@2 with dotnet test should be equivalent to using VSTest.

The consensus everywhere is to not use procdump, but use the LocalDumps registry key instead:

Don't use procdump to create dumps when a process crashes. It can cause crashes and is less reliable than the built-in windows registry feature for creating dumps when a process crashes.

https://docs.microsoft.com/en-us/visualstudio/ide/how-to-increase-chances-of-performance-issue-being-fixed?view=vs-2019#crashes
https://github.com/dotnet/roslyn/blob/6543c7086f9154477330b01bb43f45d897f36325/eng/test-build-correctness.ps1#L37-L43
https://github.com/dotnet/roslyn/blob/315c2e149ba7889b0937d872274c33fcbfe9af5f/src/Tools/Source/RunTests/ProcDumpUtil.cs#L55-L63

I think local dumps would work for some scenarios. But what if you have multiple agents on the same system? We definitely don't want to automatically upload dump of testhost and other processes that crashed in a different agent.
There are few pros and cons to localdumps and procdump:
Procdump:
✔ control which process is dumped and where the dump is placed
✔ easy to limit the "scope" of what is dumped
✔ can run in parallel to other test runs
✔ dump on process exit even if there was no exception
✔ good observability because there are logs directly from procdump
❌ must be deployed
❌ has non-trivial performance cost especially with the first chance exception setting
❌ cannot dump all crashing processes
Local dumps:
Imho the inverse of the above.
❌ hard to control which exact process is dumped
❌ hard to limit the scope of what is dumped
❌ affects all parallel runs, and other runs can disable it, or steal our dumps
❌ no option to dump on exit without exception?
❌ difficult to observe without looking into event log
✔ no need to deploy it
✔ small (or 0?) performance cost
✔ can dump any crashing process
Depending on the scenario that is investigated, those pros could be cons, and cons could be pros. When a process is crashing under testhost, and you have a single agent running on the whole system you would be happy to just enable "crash mode", which would collect all dumps, and a lot of stuff from event log.
On the other hand when a build server is running multiple agents, you probably never want to enable all dumps from the system to be collected.

I think the best option here is to continue using procdump, because crash diagnostics are usually enabled when needed, so the more narrow scope is more beneficial here.
In reality there are just a few types of "crashes" that we've seen with testhost:

Critical exceptions, most commonly Access Violation Exception and Stack Overflow exception: Especially when running in the CPP runner, where we call unmanaged code from the managed runner. Those are easy to catch and see from the dump.

The only thing to note is that AVE from unmanaged code gets translated to Null Reference Exception in some cases, which makes it confusing when looking at the log that reports NRE while the dump reports AVE.
.NET (Core) is also much better on spelling out when Stack Overflow happened. The exception shows the whole stack and you don't even need to run it with dumping.

Exits - User asks the process to exit, either via Process.Exit, or via Environment.FailFast. This is harder to diagnose, as we've seen in the case we are investigating. But far from impossible. This definitely needs to be better documented. Useful info is actually in Event log, I know that clould build is collecting that. I am not sure if we should also report it automatically in our pipeline when testhost crash occurs.

The global flags silent exit reporting seem useful for confirming the crash is coming from within the process, but not hugely necessary.

Unhandled exceptions - Managed unhandled exceptions that kill the test host, end up being written into the console, or at least in the log, where we can see them directly.

Hangs - thought these are not crashes, there are a different category of a problem connected to test host run. Those are easy to diagnose with the hang dump collector which does not rely on procdump.

In any case a coprehensive article to describe how to approach this would be nice. And I should write one.
There are also some improvements that could be done:
One improvement that should be done here is that -n 10 (or some other arbitrary number) should be used for the proc dump, because we are looking at first chance exceptions, and procdump only collects the first dump by default. When there is handled AVE in the code, we collect it as dump, but then never collect the actual crashing exception.
Possibly an exit monitor could correlate the exit of process to the dump. Or delete the non-crashing dumps when it sees that the process did not crash after the exception.
A mode for blame data collector, to set procdump to capture unhandled managed exceptions capturing instead of critical errors as we have it now.

Enabling local dumps via --blame is a new feature and won't be implemented, we are focusing on adding new features to Testing.Platform instead.  https://learn.microsoft.com/en-us/dotnet/core/testing/unit-testing-platform-intro?tabs=dotnetcli


{Service Fabric} az sf managed-cluster create: Fix tag parsing for cluster command

az sf managed-cluster

Description

This PR fixes tags for managed cluster commands. It turns out if a with argument context block has a validator defined, child arguments within the block don't get their validators run, so this is explicitly validating tags which parses them into a dict from a list
Testing Guide

[ ] create a managed cluster with tags
[ ] update a managed cluster with tags

History Notes

{Service Fabric} az sf managed-cluster create: Make tags work

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR title and description has followed the guideline in Submitting Pull Requests.

[x] I adhere to the Command Guidelines.

[x] I adhere to the Error Handling Guidelines.

Service Fabric


Adding check for missing NAT

Can you review @kallie-b or @JMesser81 ?
The network cleanup script doesn't recreate the NAT so you can get into a state where Docker thinks a nat is configured but it isn't. This helps detect that and adds steps in the README on how to fix it.

Adding @kallie-b in addition to @JMesser81 to increase odds of review.

LGTM


Add the option to weight variable groups in ClimWIP

Tasks

[x] Create an issue to discuss what you are going to do, if you haven't done so already (and add the link at the bottom)
[x] Give this pull request a descriptive title that can be used as a one line summary in a changelog
[x] Make sure your code is composed of functions of no more than 50 lines and uses meaningful names for variables
[x] Circle/CI tests pass. Status can be seen below your pull request. If the tests are failing, click the link to find out why.
[x] Preferably Codacy code quality checks pass, however a few remaining hard to solve Codacy issues are still acceptable. Status can be seen below your pull request. If there is an error, click the link to find out why. If you suspect Codacy may be wrong, please ask by commenting.
[x] Please use yamllint to check that your YAML files do not contain mistakes

Modified recipe/diagnostic

[x] Update documentation for the recipe to the doc/sphinx/source/recipes folder
[x] Update provenance information if needed
[x] Assign the author(s) of the affected recipe(s) as reviewer(s)

Closes #1853

This first try runs form me. I'm doing some output checks now.
@Peter9192: I decided to split the variable group loop in the main function, I hope that this does not create any unforeseen problems. My main intention there was to make sure that every element in the *_contributions parameters is included and have if raise an error if the group was not in the pre-processor. But I can definitely also solve this differently if you prefer.
(In addition I might add that for our work the overlap between performance and independence groups is normally rather small.)
(And it saves reading the observations for the independence only groups)

Hey @Peter9192 !
I know you are probably still busy but if you have a couple of minutes to look at this it would be great. Maybe this pull request is actually easier to get through as it does not introduce any additional package? Also @ruthlorenz needs the functionality introduced here for some thing else.

Hey @lukasbrunner I was actually waiting with this one until #1864 was merged, to avoid any conflicts. But if it's completely independent, I can have a look now.

Hey @Peter9192 Thanks for the review!! I think I addressed all your comments. I was a bit unsure how exactly to handle the complete skipping of either performance or independence weighting. For now I allow either not setting it at all or setting it to empty. I'm not sure it this creates any unforeseen problems but to me it  seemed most intuitive like this. But I'm happy for any feedback.

@lukasbrunner thanks for the changes. Before I have another look, could you please merge master into this branch? Now that #1864 is merged, we should solve any merge conflicts that might occur.

Thanks again @Peter9192 ! I find these suggestions super helpful to improve my coding style, highly appreciated! I hope I did not overlook anything I could not accept all you your suggestion directly

Nice suggestion, thx!

Okay cool, thanks for accepting all my changes. @bouweandela can you please do the bot magic again? I think I'm not allowed to.. or am I?

@esmvalbot recipe_climwip.yml

Okay one more quick fix. If one does not want to use performance weighting it is now possible to:

set all contributions to zero
not set any contributions but still keep the performance_contributions parameter (commenting out the last three lines below)
not set the performance_contributions parameter at all (commenting out all the lines below)
https://github.com/ESMValGroup/ESMValTool/blob/bba6e3e39312f178a3235c6fdc2b55584d342615/esmvaltool/recipes/recipe_climwip.yml#L91-L94

This Is this correct or should one of these cases not be allowed?
In addition, if either of 1)-3) is true this line can be either commented out or left without a value:
https://github.com/ESMValGroup/ESMValTool/blob/bba6e3e39312f178a3235c6fdc2b55584d342615/esmvaltool/recipes/recipe_climwip.yml#L90

@esmvalbot recipe_climwip.yml

We're on a roll! :muscle:

@bouweandela ping :bell:


Client Allocation Request for: DECO JOURNAL

Client Allocation Questions
Core Information

Name: DECO JOURNAL
Website / Social Media: www.decojournal.co.kr
Region: Asia excl. Greater China
DataCap Requested: 2TiB
Addresses to be Notarized: f3s57spznwngofvuwkuttvnz3n2lwgo7h5lt2hjfpwcoem2mqrsl76nuj6ujcowitd7hcbbeh5o6wfg4shnmwa
Notary Requested: IreneYoung

@subrasy Please subscribe to notifications for this Issue to be aware of updates. Notaries may request additional information on the Issue.

Comment please !!

Hi @subrasy  - Thanks for your application. Please answer the following questions to let us know about you, your company, and further information about the DataCap allocation.

Basic Info

What's your name and your position in your company?

Please introduce yourself and your team briefly. How many team members do you have in your R&D or core team? Could you provide several Github accounts or email addresses of them?

For your organization, Please describe its business, its history since inception, registration country, scale, employee counts, operation regions, named executive officers, relevant projects, industry reputation, etc.

Please show us some of your web pages, Github, social media accounts such as Twitter, Facebook, Naver blog, WeChat official account, etc. Please include as many relevant details to provide contextual information (with external links) to show your Web3 reputation or external reputation.

Please provide your company's business registration license. If you have any presentation documents about your business, please provide them to us. And also could send me via email for privacy concerns. My contact<EMAIL_ADDRESS>

What types of data do you plan to store with the DataCap and how many do you need? Could you please send us some of your sample data?

Regarding the data you intend to store, What’s the original source of those data, and do you have any proof of the ownership or authorization?

Where is your data stored now? Whether the data is stored on a server or a cloud service provider?

Track Record

Has your organization obtained DataCap before? if so, please answer the following sub-questions.
1.1 Please share all the links and recordings of your applications before.
1.2 How about your DataCap usage? Is there any remaining? Is there any information on the deals you've done and the miners you've allocated your DataCap to?
1.3 What was your allocation strategy plan then and how did you execute it?

Are there any disputes open against you from your previous DataCap allocations? If any, please describe any of your honors or disputes in the field of Filecoin.

Allocation Plan

Please describe your plan to use the DataCap as detailed as possible, including use case, amount, timespan, geography, storage providers, partners, etc.

How many regions do you plan to store the data in?

How many storage providers you intend to make dealing with?

Do you plan to record your allocation decisions and execution details in public? And how to realize it?

Do you agree to use the DataCap to only store data that abide by local regulations and is in compliance with the recipient miner’s terms of service?

We may further ask some questions and then give an accurate score to the application. Thank you for your cooperation!

I checked the question well.
We will prepare more and apply again.
Thank you.


Insteon HA integration very slow or not responding

I added my PLM modem to my HA instance in attempts to eliminate my ISY device. While I was successful at adding my insteon switches to HA, they would respond very slowly or not at all. Typically, they would respond normally once or twice, and then just stop, or there would be long delays before a device would respond. Sometimes the delay is 20-30 seconds, other times a couple minutes, or not at all. Occasionally, a device will respond normally for several commands in a row, but inevitably it stops responding or takes an extremely long time to respond.
I reset my PLM and my Insteon switches with hopes that would clean things up. I have only added a single insteon dimmer switch and the same behavior as before. The rest of the Insteon dimmers I have are all offline (pulled the tab out to cut power to them). The PLM only knows of the single dimmer and the dimmer only knows of the PLM.
I'm not sure where to go from here. I've tried different USB ports, rebooted, removed the integration, added it back, etc. Attached are some log extracts that hopefully help. Any recommendations or guidance would be greatly appreciated!
FYI - HA version information:
System Information

version
core-2024.6.4

installation_type
Home Assistant OS

dev
false

hassio
true

docker
true

user
root

virtualenv
false

python_version
3.12.2

os_name
Linux

os_version
6.6.33-haos

arch
x86_64

timezone
America/New_York

config_dir
/config

Home Assistant Community Store

GitHub API
ok

GitHub Content
ok

GitHub Web
ok

GitHub API Calls Remaining
5000

Installed Version
1.34.0

Stage
running

Available Repositories
1385

Downloaded Repositories
11

Home Assistant Cloud

logged_in
true

subscription_expiration
redacted

relayer_connected
true

relayer_region
redacted

remote_enabled
true

remote_connected
true

alexa_enabled
true

google_enabled
false

remote_server
redacted

certificate_status
ready

instance_id
redacted

can_reach_cert_server
ok

can_reach_cloud_auth
ok

can_reach_cloud
ok

Home Assistant Supervisor

host_os
Home Assistant OS 12.4

update_channel
stable

supervisor_version
supervisor-2024.06.2

agent_version
1.6.0

docker_version
26.1.4

disk_total
109.3 GB

disk_used
8.5 GB

healthy
true

supported
true

host_connectivity
true

supervisor_connectivity
true

ntp_synchronized
true

virtualization

board
generic-x86-64

supervisor_api
ok

version_api
ok

installed_addons
Studio Code Server (5.15.0), UniFi Network Application (3.1.0), Advanced SSH & Web Terminal (18.0.0)

Dashboards

dashboards
3

resources
10

views
2

mode
storage

Recorder

oldest_recorder_run
June 23, 2024 at 12:45 AM

current_recorder_run
July 2, 2024 at 8:37 PM

estimated_db_size
152.26 MiB

database_engine
sqlite

database_version
3.44.2

[home-assistant_insteon_2024-07-03T01-20-19.862Z.log](https://github.com/user-attachments/files/16075917/home-assistant_insteon_2024-07-03T01-20-19.862Z.log)
[home-assistant_insteon_2024-07-03T00-52-38.120Z.log](https://github.com/user-attachments/files/16075918/home-assistant_insteon_2024-07-03T00-52-38.120Z.log)

@ChrisMory did you ever find a solution to this? I'm running into the same issues, although I'm using a Hub2.

No, I ended up just going away from Insteon altogether.

From: Nick Gurney @.>
Sent: Wednesday, December 11, 2024 1:38 AM
To: pyinsteon/insteon-panel @.>
Cc: ChrisMory @.>; Mention @.>
Subject: Re: [pyinsteon/insteon-panel] Insteon HA integration very slow or not responding (Issue #39)
@ChrisMoryhttps://github.com/ChrisMory did you ever find a solution to this? I'm running into the same issues, although I'm using a Hub2.
—
Reply to this email directly, view it on GitHubhttps://github.com/pyinsteon/insteon-panel/issues/39#issuecomment-2533758649, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AEMDTRI75EJTLITBYXFG46D2E7MUTAVCNFSM6AAAAABKISW676VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZTG42TQNRUHE.
You are receiving this because you were mentioned.Message ID: @.***>


moved math utility functions to proper files and wrote tests

Please have a look. The functions that have been moved are math utility functions, residing in the wrong class. They have been moved to the classes where they belong, and tests have been written for those functions.

Oops, wrong fork.


Version 0.11.1 freezes after 10-15 minutes

Hi,
an hour ago, or so, I updated to 0.11.1 and since then the tool already 2-3 times freezed and I had to restart it.
The widget and the tool itself freezed, (summary tab, etc.) not just one.
I now jumped back tp 0.11.0.
I use Win10.
Kind regards
Dirk

Hi @FDT-Dirk , i faced the same issue today with this latest version.
Do you know what caused it?

already 2-3 times freezed

And by freezing you mean the network speed is stuck and the graph is stopped yeah? were you still able to navigate the other tabs while frozen?

Hi,
now even my 0.11.0 freezed. When I open the program from taskbar I can jump between all tab's, but no tab and widget are not updating.
Kind regards
Dirk

Hi @FDT-Dirk , fixed the issue. its included in the new v0.11.2 version


Incorrect drawing of Polyline when create a new one

While creating a new Polyline the lines drawn on the Canvas are one vertex behind.
You can see on the right side on the control center that a new point is created. But the canvas is updated only after the next point is clicked.

fixed

fixed


added a more detailed description of the implementation

@unoebauer I think I'm mostly done with this.

Looking very good - are still working on this, @wkerzendorf, or should I merge it?

nope you can merge and also merge to the upstream TEP. I am done with this
one.
On Fri, Feb 5, 2016 at 4:58 PM Ulrich Noebauer<EMAIL_ADDRESS>wrote:

Looking very good - are still working on this, @wkerzendorf
https://github.com/wkerzendorf, or should I merge it?
—
Reply to this email directly or view it on GitHub
https://github.com/unoebauer/tep/pull/2#issuecomment-180414109.

--
Dr. Wolfgang E Kerzendorf
ESO Fellow
European Southern Observatory
Karl-Schwarzschild Str. 2, 85748
Garching bei Muenchen, Germany


compatibility clause to NSS CRDs

not sure if we should change crd in this file: deploy/operator.ibm.com_namespacescopes.yaml


malfunctioning of EditorGUILayout.Popup

selecting editor/enum pop up of unselected node results in selection changes of selected popup this can even be observed in calculation graph example

this issue was because you returned when event was used , editor popups set even as used
private static void CallEventHandlers (NodeEditorInputInfo inputInfo, bool late)
{
object[] parameter = new object[] { inputInfo };
foreach (KeyValuePair<EventHandlerAttribute, Delegate> eventHandler in eventHandlers)
{
if ((eventHandler.Key.handledEvent == null || eventHandler.Key.handledEvent == inputInfo.inputEvent.type) &&
(late? eventHandler.Key.priority >= 100 : eventHandler.Key.priority < 100))
{ // Event is happening and specified priority is ok with the late-state
eventHandler.Value.DynamicInvoke (parameter);
if (inputInfo.inputEvent.type == EventType.Used)
return;
}
}
}
I have current used this  as fix-
[EventHandlerAttribute(-1)] // Absolute third to call! to set focus
private static void HandleSelection(NodeEditorInputInfo inputInfo)
{
if (Event.current.clickCount < 1) { return; }
        NodeEditorState state = inputInfo.editorState;
        if (inputInfo.inputEvent.button == 0 && state.focusedNode != state.selectedNode)
        { // Select focussed Node
            //unfocusControlsForState = state;
            state.selectedNode = state.focusedNode;
            //NodeEditor.RepaintClients();
        }

#if UNITY_EDITOR
if (state.selectedNode != null)
UnityEditor.Selection.activeObject = state.selectedNode;
#endif
}
this would be a more expensive operation but no issues for editor only use

Hm interesting, will take a look if that can be used to fix it. Thanks!

Finally got to merge it, sorry for the delay.


Container started with --rm is always removed. Fixed #6757

Fixes #6757

Can you please sign your commits following these rules:
https://github.com/docker/docker/blob/master/CONTRIBUTING.md#sign-your-work
The easiest way to do this is to amend the last commit:
$ git clone -b "master" git@github.com:spf13/docker.git somewhere
$ cd somewhere
$ git commit --amend -s --no-edit
$ git push -f

I thought part of the issues with this --rm flag was that it was a client-side removal. So, if something went wrong and the connect between the client and daemon was broken the container would live on - or if the container was started in detached mode.  Is there any way we could fix this for good and make it a daemon-side action? IOW, have the daemon persist the --rm flag state in the metadata for the container and then have it delete the container when it stops based on that metadata?

I'm not against this change, but I'd like to point out that it was a design decision.
In case of a docker run that fails, you want to see the logs. I think we should do like docker build, have --rm and --force-rm
--force-rm=false     Always remove the container when it exists
--rm=false           Automatically remove the container when it exits successfully

ping @jfrazelle @LK4D4 @tiborvass

But I kinda also agree with https://github.com/docker/docker/issues/6757#issuecomment-66385871

@vieux why wasn't yours merged way back when https://github.com/docker/docker/pull/7383

@jfrazelle I don't remember :/

I think I'm +1 for this, because the only case where docker run --rm does NOT remove the container, is only when something went wrong on the docker-side of things, not the application itself. docker run --rm --name test busybox false can be run multiple times without name conflict. And when things go wrong on the docker side, the error should be displayed on the client, so no need for docker logs that would only check the application's error. And IMHO, there is no such case where we want the container to stay around even though things went wrong with Docker (not the application).
@vieux let me know if that makes sense.

I'm definitely +1 on server side rm if we can accomplish it without the
race conditions we kept running into last time it was attempted.

@spf13 I'm curious to know why you closed it


feat: add ctor

We can use this in e := &jx.Encoder{} and d := &jx.Decoder{} case

Zero values just work, there is no need for this constructors


If we change the published_date

@tmatsuo
Where I can place the NOW() Function?

@jgacuca567
Thanks, but this seems to be a question rather than a PR. Can you file an issue instead?

Whats the status? Its been 4 months......
@bshaffer
@tmatsuo
I created the issue, already #186


Hide multiselect labels on grants table and grant details

Ticket #984
Description
Hide multiselect labels which aren't necessary and cause overlap issues on smaller screens for certain components.
fixes usdigitalresponse/usdr-gost#984
Screenshots / Demo Video

Testing
Open the various Multiselects (4 on main grants table, 1 on grant details) and observe that "Press enter to select" label is gone.
I didn't write a unit test since there aren't existing tests for these components (right?), and I think the Cypress stuff is just getting started. But if anyone would prefer I'd include one here, I'm happy to do so.
Automated and Unit Tests

[ ] Added Unit tests

Manual tests for Reviewer

[x] Added steps to test feature/functionality manually

Checklist

[x] Provided ticket and description
[x] Provided screenshots/demo
[x] Provided testing information
[ ] Provided adequate test coverage for all new code
[x] Added PR reviewers

@jakekreider Just to follow up with some instructions since it's your first PR (🎉 ):

When you're ready, go ahead and "Squash and merge" this PR.

NB: We often make use of GitHub's auto-merge feature, which will automate merging the PR once all CI checks have passed and the required number of reviewers have approved the PR.

When opening a PR, please self-assign.
You can tag a specific person on the team for review (as you did with me) or add the "usdigitalresponse/grants" team to request review from anyone on the team.
Once merged, the updated _staging branch will deploy to our staging environment, which you can access at https://staging.grants.usdr.dev for manual testing.

We're working on adding Cypress tests to reduce manual testing burden, but there's currently no requirement to include these tests on PRs, since things are still in relatively early stages.

Thanks again for the PR!


Fixed wrong day being displayed in nifty clocks

Small fix where the day of the week is display instead of day of the month.

:) thanks!


Example error

I try run example(node example.js) and recieve error:
var cryptedSessionKey = crypto.publicEncrypt(publicKey, sessionKey);
TypeError: Object #<Object> has no method 'publicEncrypt'

You're need to be using Node.js v0.12.0 or higher for node-steam to work. To easily upgrade to Node v0.12.0:
npm install nvm
nvm install v0.12.0

@andrewda Just fyi, the npm version is outdated - v0.0.3 in npm vs. v0.25.4 in the repo. Definitely use the repo version.

@andrewda, @scholtzm thanks for the help


What are the parameters of eval?

We have a course to reproduce your code, but the parameter of eval is not found. I set train_root to "~" according to the md document, but this caused an error in the setenvironment function in main.py.

你好，我也有相同的问题等待解决，非常感谢！


Investigate using STOMP

We need to start writing the event bus spec soon. The result of the Walking Skeleton was to use RabbitMQ (AMQP 0.9.1 + extensions).
I've never been entirely comfortable with this as it's a specific implementation. While it's open source and easily runnable in a Docker container, it's still something we could have to run on AWS unlike our DBs, caches etc (unless another SAAS like CloudAMQP is used). AWS (and Azure) provide AMQP 1.0 services, which despite the name is very different to 0.9. RabbitMQ has a plugin that supports 1.0, but there seems to be little usage generally (I can't find a PHP client anywhere! The only Python client I can find is Qpid Proton).
AWS actually run ActiveMQ, which supports other protocols in the same way that RabbitMQ does. One of these is STOMP, which does have a decent amount of usage.  So, I've started to experiment whether we can get it to support what we think we need in various implementations:

Topics (messages sent to 0..n consumers, with wildcard routing/subscribing to multiple topics)
Confirmations when sending/receiving
Redelivery and dead lettering
Durability (consumer can disconnect, reconnect and pick up messages sent during that time)
Competing consumers

Managed to get it roughly working with Stomp PHP against both RabbitMQ and ActiveMQ. Planning to get a repo up with examples of both.

RabbitMQ was straightforward, having trouble getting competing consumers in ActiveMQ at the moment.

Bit hidden in the docs, but VirtualTopics are the ActiveMQ solution.

Experimentation in https://github.com/libero/stomp-event-bus-test.

Writing an RFC for this, will close when published.


Time data api error

Get api return error.
Sl departure
Plats id: 9192
Direction: don't matter
Lines: filtered and not filtred
Hämta data: 60 sec
Binary sensor: yes
No result.
Api result
time data '' does not match format '%Y-%m-%dT%H:%M:%S'

🚌

Is this error persistant or was it temprorary?

Permanent (almost)! Est. working 1 day/month.

I'm getting the same exact thing all of a sudden. Was working fine a couple of hours ago

Just set up the sensor and can confirm that I get the same error.
Let me know if there's anything I can help you with in debugging this.

Api error as far as I can see as there is no repeatable pattern but seem to be a load issue with the remote data from api side.


Page 3 of codelab says it will use ObservableFields and then uses LiveData

There are multiple ways to implement observability. You can use observable classes, observable fields, or, the preferred way, LiveData. The full documentation on that is here.
We're going to use ObservableFields as they are simpler.
...

Replace
...
with the new LiveDatas:

It's now on page 7.

It's a year later. The problem is still there.


Fresh wdio-vscode-service project is not starting, because of 3.0.8 vscode-uri

Steps to reproduce:
Create wdio project for vscode extension testing - npm create wdio ./
Run it - npm run wdio
Error:
F:\Projects\webdriver.io\uri-bug>npm run wdio

> wdio
> wdio run ./wdio.conf.ts

Execution of 1 workers started at 2023-10-13T18:31:09.764Z

2023-10-13T18:31:17.841Z INFO @wdio/local-runner: Shutting down spawned worker
2023-10-13T18:31:18.094Z INFO @wdio/local-runner: Waiting for 0 to shut down gracefully
2023-10-13T18:31:18.095Z INFO @wdio/local-runner: shutting down
Error: Error: Failed to initilialise launcher service unknown: Error: Couldn't initialise "wdio-vscode-service".
TypeError: Cannot destructure property 'URI' of '(intermediate value).default' as it is undefined.
    at file:///F:/Projects/webdriver.io/uri-bug/node_modules/wdio-vscode-service/src/server/utils.ts:6:9
    at safeImport (file:///F:/Projects/webdriver.io/uri-bug/node_modules/@wdio/utils/build/utils.js:210:15)
    at async initialisePlugin (file:///F:/Projects/webdriver.io/uri-bug/node_modules/@wdio/utils/build/initialisePlugin.js:32:20)
    at async initialiseServices (file:///F:/Projects/webdriver.io/uri-bug/node_modules/@wdio/utils/build/initialiseServices.js:53:25)
    at async initialiseLauncherService (file:///F:/Projects/webdriver.io/uri-bug/node_modules/@wdio/utils/build/initialiseServices.js:81:26)
    at async Launcher.run (file:///F:/Projects/webdriver.io/uri-bug/node_modules/@wdio/cli/build/launcher.js:81:65)
    at initialiseLauncherService (file:///F:/Projects/webdriver.io/uri-bug/node_modules/@wdio/utils/build/initialiseServices.js:118:15)
    at async Launcher.run (file:///F:/Projects/webdriver.io/uri-bug/node_modules/@wdio/cli/build/launcher.js:81:65)
Error: Failed to initilialise launcher service unknown: Error: Couldn't initialise "wdio-vscode-service".
TypeError: Cannot destructure property 'URI' of '(intermediate value).default' as it is undefined.
    at file:///F:/Projects/webdriver.io/uri-bug/node_modules/wdio-vscode-service/src/server/utils.ts:6:9
    at safeImport (file:///F:/Projects/webdriver.io/uri-bug/node_modules/@wdio/utils/build/utils.js:210:15)
    at async initialisePlugin (file:///F:/Projects/webdriver.io/uri-bug/node_modules/@wdio/utils/build/initialisePlugin.js:32:20)
    at async initialiseServices (file:///F:/Projects/webdriver.io/uri-bug/node_modules/@wdio/utils/build/initialiseServices.js:53:25)
    at async initialiseLauncherService (file:///F:/Projects/webdriver.io/uri-bug/node_modules/@wdio/utils/build/initialiseServices.js:81:26)
    at async Launcher.run (file:///F:/Projects/webdriver.io/uri-bug/node_modules/@wdio/cli/build/launcher.js:81:65)
    at initialiseLauncherService (file:///F:/Projects/webdriver.io/uri-bug/node_modules/@wdio/utils/build/initialiseServices.js:118:15)
    at async Launcher.run (file:///F:/Projects/webdriver.io/uri-bug/node_modules/@wdio/cli/build/launcher.js:81:65)

Workaround is to run npm install<EMAIL_ADDRESS>Fault location inside wdio-vscode-service with vscode-uri v3.0.8:
'src/server/utils.ts' line 6:
...
const { URI } = (await import('vscode-uri')).default
...

Thanks for reporting!

We greatly appreciate any contributions that help resolve the bug. While we understand that active contributors have their own priorities, we kindly request your assistance if you rely on this bug being fixed. We encourage you to take a look at our contribution guidelines or join our friendly Discord development server, where you can ask any questions you may have. Thank you for your support, and cheers!

@tzAcee I tried installing<EMAIL_ADDRESS>as a workaround but still getting the same error. Is there ahything am I missing?

@tzAcee I tried installing<EMAIL_ADDRESS>as a workaround but still getting the same error. Is there anything am I missing?

The workaround did work for me atleast. Can you check whether the version 3.0.7 of vscode-uri is really installed as a dependency by checking the version inside the package.json of the package inside your node_modules folder?

@tzAcee you are right seems the version in package.json file inside node_modules for vscode-uri is still 3.0.8. But I d o have installed<EMAIL_ADDRESS>still its not updated here. I did try making it 3.0.7 manually but not working. Any suggestions how can I make this work?

@tzAcee But there are two places where we find vscode-uri - one inside wdio-vscode-service package folder inside node_moduled and another one is vscode-uri package folder itself inside node_modules folder. And strange thing is at one we do getting 3.0.7 but at another place It's still showing 3.0.8

mhm no idea really.
Maybe try delete your node_modules folder completly and try npm install again.
The code-wise fix for the problem should be very quick & easy.
If I find time this weekend for getting wdio-vscode-service built on my system, I can provide a fix.

#89

@tzAcee I tried deleting node_modules and yarn.lock file and then ran yarn to install dependencies but still getting the same error :(

@tzAcee I tried deleting node_modules and yarn.lock file and then ran yarn to install dependencies but still getting the same error :(

Mhm then we'll have to wait till the PR get's merged :D!


get matt/laura to setup tickets

use pricing of 2017 as early-bird towards 31-Jan-2018
then increase


perf: improve DoMulti by reducing chansends

Codecov Report
Patch coverage: 100.00% and project coverage change: +0.01 :tada:

Comparison is base (47c3d7c) 97.67% compared to head (2911b22) 97.68%.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
Additional details and impacted files
@@            Coverage Diff             @@
##             main     #291      +/-   ##
==========================================
+ Coverage   97.67%   97.68%   +0.01%
==========================================
  Files          70       70
  Lines       29683    29688       +5
==========================================
+ Hits        28993    29001       +8
+ Misses        583      582       -1
+ Partials      107      105       -2

Impacted Files
Coverage Δ

pipe.go
99.70% <100.00%> (-0.30%)
:arrow_down:

ring.go
100.00% <100.00%> (ø)

... and 2 files with indirect coverage changes

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


[RBAC] Remove the "relationship tracking" or "role tracking" feature

We don't need this anymore. JWT data exchange details were unclear at the time.
Tests at test_app/tests/rbac/features/test_role_tracking.py

@fosterseth I want you to know that I've got some stuff like this lying around. I'm just not prioritizing it at the moment.

Blocked because we might use this temporarily to solve an API compatibility problem.