What should go into an eventual 1.2.3 release?

[aesedepece]

There's this intention of releasing 1.2.3 asap. This is to discuss what should we ship with it, and what can be left out.

[aesedepece]

The https://github.com/witnet/witnet-rust/tree/202106-recovery branch introduced 11 commits that are not on upstream/master.

We may need to backport some of those changes to the master branch and make sure that goes into an eventual 1.2.3 release.

Shall we make a list of what is worth backporting?

[aesedepece]

At first thought, commit c97bd5f should be left out, as these pieces of code are no longer needed:

witnet-rust/data_structures/src/mainnet_validations.rs

Lines 14 to 22 in d8cf218

	/// Committee for superblock indices 750-1344
	const SECOND_EMERGENCY_COMMITTEE: [&str; 6] = [
	"wit1drcpu0xc2akfcqn8r69vw70pj8fzjhjypdcfsq",
	"wit1drcpu3x42y5vp7w3pe203xrwpnth2pnt6c0dm9",
	"wit1asdpcspwysf0hg5kgwvgsp2h6g65y5kg9gj5dz",
	"wit1cyrlc64hyu0rux7hclmg9rxwxpa0v9pevyaj2c",
	"wit1etherz02v4fvqty6jhdawefd0pl33qtevy7s4z",
	"wit13l337znc5yuualnxfg9s2hu9txylntq5pyazty",
	];

witnet-rust/data_structures/src/mainnet_validations.rs

Lines 44 to 53 in d8cf218

	} else if Environment::Mainnet == environment
	&& superblock_index > 44165
	&& superblock_index < 45509
	{
	Some(
	SECOND_EMERGENCY_COMMITTEE
	.iter()
	.map(|address| address.parse().expect("Malformed signing committee"))
	.collect(),
	)

Which makes me think that the code for the first emergency committee can be removed just as well, right?

[drcpu-github]

I am wondering if we want to remove this. Does it not make sense to keep it included for posterity, so in the future people can easily verify things like emergency committees and how they worked? I cannot immediately think of a use case for that, but I'm also not sure if removing them serves a good purpose.

[aesedepece]

That was also the reason for keeping the logic of the first emergency committee in place.

My point with removing any piece of dead code (those parts that are no longer used for validations, mining nor synchronization) is to maintain our code base as lean and maintainable as possible.

In the same fashion, my take is that once some protocol upgrade has been enacted via TAPI, the following witnet-rust release should remove the conditional activation from that part of the code, because the logic contained therein will have become part of the core protocol as per WIP-0014§17.

[drcpu-github]

My point with removing any piece of dead code (those parts that are no longer used for validations, mining nor synchronization) is to maintain our code base as lean and maintainable as possible.

I'd say the fact that it is put in a separate function makes it pretty lean / maintainable. I have no strong opinion on keeping or removing it, because I cannot

In the same fashion, my take is that once some protocol upgrade has been enacted via TAPI, the following witnet-rust release should remove the conditional activation from that part of the code, because the logic contained therein will have become part of the core protocol as per WIP-0014§17.

I feel like this is a slightly different case because those are protocol improvements versus interventions in the consensus mechanism, but in the end the repository and associated tags show a good enough overview of the different changes the node software went through.

[aesedepece]

I'd say the fact that it is put in a separate function makes it pretty lean / maintainable. I have no strong opinion on keeping or removing it, because I cannot

I dislike the idea of having if / else if / else blocks covering conditions that we know that can never be met, because each of those conditions add cognitive complexity to the business logic and also require a specific test.

[drcpu-github]

I guess all commits, except 845e336 (shorter icing period) and 6ed2de9 (microforking) make sense to include in the master branch.