livepeer / LIPs

Livepeer Improvement Proposals
9 stars 13 forks source link

Ability to update registered solver in LivepeerVerifier #3

Closed yondonfu closed 6 years ago

yondonfu commented 6 years ago

This LIP proposes an upgrade to the LivepeerVerifier contract that allows for both the addition and removal of solver addresses. The proposal also describes some related state management updates that can simplify the logic of the contract.

yondonfu commented 6 years ago

Re: discussion in an issue prior to creation of PR - I was thinking that discussion in public forums such as Github issues or forum posts would serve as a good way to help develop a specification for a particular proposal when it is at an earlier idea stage. After receiving feedback and exchanging ideas in public forums, the specification for the proposal can be written and the comment thread of the PR would be more focused on the existing content of the written specification as opposed to exploring the general idea space. In this particular case, I already had a specification so I thought it might make sense to skip the public forum discussion and to have the discussion directly in the comment thread of this PR. Let me know what you think!

dob commented 6 years ago

Sounds good. One of the meta-challenges I see is that even though you've addressed the issues I raised, and I would now approve the PR, I'm not sure how to determine if there's been enough chance for others to also look and weigh in on the ideas before it becomes accepted. So yes, a forum or issues post about the ideas seem sound in the future to allow that discussion to play out before a PR. But yes, I agree in this case this is more straightforward and was basically ready for spec.

yondonfu commented 6 years ago

I think its reasonable to leave this PR open for a few days before merging this as a draft and assigning a number. I'd note that in the current process merging this proposal does not mean that it is is designated "Accepted" status, it just means that it will be a candidate for discussion in a core dev call and if it receives support there it will be designated "Accepted" status. And of course it is up for debate whether this is the right flow for the project at this particular stage, but this is the current outlined approach