Drop of `commontorizon/?` images usage

[microhobby]

The Common Torizon organization will be archived, and we should not use the containers from the commontorizon/? org anymore. This will be an issue for Torizon OS 7 update.

Of the templates that "depend" on these images yet, the most important one is from the Slint partnership. So, @tronical we will have some options, and I would like your help to make the final decision and maintenance action.

1. Move all the base instructions to the template Dockerfiles:
   • Cons: The build time will be increased impacting the developer experience;
   • Pros: Less maintenance effort;
2. Slint will publish a slint/slint-sdk or/and slint/slint-runtime images:
   • Cons: Plus maintenance effort;
   • Pros: Build time will be decreased, making the developer experience better;

[tronical]

My preference is (1). We can try to bring down compile times, but the optimization only works for C++ anyway and not Rust.

Another idea would be for Slint to provide C++ binary arm packages. We have some for Linux x86-64 already.

[escherstair]

@microhobby

The Common Torizon organization will be archived

What do you mean with this sentence? What are the impacts?

Thanks

[leograba]

@escherstair let me address this relevant question

Historically, CommonTorizon (including the https://github.com/commontorizon organization on GitHub) was born as an experiment to address two points:

• Support of 3rd-party hardware in Torizon
• Foster a community around Torizon

At a later point in time, Toradex has created the https://github.com/torizon organization to keep some projects that were previously (some before CommonTorizon, some after) outside the more generic https://github.com/toradex organization

That led to mismatch expectations and harder for customers to understand the relationship and stakes of Toradex and the SW development community.

Due to this, we are planning to sunset the CommonTorizon organization, so all Torizon projects (even 3rd-party HW support and foster of an open-source SW community around Torizon) are all kept united under a single GitHub organization, https://github.com/torizon

We understand this will make it easier for you, as a collaborator, and @tronical as a partner, to collaborate with us in the long term.

In the short term, there will be decisions to make, things to move, questions to answer, and this might be a bit disruptive. For that I ask a bit of patience, and as you have more questions keep them coming so I also have a clear understanding of the community expectations.

[microhobby]

@escherstair from the Common Torizon github page:

Acknowledgements

Torizon™ is a registered trademark of Toradex Group AG. This derivative work have not been reviewed or approved by Toradex. Common Torizon community does not talk on behalf of Toradex.

It was a mistake to have the commontorizon/? images used here on Toradex supported templates at the first place. And I take responsibility for this error. We are fixing it now.

If you would like to continue your contributions please follow up on https://github.com/torizon

Thanks!

[escherstair]

@leograba I thought a little bit about your answer. One thing is not clear to me and it's related to the commontorizon/? images. From your explanation I understand that https://github.com/torizon organization will take the role of commontorizon (more or less with the same targets: 3rd party hardware + community). So, since commontorizon published some useful docker images (as an example slint-xxxx), why torizon can't publish the same images, if a mantainer is found? I think it's the easiest solution. For sure if nobody wants to mantain them they will not be moved from commontorizon to torizon.

Is this because Toradex (big thanks to Toradex for the Torizon OS) has the final word on what can or can't be handled inside torizon organization? If this is the case, I imagine that soon or later someone will fork this repo to create a new "open" organization.. But this is what we have now with commontorizon... nonsense. This is not clear to me.

[leograba]

@escherstair that's a good point.

So, since commontorizon published some useful docker images (as an example slint-xxxx), why torizon can't publish the same images, if a mantainer is found? I think it's the easiest solution.

This is a valid approach. I would be ok having the partner labeled images in the repo, conceptually. @tronical, please consider this an option.

In practice, the https://github.com/torizon/torizon-containers/ repo is not yet structured in a way to receive external contributions and if anyone sends a PR there probably the first time we'll have to solve it - which may delay things a bit until we're ready. I'm just saying it to acknowledge you won't find concrete instructions or evidence that it's a community repo yet, because we are in the middle of this transition; but you can consider that repo as the place (at least for now) that will cherry-pick whatever makes sense from https://github.com/commontorizon/Containerfiles in the long-term.

Is this because Toradex (big thanks to Toradex for the Torizon OS) has the final word on what can or can't be handled inside torizon organization? If this is the case, I imagine that soon or later someone will fork this repo to create a new "open" organization.. But this is what we have now with commontorizon... nonsense. This is not clear to me.

I don't think this is binary.

On one hand, Toradex has big stakes in fostering a community and is a major stakeholder in guiding the community and negotiating what is acceptable, what isn't, and especially transparently stating the reasons why - even if non-technical sometimes. Therefore, I feel it is our duty as maintainers to deny things that we don't agree with. But I also expect this will be the exception, not the rule.

On the other hand, if Toradex starts blocking each and every contribution that will be bad (I don't expect this to happen), it is very likely that frustrated members of the community will start forking stuff as a response to a policy they don't agree with. This is a beautiful point of FOSS I think, because it empowers people to diverge if they can't agree and work together. But also I want to avoid it as much as I can and so far I don't remember any community contribution that was radically, unilaterally blocked.

[escherstair]

On one hand, Toradex has big stakes in fostering a community and is a major stakeholder in guiding the community and negotiating what is acceptable, what isn't, and especially transparently stating the reasons why - even if non-technical sometimes. Therefore, I feel it is our duty as maintainers to deny things that we don't agree with. But I also expect this will be the exception, not the rule.

On the other hand, if Toradex starts blocking each and every contribution that will be bad (I don't expect this to happen), it is very likely that frustrated members of the community will start forking stuff as a response to a policy they don't agree with. This is a beautiful point of FOSS I think, because it empowers people to diverge if they can't agree and work together. But also I want to avoid it as much as I can and so far I don't remember any community contribution that was radically, unilaterally blocked.

I agree to this. It makes sense. From the user/contributor perspective, the easiest approach would be "cherry-picking" from commontorizon as much as possible (and as much has sense), if a mantainer is available. For sure Toradex cannot be responsible to mantain "community" items that nobody whants to mantain.

[tronical]

I've got some time to work on the Slint template and could drop the common torizon bits. I'm wondering: Should I based this work on torizon 6 and the current dev branch, or is this better done with Torizon 7? (How could that be done?)