Add a new template to show the list of host functions

[chevdor]

Before

After

[ggwpez]

Thanks for fixing!

@koute your MR actually modified a host function, not added a new one, or?
So we should probably change the description of the label and section eventually.

[chevdor]

@ggwpez @koute expained actually quite nicely in his PR.

This situation occurs quite often: a new host function is added but not in use yet.
So setting the label is legit but reporting it as we could be seen as a false "alarm" since it is not in use.

Still it is better to raise awareness that a new host function showed up. If users upgrade now, it will be all good if they don't later when it is really needed.

We could add a special mention as free note but is it worth it ?

[ggwpez]

I think it is fine, my concern was about the formulation: "one new host function".
But there was no new one - it was just modifying an existing one (actually two) by bumping a dependency.

[bkchr]

But there was no new one - it was just modifying an existing one (actually two) by bumping a dependency.

Exactly this is correct!

It is then required by a human to "fix" this afterwards in the release notes.

[chevdor]

I am editing this for the upcoming release and indeed I should change the wording in the template.

The number we inject in the template is not the number of host functions as you pointed out @ggwpez but the number of PRs related to host functions.

The E3 label has been mostly used to introduce new host functions (active or not) but the labels do not carry the information about the number of host fn affected.
Now with the list of related PRs, we can see a bit more details about those changes.

I will rephrase that part.

[koute]

@koute your MR actually modified a host function, not added a new one, or? So we should probably change the description of the label and section eventually.

Yes. Would be nice to have a dedicated label for this. Maybe something like this:

• one label for when we introduce a new host function (host function is not used yet, so no need for everyone to upgrade; low priority)
• one label for when we enable a previously unused host function (everyone has to upgrade; high priority)
• one label for when we modify a previously unused but already existing in in-the-wild host function (so that if we enable it we know what is the oldest version of node that's still compatible)

cc @the-right-joyce

[chevdor]

I am totally fine with that @koute. This kind of granularity allows being super accurate when listing/grouping those PRs.
This will however only work if those extra labels are used properly by everyone and picking the right set of labels has an overhead.
We have already lots of labels and I know the amount if already daunting. That being said, the number of people working around host functions is limited so it may work.

For now, I will fix the templates with the labels we currently have. @koute I opened a separate issue to keep track of your suggestion.

[chevdor]

Here is a preview of the new change in the case of 1 PR related to host functions:

[chevdor]

bot rebase

[paritytech-processbot]

Rebased

[chevdor]

bot merge

[paritytech-processbot]

Waiting for commit status.