Skip to content
This repository has been archived by the owner on Nov 15, 2023. It is now read-only.

WIP: Split global prio into prios for runtime and node #7159

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

chevdor
Copy link
Contributor

@chevdor chevdor commented May 2, 2023

Abstract

Currently we have a single priority computed over both runtime and node priorities.
This PR splits into 2 prios:

  • runtime
  • node

Open

  • should T2 be included into runtime/node/or both ?

Preview

image

@chevdor
Copy link
Contributor Author

chevdor commented May 2, 2023

Today we consider only 3 labels:

  • T0-node: This PR/Issue is related to the topic “node”
  • T1-runtime: This PR/Issue is related to the topic “runtime”
  • T2-API: This PR/Issue is related to APIs

In the current state, this PR considers only T0 and T1 and ignores T2.

We have 4 options for now (things will ease later when we fix those issues preventing multiple labels with the same letter):

  • consider T2 along with T0
  • consider T2 along with T1
  • consider T2 along with both T0 and T1
  • ignore T2

The answer depends mostly on how T2 is used at the moment.
@the-right-joyce @bkchr what are your takes on that ?

The idea here is to stop telling node users to upgrade urgently when the high prio fix is actuallly in the runtime.
At the same time, being able to tell the right users that the runtime contains a high prio fix, will also be useful.

@chevdor
Copy link
Contributor Author

chevdor commented May 2, 2023

After further checking, I see what we miss the data for the template to properly output what we want.
We only get meta about the overall highest priority. We currently don't have the highest priority for the node or runtime only. Splitting requires more aggregration in the underlaying tooling (changelogerator) that is planned for a re-write.

@paritytech-cicd-pr
Copy link

The CI pipeline was cancelled due to failure one of the required jobs.
Job name: test-linux-stable
Logs: https://gitlab.parity.io/parity/mirrors/polkadot/-/jobs/2762755

@bkchr
Copy link
Member

bkchr commented May 2, 2023

The answer depends mostly on how T2 is used at the moment.
@the-right-joyce @bkchr what are your takes on that ?

Maybe the best would be to remove T2. If not someone can explain for what it is good. So, for your use case I would ignore it.

@chevdor
Copy link
Contributor Author

chevdor commented Jul 25, 2023

@chevdor chevdor added B0-silent Changes should not be mentioned in any release notes A2-insubstantial Pull request requires no code review (e.g., a sub-repository hash update). labels Jul 25, 2023
@the-right-joyce
Copy link
Contributor

T2 is no longer existing, we won't have the same set of labels any longer and also not the same rules, see https://github.com/paritytech/labels/pull/29/files
As off now we had the feedback that the devs would like to add multiple T*labels to their PRs/issues as it helps them to classify what the issue/PR is about, so they will also not be exclusive anymore
Priority labels are also gone, we need to think of a completely new template for the releases, not based on the sets that we currently have.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
A2-insubstantial Pull request requires no code review (e.g., a sub-repository hash update). B0-silent Changes should not be mentioned in any release notes
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants