Richard wrote: > We have spent an enormous amount of time on this ... >
Hi, Some thoughts regarding the discussion of safety and design of security measures, i.e. a kind of "lessons learned" regarding the discussion aspects. I think one thing that made things slower and more inefficient was a lack of any self-contained description[*] of the overall design regarding safety and security. Ideally I think the discussion would've benefited from having one for: - LyX version 2.2, i.e. the release with the big problems - What was in master/HEAD, and at least was on its way to become LyX 2.3 - Intended eventual design, for LyX 2.3 or possibly a later release. The long threads likely by now do contain a lot of separate pieces of description, but it's unfortunately not so easy (at least for me) to find this information among all the posts. And sometimes I'd probably not understand to which "release" the information pertains. A partial "fix" might be to create a "best of"-list of posts with useful descriptive information. Or perhaps to copy them to into one place, adding minor markup as to what's still valid. Or actually try to write down some design design description. Question: Is there anyone who feels they know/understand the big picture regarding safety/security? Because I guess we in theory instead of writing things down could have a designated "guru". Actually, I'm a little worried that no one really has the big picture of the intended design regarding safety and security. Also, that different people have different ideas of where we are going and what's considered needed, while we at the same time are not aware of these differences. For something (a "feature") much less complicated than safety/security, I think it'd be fine for LyX if only a very small number of people know that part, and to where they intend to go. And that everything else is in the code. But for a complicated topic like safety, and when asking people to vote, I think the lack of a description is a problem. Hmm, and perhaps in case of votes, Scott should (be allowed to) weigh them differently depending on the persons knowledge. E.g., since I don't know/understand the (intended) safety design, why should my vote count as much as a potential safety "guru". On a more practical level: Hindsight is 20-20, but regarding e.g. Enrico's patch, perhaps we should have created a branch representing that alternative? This would have allowed that branch to always represent the latest improvement, thus avoiding people testing out an older patch accidentally. So we should keep the possibility of using branches in mind for future discussions. Perhaps there's other more practical things we could've done to make life easier. Best regards, /Christian [*] Regarding SW design descriptions and actually being able to understand and review an intended design in advance, I'm probably a bit "damaged" from when I worked with satellite software (AOCS), e.g. as SW verification and validation manager. In that field, lots of documentation was required which often was annoying, but for complicated stuff like FDIR (making the SW/satellite be able to cope with equipment failures), it really was essential to have the overall picture. The reason being that a tiny change in one area of the system could easily cause big problems in other areas, i.e. it's about unintended consequences. Here I see several similarities between FDIR and the safety/security for LyX, e.g. that adding a neat feature like previews of Gnuplot figures could've led to a big security hole. Another similarity is that you can't do FDIR only at a low level, you need a system perspective. I think it's the same with safety/security for LyX: If we only consider each feature separately, we're going to screw up. Two features in isolation might be safe, but when available together it might "leak". Another similarity is needing to define our objectives, and what we consider "good enough" safety. If we don't understand what we're trying to achieve, it's e.g. not possible to review a design to see if it achieves the objectives.
