Separate T* and X*

[the-right-joyce]

X* labels will now be release-related, so that multiple T* labels can be used
addresses #24

@chevdor
please change on the release script the T0, T1, T2 and T6 to X0, X1, X2 and X3

[bkchr]

Can you please explain how this should work? Can we please stop with the label explosion? What is the reason for the T labels? What do they express?

In general, the release management should get away of using labels. This was always wrong. We can use labels to have some coarse list, but then we need manual work to create proper release nodes out of them.

[the-right-joyce]

Can we please stop with the label explosion? What is the reason for the T labels? What do they express?

they are for the Topics. It's not explosion, it's just separating the topics that are used for the releases as well.

In general, the release management should get away of using labels. This was always wrong. We can use labels to have some coarse list, but then we need manual work to create proper release nodes out of them.

Right now labels are used, so we have to make it work - we're going to a monorepo and can find another way there.

[bkchr]

Right now labels are used, so we have to make it work - we're going to a monorepo and can find another way there.

The X labels you have added can be derived from the T labels. I don't see the reason to add them.

[bkchr]

T9-release should be removed, not sure why we need to signal this in our labels 🤷

And parachains and system_parachains are essentially the same and there is no real need to differentiate between them.

[ggwpez]

So this makes the X and the T labels orthogonal? thanks.
My problem was that the Polkadot CI rejects something like T1-runtime, T5-parachains, T6-XCM.
I think there are parachain teams who filter the merged MRs by label to find relevant ones. Not exclusively for the release engies.
Now with this MR i could do: T2-parachains_protocol, X1-runtime, X3-XCM which covers all the topics, but still has only one release section (T2).

Or who else would you solve that @bkchr ? I think these labels are a good API to notify external dev teams of changes that could concern them.

[chevdor]

My problem was that the Polkadot CI rejects something like T1-runtime, T5-parachains, T6-XCM.

The CI rejects multiple T labels indeed. It does it despite the fact that it should be allowed for the Topics labels, I agree.

CI (ruled_labels) rejects those because we have some legacy tooling that does not support multiple labels with the same letter and collapses them. As a result, your example T1-runtime, T5-parachains, T6-XCM becomes one of T1, T5, T6 and wipe the rest 🥲

It is trivial to change the rules to allow multiple T (or any letter actually) label with the YAML config you already played with @ggwpez, this is unfortunately not where the issue is.

[bkchr]

Or who else would you solve that @bkchr ? I think these labels are a good API to notify external dev teams of changes that could concern them.

I did not speak against labels. I also know that downstream is using them, which is kind of sad but our failure of not providing anything better. My argument was just that T and X are the same.