Hello all,
It looks like the copyright guidance on this project changed about a year
ago (Nov 13, 2018) to a placeholder and hasn't been corrected yet. Can
this be fixed to make the license valid so the project can be legally
redistributed per BSD-3 as intended?
Thanks,
Tristan Muntsinger
Hi Yann,
You are quite correct. We will be looking to create a v2.2 tag release sometime early to mid October. You can expect a more formal notification and a request to get any patches submitted in the next week or so. As in previous releases master will be generally locked for a week or so while closedown testing is performed although we will assess incoming patches to see if they can be taken with low risk.
Joanna
On 16/09/2019, 13:19, "TF-A on behalf of Yann GAUTIER via TF-A" <tf-a-bounces(a)lists.trustedfirmware.org on behalf of tf-a(a)lists.trustedfirmware.org> wrote:
Hi,
From the wiki page https://developer.trustedfirmware.org/w/tf_a/tf-a_release_information/, the next v2.2 tag may be released soon.
But the exact timeframe is not yet published.
The wiki page might be updated if you have more information.
When do you expect to release tag v2.2?
What will be the deadline to send patches upstream?
Thanks,
Yann
--
TF-A mailing list
TF-A(a)lists.trustedfirmware.org
https://lists.trustedfirmware.org/mailman/listinfo/tf-a
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.
Hi,
>From the wiki page https://developer.trustedfirmware.org/w/tf_a/tf-a_release_information/, the next v2.2 tag may be released soon.
But the exact timeframe is not yet published.
The wiki page might be updated if you have more information.
When do you expect to release tag v2.2?
What will be the deadline to send patches upstream?
Thanks,
Yann
Hi Soby,
> 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.
No problem, thanks to Sandrine for taking care of it so quickly.
Unfortunately we now discovered that we're still stuck on the same
issue with MT8173. Could one of you please help getting
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/990/31
landed to fix that too?
Thanks,
Julius
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.
Hi Julius,
On 8/27/19 9:55 PM, Julius Werner via TF-A wrote:
> Could either of you please help get the Tegra fix in
> https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1192
> landed (and subsequently CI for Tegra re-enabled)? It has been
> reviewed and approved for two weeks but nobody is merging it. This is
> blocking more and more work across all coreboot-based platforms so I
> would appreciate if we could get it resolved quickly.
Apologies for the delay. As you may have seen, the patch has now been
merged, and we've also re-enabled the Tegra builds in the CI.
Regards,
Sandrine
Hi Soby, Joanna,
Could either of you please help get the Tegra fix in
https://review.trustedfirmware.org/c/TF-A/trusted-firmware-a/+/1192
landed (and subsequently CI for Tegra re-enabled)? It has been
reviewed and approved for two weeks but nobody is merging it. This is
blocking more and more work across all coreboot-based platforms so I
would appreciate if we could get it resolved quickly.
Thanks,
Julius