Hello Soby/Joanna,
We would like to upstream support for a new Tegra platform along with some other changes. The last time I checked, there were more than 400 changes waiting to be upstreamed.
Can someone help me with the best/fastest approach to start upstreaming? Previously, we would upstream changes in big chunks (as branches) but I don't know if that approach still works.
Thanks.
-----------------------------------------------------------------------------------
This email message is for the sole use of the intended recipient(s) and may contain
confidential information. Any unauthorized review, use, disclosure or distribution
is prohibited. If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
-----------------------------------------------------------------------------------
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.
