Hi Soby,
Hmm, if we merge a non-trivial patch and ensure the build works, then we do not know whether it runs correctly, whether there are any runtime effects that would affect stability/robustness of the platform that even might have security implications. Hence, in my view, it is better to have a broken build for the platform, rather than have runtime problems.
The project could form a policy that if a platform remains broken for more than 2 releases (1 year by current release intervals), then it will get removed from the tree after giving enough notifications.
Thanks, yes, I think it would be good to have a clear policy on this, whatever it is.
I would still like to make a case for keeping these platforms in the tree on a best-effort basis. You're right that there's a chance for untested patches to cause all sorts of runtime errors, but I think that may still be better than a platform that doesn't build at all. A platform that doesn't build doesn't benefit anyone. A platform that may have errors still has a chance of working, and even if it doesn't it gives a third-party contributor or hobby developer who wants to start using it a chance to fix it up again. This is something we occasionally see happening with some of our older, less maintained platforms in coreboot. But if it doesn't even build, the chance of someone coming along to fix it seem very slim, because then more and more build issues will keep piling up over time. (In fact, I doubt there's even any point in keeping broken stuff in the tree for another year as you proposed... likely all that would do is confuse people who are trying to refactor project-wide APIs. Code that's never build-tested just bit rots very quickly. I think at that point you might as well remove it from the repo immediately.)
It's true that there may also be security issues (which is more serious), but I'm skeptical that this really makes a lot of difference. After all, this may happen even while the platform is still actively maintained. Just testing whether it boots doesn't make sure you have no security issues anyway. Maybe a way to make this more visible instead could be to introduce a new ALLOW_UNMAINTAINED_PLATFORM=1 make variable that the user has to explicitly set to build a platform without active maintainer? That could serve as a warning that the code may not be safe to use for critical applications anymore while still giving developers access to something if they're willing to deal with possible issues.
Anyway, whatever the policy may be, a more defined process would help. I think the initial messaging around the console deprecation plan was fine, but it would have been good to have another explicit announcement when the CI actually gets turned off for a platform.
On 05/08/2019 22:40, Julius Werner wrote:
Hi Soby,
Hmm, if we merge a non-trivial patch and ensure the build works, then we do not know whether it runs correctly, whether there are any runtime effects that would affect stability/robustness of the platform that even might have security implications. Hence, in my view, it is better to have a broken build for the platform, rather than have runtime problems.
The project could form a policy that if a platform remains broken for more than 2 releases (1 year by current release intervals), then it will get removed from the tree after giving enough notifications.
Thanks, yes, I think it would be good to have a clear policy on this, whatever it is.
I would still like to make a case for keeping these platforms in the tree on a best-effort basis. You're right that there's a chance for untested patches to cause all sorts of runtime errors, but I think that may still be better than a platform that doesn't build at all. A platform that doesn't build doesn't benefit anyone. A platform that may have errors still has a chance of working, and even if it doesn't it gives a third-party contributor or hobby developer who wants to start using it a chance to fix it up again. This is something we occasionally see happening with some of our older, less maintained platforms in coreboot. But if it doesn't even build, the chance of someone coming along to fix it seem very slim, because then more and more build issues will keep piling up over time. (In fact, I doubt there's even any point in keeping broken stuff in the tree for another year as you proposed... likely all that would do is confuse people who are trying to refactor project-wide APIs. Code that's never build-tested just bit rots very quickly. I think at that point you might as well remove it from the repo immediately.)
It's true that there may also be security issues (which is more serious), but I'm skeptical that this really makes a lot of difference. After all, this may happen even while the platform is still actively maintained. Just testing whether it boots doesn't make sure you have no security issues anyway. Maybe a way to make this more visible instead could be to introduce a new ALLOW_UNMAINTAINED_PLATFORM=1 make variable that the user has to explicitly set to build a platform without active maintainer? That could serve as a warning that the code may not be safe to use for critical applications anymore while still giving developers access to something if they're willing to deal with possible issues.
Anyway, whatever the policy may be, a more defined process would help. I think the initial messaging around the console deprecation plan was fine, but it would have been good to have another explicit announcement when the CI actually gets turned off for a platform.
Hi Julius, Apologize for the radio silence as I was on sabbatical. Yes, I agree the project needs to have a clear policy around platforms. We will get this started on our end and send a policy proposal for review.
Best Regards Soby Mathew IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
tf-a@lists.trustedfirmware.org
-
Julius Werner -
Soby Mathew