| Message ID | 20210112103338.14712-1-silvano.cirujano-cuesta@siemens.com |
|---|---|
| Headers | show |
| Series | support generation of sdk container images | expand |
I wonder how to interpret the current feelings about this proposal: * There's no interest at all. * I haven't succeed on raising enough interest. In that case I'd need more input from people who see the demand for this functionality to better understand what's missing in my proposal. * There's interest, but I should update the patch according the comments up-to-now before I send a 1st patch series proposal (or a 2nd RFC). I'd appreciate any feedback. The more decision power the person giving the feedback, the more valuable it is for me :-) Thanks! Silvano On 12/01/2021 11:33, [ext] Silvano Cirujano Cuesta wrote: > This patch series adds to the SDK generation (task `populate_sdk`) the > possibility of generating container images containing the SDK in > different formats (multiple formats can be generated at once). > > Up-to-now the task `populate_sdk` generates the sdk root filesystem (in > both as a file tree and in a tarball) that can be chrooted to. The same > root filesystem can be easily distributed as a container image and > started as a container. > > It's even possible extracting the root filesystem from a container > image, using the container image format only as a sort of packaging > system for easy distribution. > > More information about its usage is documented in the file > docs/user_manual.md. > > Typical container image management actions (e.g. push an image to a > container image regitry) are out of scope. Available tools (Docker, > Skopeo, Buildah, Podman,...) should be used for these actions. > > Silvano Cirujano Cuesta (2): > sdk: support creation of container image > docs: document usage of sdk container images > > doc/user_manual.md | 70 +++++++++++++++++ > meta/classes/image-sdk-extension.bbclass | 99 ++++++++++++++++++++++-- > 2 files changed, 162 insertions(+), 7 deletions(-) >
Please do not make my voice count too much, the moment i see "docker" i go "strong reject". A reflex i can not help ... maybe its valuable and i am too much blinded by stereotypes. Henning Am Thu, 14 Jan 2021 14:56:59 +0100 schrieb "[ext] Silvano Cirujano Cuesta" <silvano.cirujano-cuesta@siemens.com>: > I wonder how to interpret the current feelings about this proposal: > > * There's no interest at all. > > * I haven't succeed on raising enough interest. In that case I'd > need more input from people who see the demand for this functionality > to better understand what's missing in my proposal. > > * There's interest, but I should update the patch according the > comments up-to-now before I send a 1st patch series proposal (or a > 2nd RFC). > > I'd appreciate any feedback. The more decision power the person > giving the feedback, the more valuable it is for me :-) > > Thanks! > > Silvano > > > On 12/01/2021 11:33, [ext] Silvano Cirujano Cuesta wrote: > > This patch series adds to the SDK generation (task `populate_sdk`) > > the possibility of generating container images containing the SDK in > > different formats (multiple formats can be generated at once). > > > > Up-to-now the task `populate_sdk` generates the sdk root filesystem > > (in both as a file tree and in a tarball) that can be chrooted to. > > The same root filesystem can be easily distributed as a container > > image and started as a container. > > > > It's even possible extracting the root filesystem from a container > > image, using the container image format only as a sort of packaging > > system for easy distribution. > > > > More information about its usage is documented in the file > > docs/user_manual.md. > > > > Typical container image management actions (e.g. push an image to a > > container image regitry) are out of scope. Available tools (Docker, > > Skopeo, Buildah, Podman,...) should be used for these actions. > > > > Silvano Cirujano Cuesta (2): > > sdk: support creation of container image > > docs: document usage of sdk container images > > > > doc/user_manual.md | 70 +++++++++++++++++ > > meta/classes/image-sdk-extension.bbclass | 99 > > ++++++++++++++++++++++-- 2 files changed, 162 insertions(+), 7 > > deletions(-) >
On 14.01.21 14:56, [ext] Silvano Cirujano Cuesta wrote: > I wonder how to interpret the current feelings about this proposal: > > * There's no interest at all. > > * I haven't succeed on raising enough interest. In that case I'd need more input from people who see the demand for this functionality to better understand what's missing in my proposal. > > * There's interest, but I should update the patch according the comments up-to-now before I send a 1st patch series proposal (or a 2nd RFC). > > I'd appreciate any feedback. The more decision power the person giving the feedback, the more valuable it is for me :-) > The level of feedback you received is already quite good for a first round :), and there is usually no early feedback from maintainers. I would say update the series, addressing that smaller issue(s) and remove the RFC. I'll also give that a try soon. Thanks a lot, Jan
On 14/01/2021 19:32, Henning Schild wrote: > Please do not make my voice count too much, the moment i see "docker" i > go "strong reject". A reflex i can not help ... maybe its valuable and > i am too much blinded by stereotypes. I don't make your voice count too much, only as much as it's worth, being you one of the main contributors. I'm aware of your concerns about anything related to containers. But your concern is valid, since questioning the need for integrating completely new technologies and tools is always meaningful. If you're biased in one direction, I'm biased in the other one. My previous e-mail was sort of a call for the opinion of someone less biased. Cheers, Silvano > > Henning > > Am Thu, 14 Jan 2021 14:56:59 +0100 > schrieb "[ext] Silvano Cirujano Cuesta" > <silvano.cirujano-cuesta@siemens.com>: > >> I wonder how to interpret the current feelings about this proposal: >> >> * There's no interest at all. >> >> * I haven't succeed on raising enough interest. In that case I'd >> need more input from people who see the demand for this functionality >> to better understand what's missing in my proposal. >> >> * There's interest, but I should update the patch according the >> comments up-to-now before I send a 1st patch series proposal (or a >> 2nd RFC). >> >> I'd appreciate any feedback. The more decision power the person >> giving the feedback, the more valuable it is for me :-) >> >> Thanks! >> >> Silvano >> >> >> On 12/01/2021 11:33, [ext] Silvano Cirujano Cuesta wrote: >>> This patch series adds to the SDK generation (task `populate_sdk`) >>> the possibility of generating container images containing the SDK in >>> different formats (multiple formats can be generated at once). >>> >>> Up-to-now the task `populate_sdk` generates the sdk root filesystem >>> (in both as a file tree and in a tarball) that can be chrooted to. >>> The same root filesystem can be easily distributed as a container >>> image and started as a container. >>> >>> It's even possible extracting the root filesystem from a container >>> image, using the container image format only as a sort of packaging >>> system for easy distribution. >>> >>> More information about its usage is documented in the file >>> docs/user_manual.md. >>> >>> Typical container image management actions (e.g. push an image to a >>> container image regitry) are out of scope. Available tools (Docker, >>> Skopeo, Buildah, Podman,...) should be used for these actions. >>> >>> Silvano Cirujano Cuesta (2): >>> sdk: support creation of container image >>> docs: document usage of sdk container images >>> >>> doc/user_manual.md | 70 +++++++++++++++++ >>> meta/classes/image-sdk-extension.bbclass | 99 >>> ++++++++++++++++++++++-- 2 files changed, 162 insertions(+), 7 >>> deletions(-)
On 15/01/2021 08:09, Jan Kiszka wrote: > On 14.01.21 14:56, [ext] Silvano Cirujano Cuesta wrote: >> I wonder how to interpret the current feelings about this proposal: >> >> * There's no interest at all. >> >> * I haven't succeed on raising enough interest. In that case I'd need more input from people who see the demand for this functionality to better understand what's missing in my proposal. >> >> * There's interest, but I should update the patch according the comments up-to-now before I send a 1st patch series proposal (or a 2nd RFC). >> >> I'd appreciate any feedback. The more decision power the person giving the feedback, the more valuable it is for me :-) >> > The level of feedback you received is already quite good for a first > round :), and there is usually no early feedback from maintainers. I don't meant that the feedback was bad, only mostly opposed :-) > I would say update the series, addressing that smaller issue(s) and > remove the RFC. I'll also give that a try soon. This is enough feedback to confirm me on moving forward. My next steps are then: addressing the small issues and adding in the cover letter information on how to easily test it. Silvano > > Thanks a lot, > Jan >