Initial commit of documents for licensing and encryption standardizat… #2917
Conversation
…ion proposal This is material from the original proposal somewhat adapted to the new MCP process. it describes how the open source prototype available on https://github.com/modelon-community/SEMLA works. It describes well how it works, but will need some work to be ready as specification text. I can help port this to a different format if needed.
There was a problem hiding this comment.
Very nice initiative! I can try to guide you through the process.
Two things:
- To follow procedures, you should start with a PR for just the allocation of an MCP number, so that we get a traceable language group decision on taking on this MCP. (I have no doubts that it will be accepted, probably at the upcoming phone meeting.) This PR should have a title like Allocate MCP number for Licensing and Encryption, and only add a row here: https://github.com/modelica/ModelicaSpecification/blob/master/RationaleMCP/ReadMe.md
- Considering that the MCP documents will end up in the master branch in the end, I think it would be better to convert to markdown before making an initial commit. It will also make the content far more accessible from start. Also, the MCP directory should have a ReadMe.md with the usual summary. It's great that you volunteered to port the documents, but then we should probably restart the branch without the old Word files.
From the limited experience we have with the new MCP procedure, it is typically best to delay preparation of actual specification changes until late in the process, to avoid unnecessary merge conflicts. Also, having the design presented as separate markdown documents is a much more convenient form for discussing the proposal before getting to the LaTeX sources. |
|
To avoid unnecessary delays, I created the PR for MCP number allocation: #2919 |
It's also very important in order to first focus on understanding the problem, and how it can be solved in principle. We've had some bad experience with several proposals that started by describing the spec-changes without actually describing why they were needed. It doesn't seem like the case here, though. |
|
Additionally the MCP should stored on a branch with a specific name while working on it, not directly merged to master. I can easily fix that, but the important part would be to convert the text to markdown. |
I think having a PR in Draft state for merging the (main) MCP branch into master is OK as soon as an MCP number has been allocated and the main MCP branch has been set up. That PR will then be the main issue representing the MCP, and we want that to exist from the beginning, so that there is a clear place for having the overarching discussions about the MCP. (Smaller discussions about subtopics can be organized by having separate PRs on those subtopics, where the target branch is the MCP branch, and the branch of the subtopic is named so that it is clear what MCP it belongs to.) |
I wasn't discussing the PR state, but the name of the branch for the MCP during that time. |
Sure, the PR branch should have the proper name. I just got confused by "merged to master", since that has to do with the name of the target branch. Since the MCP branch shall be developed in the central repository, calling that one master is not even possible. |
|
With #2931 containing the updated things I believe this can be closed without being merged, right? |
That's also my understanding. |
…ion proposal
This is material from the original proposal somewhat adapted to the new MCP process. it describes how the open source prototype available on https://github.com/modelon-community/SEMLA works. It describes well how it works, but will need some work to be ready as specification text. I can help port this to a different format if needed.