-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Allow multiple categories? #433
Comments
I recall us discussing the case of multiple categories in the rework of CIP-0001 and, the point was that having only a single category makes it easier for classification. Plus, there's almost always a main category, even though the work may indeed impact other areas of the ecosystem. I am afraid that by allowing multiple categories, we'll soon end up with CIP referencing half a dozen of categories to which they barely relate. I find it easier to only consider one main category; even if some CIPs may actually fit multiple on occasions. |
Okay, that's reasonable. I think it may cause it's own confusion, but fine. |
Actually, I'm still unsure. Consider the case of the Ledger and Plutus categories. Suppose that both of these require some process, e.g. that the submitter propose changes to the corresponding specifications. A CIP in the overlap of the two should have to follow both of the processes, i.e. we do need changes to both specifications. I can say something like "a CIP which would also fall under the Ledger category should be categorized under Plutus but must also follow the process of the Ledger category", but that seems clunky? 🤔 |
I couldn't find any proposals (merged, closed, or open) that use the Ledger category. The cips website doesn't even have the option for Ledger sorting. Plus, looking at CIP-0035, it seems to me that all plutus changes, except for real performance changes, require a hardfork. AFAIK this means the ledger team must be involved for all plutus changes except for real performance changes. Even CIPs 31,32, and 33 use the Plutus category despite making changes to the ledger. Perhaps the Plutus and Ledger category should just be merged into a new Plutus/Ledger category and the software update changes should go into a new Node category. If possible, the processes for the original Plutus and Ledger categories should just be merged into one process. I can't think of any way that plutus or the ledger can be changed without impacting the other. For example, if the way things are stored on-chain changes (a ledger change), wouldn't the ledger-script interface also need to change (a plutus change)? Conversely, as noted above, most plutus changes require a hardfork which AFAICT means a change to the ledger. If it is easy for someone else to come up with ledger changes that do not impact plutus, then I take back this suggestion. |
I think there will be a Ledger category soon :) Requiring a HF does not mean that we need involvement from the ledger team, it just means we can't do it until the next HF. Most of the ledger changes don't affect Plutus and vice versa. |
I'm updating CIP-35 to be more in line with the new CIP-1. I notice that lots of Plutus changes are also Ledger changes, e.g. changes to the ledger-script interface, protocol parameter changes. The obvious thing for me to say is that in these situations a CIP should be in both categories and get reviewed by both sets of reviewers. But right now CIPs can only have one category.
The text was updated successfully, but these errors were encountered: