Docs/minimization
2
0
Fork 0
Code Issues 19 Pull requests Projects Releases Packages Wiki Activity Actions

Drop systemd from container images #2

New issue
Open
opened 2019-08-04 20:39:16 +00:00 by ignatenkobrain · 35 comments
ignatenkobrain commented 2019-08-04 20:39:16 +00:00
Copy link

Size change

  • 238.7 MB → 220.6 MB

Disappearing packages

  • systemd-243~rc1-1.fc31.x86_64: 13.5 MB
  • cryptsetup-libs-2.2.0-0.3.fc31.x86_64: 1.6 MB
  • dbus-broker-21-6.fc31.x86_64: 433.4 kB
  • device-mapper-libs-1.02.163-1.fc31.x86_64: 421.7 kB
  • libpcap-14:1.9.0-4.fc31.x86_64: 367.2 kB
  • device-mapper-1.02.163-1.fc31.x86_64: 354.4 kB
  • systemd-pam-243~rc1-1.fc31.x86_64: 345.9 kB
  • libseccomp-2.4.1-1.fc31.x86_64: 341.4 kB
  • acl-2.2.53-4.fc31.x86_64: 217.1 kB
  • kmod-libs-26-4.fc31.x86_64: 202.2 kB
  • qrencode-libs-4.0.2-4.fc31.x86_64: 163.2 kB
  • iptables-libs-1.8.3-5.fc31.x86_64: 160.2 kB
  • libargon2-20171227-3.fc31.x86_64: 56.2 kB
  • dbus-common-1:1.12.16-3.fc31.noarch: 11.5 kB
  • systemd-rpm-macros-243~rc1-1.fc31.noarch: 5.0 kB
  • dbus-1:1.12.16-3.fc31.x86_64: 0 Bytes

cc @zbyszek @cverna

### Size change * `238.7 MB → 220.6 MB` ### Disappearing packages - `systemd-243~rc1-1.fc31.x86_64`: 13.5 MB - `cryptsetup-libs-2.2.0-0.3.fc31.x86_64`: 1.6 MB - `dbus-broker-21-6.fc31.x86_64`: 433.4 kB - `device-mapper-libs-1.02.163-1.fc31.x86_64`: 421.7 kB - `libpcap-14:1.9.0-4.fc31.x86_64`: 367.2 kB - `device-mapper-1.02.163-1.fc31.x86_64`: 354.4 kB - `systemd-pam-243~rc1-1.fc31.x86_64`: 345.9 kB - `libseccomp-2.4.1-1.fc31.x86_64`: 341.4 kB - `acl-2.2.53-4.fc31.x86_64`: 217.1 kB - `kmod-libs-26-4.fc31.x86_64`: 202.2 kB - `qrencode-libs-4.0.2-4.fc31.x86_64`: 163.2 kB - `iptables-libs-1.8.3-5.fc31.x86_64`: 160.2 kB - `libargon2-20171227-3.fc31.x86_64`: 56.2 kB - `dbus-common-1:1.12.16-3.fc31.noarch`: 11.5 kB - `systemd-rpm-macros-243~rc1-1.fc31.noarch`: 5.0 kB - `dbus-1:1.12.16-3.fc31.x86_64`: 0 Bytes --- cc @zbyszek @cverna
ignatenkobrain commented 2019-08-04 20:40:10 +00:00
Author
Copy link

The only reason why systemd is there is DNF. It has %{?systemd_requires}, but it has only dnf-makecache.{timer,service} so I think we can drop it.

The only reason why systemd is there is DNF. It has `%{?systemd_requires}`, but it has only `dnf-makecache.{timer,service}` so I think we can drop it.
ignatenkobrain commented 2019-08-04 20:41:14 +00:00
Author
Copy link

Though, @ngompa pointed out that dnf-data ships %{_tmpfilesdir}/dnf.conf but does not call any scriptlet for that.

Though, @ngompa pointed out that `dnf-data` ships `%{_tmpfilesdir}/dnf.conf` but does not call any scriptlet for that.
ngompa commented 2019-08-04 20:51:51 +00:00
Copy link

@ignatenkobrain Hmm, I thought we did call a script for it... In any case, these days, it'd be invoked via file trigger.

The problem is that DNF behaves very poorly when the directories don't exist in the container...

@ignatenkobrain Hmm, I thought we did call a script for it... In any case, these days, it'd be invoked via file trigger. The problem is that DNF behaves very poorly when the directories don't exist in the container...
zbyszek commented 2019-08-05 07:02:12 +00:00
Copy link

What kind of container? There are containers which definitely require an init process, to start services. Then there are containers which still require something to reap zombies. So before we go ripping out stuff, let's clarify what we are ripping it out of ;)

What kind of container? There are containers which definitely require an init process, to start services. Then there are containers which still require something to reap zombies. So before we go ripping out stuff, let's clarify what we are ripping it out of ;)
cverna commented 2019-08-05 09:09:13 +00:00
Copy link

What kind of container? There are containers which definitely require an init process, to start services. Then there are containers which still require something to reap zombies. So before we go ripping out stuff, let's clarify what we are ripping it out of ;)

Yes I think this is a valid point, I guess we could follow what UBI does and provide 3 base images.

fedora
fedora-minimal
fedora-init

We currently have fedora and fedora-minimal but we don't have the fedora-init. So if we were to drop systemd from the fedora and fedora-minimal images I think we need to introduce the fedora-init image first.

> What kind of container? There are containers which definitely require an init process, to start services. Then there are containers which still require something to reap zombies. So before we go ripping out stuff, let's clarify what we are ripping it out of ;) Yes I think this is a valid point, I guess we could follow what UBI does and provide 3 base images. ``` fedora fedora-minimal fedora-init ``` We currently have `fedora` and `fedora-minimal` but we don't have the `fedora-init`. So if we were to drop systemd from the `fedora` and `fedora-minimal` images I think we need to introduce the `fedora-init` image first.
asamalik commented 2019-08-05 11:48:17 +00:00
Copy link

What kind of container? There are containers which definitely require an init process, to start services. Then there are containers which still require something to reap zombies. So before we go ripping out stuff, let's clarify what we are ripping it out of ;)

@zbyszek's comment is exactly why I don't want to focus on containers [1] and decide what goes there and what doesn't. I's a very different discussion.

If there are some use cases of container images not having systemd (and yes there are), we can definitely enable them by making possible for the packages to be installed functional without systemd, but leave the actual decision of removing vs. keeping it there (or having two variants of images) for the image maintainers.

[1] The "Images are not our direct goal" part of https://docs.fedoraproject.org/en-US/minimization/#_strategy

> What kind of container? There are containers which definitely require an init process, to start services. Then there are containers which still require something to reap zombies. So before we go ripping out stuff, let's clarify what we are ripping it out of ;) @zbyszek's comment is exactly why I don't want to focus on containers [1] and decide what goes there and what doesn't. I's a very different discussion. If there are some use cases of container images not having systemd (and yes there are), we can definitely enable them by making possible for the packages to be installed functional without systemd, but leave the actual decision of removing vs. keeping it there (or having two variants of images) for the image maintainers. [1] The "Images are not our direct goal" part of https://docs.fedoraproject.org/en-US/minimization/#_strategy
zbyszek commented 2019-08-12 14:26:15 +00:00
Copy link

Independent of the wider discussion (what is a "container", etc.), it's totally reasonable to drop %systemd_requires from dnf rpm. Guidelines change: https://pagure.io/packaging-committee/pull-request/890.

Independent of the wider discussion (what is a "container", etc.), it's totally reasonable to drop %systemd_requires from dnf rpm. Guidelines change: https://pagure.io/packaging-committee/pull-request/890.
cverna commented 2019-08-20 19:42:44 +00:00
Copy link

@ignatenkobrain I wonder if the change in dnf is causing the following error
screenshot-1.png

@ignatenkobrain I wonder if the change in dnf is causing the following error [![screenshot-1.png](/minimization/issue/raw/files/bd083c71cf59920549c10e25c85a971143b734b482764b47c475c2070954b3e0-screenshot-1.png)](/minimization/issue/raw/files/bd083c71cf59920549c10e25c85a971143b734b482764b47c475c2070954b3e0-screenshot-1.png)
zbyszek commented 2019-08-20 19:47:45 +00:00
Copy link

If nothing else is pulling systemd in, that would be plausible.

If nothing else is pulling systemd in, that would be plausible.
cverna commented 2019-08-20 20:04:14 +00:00
Copy link

Ha I think I found why, in the post install section in the kickstart we are using systemctl to disable or mask some services

https://pagure.io/fedora-kickstarts/blob/master/f/fedora-container-base.ks#_30

I guess we don't need that anymore 😄

Ha I think I found why, in the post install section in the kickstart we are using systemctl to disable or mask some services https://pagure.io/fedora-kickstarts/blob/master/f/fedora-container-base.ks#_30 I guess we don't need that anymore :smile:
cverna commented 2019-08-21 09:29:43 +00:00
Copy link

Ok so after looking at it a bit closer, I think anaconda is expecting systemd to be present. It is trying to configure the systemd default target during the installation.

I did not see a way to bypass that but I am far from being an expert in anaconda. I ll wait and see if the anaconda folks respond to my question on their IRC channel.

Ok so after looking at it a bit closer, I think anaconda is expecting systemd to be present. It is trying to configure the systemd default target during the installation. I did not see a way to bypass that but I am far from being an expert in anaconda. I ll wait and see if the anaconda folks respond to my question on their IRC channel.
yselkowitz commented 2019-09-04 17:09:01 +00:00
Copy link

For background, this came up during our previous minimization efforts:

https://pagure.io/packaging-committee/issue/644

For background, this came up during our previous minimization efforts: https://pagure.io/packaging-committee/issue/644
asamalik commented 2019-09-05 11:26:35 +00:00
Copy link

The difference can be seen here comparing f30 (with systemd), and f31 or Rawhide (without) https://minimization.github.io/reports/report-base-releases--fedora-container-base.html

The difference can be seen here comparing f30 (with systemd), and f31 or Rawhide (without) https://minimization.github.io/reports/report-base-releases--fedora-container-base.html
tdawson commented 2019-09-05 17:07:17 +00:00
Copy link

The difference can be seen here comparing f30 (with systemd), and f31 or Rawhide (without) https://minimization.github.io/reports/report-base-releases--fedora-container-base.html

I just want to point out that the reason for this change is due to dnf dropping it's dependency on systemd. As was talked about in this comment https://pagure.io/minimization/issue/2#comment-587776

> The difference can be seen here comparing f30 (with systemd), and f31 or Rawhide (without) https://minimization.github.io/reports/report-base-releases--fedora-container-base.html I just want to point out that the reason for this change is due to dnf dropping it's dependency on systemd. As was talked about in this comment https://pagure.io/minimization/issue/2#comment-587776
tdawson commented 2019-09-05 17:08:28 +00:00
Copy link

I have created pull requests to remove systemd from httpd and nginx.

httpd: https://src.fedoraproject.org/rpms/httpd/pull-request/7
nginx: https://src.fedoraproject.org/rpms/nginx/pull-request/5

I have created pull requests to remove systemd from httpd and nginx. httpd: https://src.fedoraproject.org/rpms/httpd/pull-request/7 nginx: https://src.fedoraproject.org/rpms/nginx/pull-request/5
asamalik commented 2019-09-09 15:30:36 +00:00
Copy link

Metadata Update from @asamalik:

  • Issue tagged with: Package Notes
**Metadata Update from @asamalik**: - Issue tagged with: Package Notes
asamalik commented 2019-09-10 08:23:12 +00:00
Copy link

Metadata Update from @asamalik:

  • Issue tagged with: Focus Area: Use Case Analysis
**Metadata Update from @asamalik**: - Issue tagged with: Focus Area: Use Case Analysis
msuchy commented 2019-09-12 18:03:04 +00:00
Copy link

Note, that when you remove systemd from container then you cannot create users and groups using sysusers.

Note, that when you remove systemd from container then you cannot create users and groups using sysusers.
tdawson commented 2019-09-16 15:10:18 +00:00
Copy link

Note, that when you remove systemd from container then you cannot create users and groups using sysusers.
Thank you for bringing this up. You are correct, and this is going to need a bigger discussion. I have created a new issue just for this.

https://pagure.io/minimization/issue/13

> Note, that when you remove systemd from container then you cannot create users and groups using sysusers. Thank you for bringing this up. You are correct, and this is going to need a bigger discussion. I have created a new issue just for this. https://pagure.io/minimization/issue/13
tdawson commented 2019-10-03 20:07:54 +00:00
Copy link

systemd is still in the main Fedora containers. The culprit is gnupg2 (possibly)

gpgme and rpm-sign-libs -> gnupg2 -> libusbx -> systemd-libs

Other things are pulled in with libusbx, most of them hardware related.

systemd is still in the main Fedora containers. The culprit is gnupg2 (possibly) gpgme and rpm-sign-libs -> gnupg2 -> libusbx -> systemd-libs Other things are pulled in with libusbx, most of them hardware related.
tdawson commented 2019-10-04 15:41:05 +00:00
Copy link

systemd is still in the main Fedora containers. The culprit is gnupg2 (possibly)
gpgme and rpm-sign-libs -> gnupg2 -> libusbx -> systemd-libs
Other things are pulled in with libusbx, most of them hardware related.

Sveral things came out of investigating this.

  • gnupg2 either has usb enabled through all the software, or not at all. There isn't some binary or library that we can put in a sub-package. Looking at the use cases for gnupg2 and usb, I agree with the packagers that usb should remain on.
  • systemd-libs does not pull in the rest of systemd, or any other dependencies. So, while libusbx and systemd-libs are hardware packages, they are not that huge. It is not worth the effort to pull them out.
  • systemd is put into the container due to an anaconda bug. anaconda is used to create the initial fedora image. https://github.com/rhinstaller/anaconda/pull/2098 The pull request to fix the bug has been merged and built (anaconda-32.3). Now it's just a matter of time before this get's put on the koji builders, and systemd can be removed from the base fedora container.
> systemd is still in the main Fedora containers. The culprit is gnupg2 (possibly) > gpgme and rpm-sign-libs -> gnupg2 -> libusbx -> systemd-libs > Other things are pulled in with libusbx, most of them hardware related. Sveral things came out of investigating this. * gnupg2 either has usb enabled through all the software, or not at all. There isn't some binary or library that we can put in a sub-package. Looking at the use cases for gnupg2 and usb, I agree with the packagers that usb should remain on. * systemd-libs does *not* pull in the rest of systemd, or any other dependencies. So, while libusbx and systemd-libs are hardware packages, they are not that huge. It is not worth the effort to pull them out. * systemd is put into the container due to an anaconda bug. anaconda is used to create the initial fedora image. https://github.com/rhinstaller/anaconda/pull/2098 The pull request to fix the bug has been merged and built (anaconda-32.3). Now it's just a matter of time before this get's put on the koji builders, and systemd can be removed from the base fedora container.
cverna commented 2019-11-04 16:03:39 +00:00
Copy link

Once the koji builder are updated to Fedora 31, we should be able to use the version of anaconda that has the fix in it.

I think that this should happen soon 😄

Once the koji builder are updated to Fedora 31, we should be able to use the version of anaconda that has the fix in it. I think that this should happen soon :smile:
tdawson commented 2020-01-22 15:04:40 +00:00
Copy link

Have the koji builders been updated to Fedora 31?
And if so, have we been able to remove systemd from base containers and images?

Have the koji builders been updated to Fedora 31? And if so, have we been able to remove systemd from base containers and images?
menantea commented 2020-05-26 07:46:55 +00:00
Copy link

Install of httpd on Fedora-Container-Minimal-Base image is not successfull due to systemd. see https://bugzilla.redhat.com/show_bug.cgi?id=1824208

Install of httpd on Fedora-Container-Minimal-Base image is not successfull due to systemd. see https://bugzilla.redhat.com/show_bug.cgi?id=1824208
tdawson commented 2020-05-26 13:50:02 +00:00
Copy link

Install of httpd on Fedora-Container-Minimal-Base image is not successfull due to systemd. see https://bugzilla.redhat.com/show_bug.cgi?id=1824208

Although this deals with minimizing, this needs to stay with the container images team, not the minimization team.
I have put my investigation information in the bugzilla.

But, for those that are seeing just this, when trimming down unnecessary files out of rpms, they accidentally took out the libsystemd-shared-245.so file, which is needed by systemctl.

> Install of httpd on Fedora-Container-Minimal-Base image is not successfull due to systemd. see https://bugzilla.redhat.com/show_bug.cgi?id=1824208 Although this deals with minimizing, this needs to stay with the container images team, not the minimization team. I have put my investigation information in the bugzilla. But, for those that are seeing just this, when trimming down unnecessary files out of rpms, they accidentally took out the libsystemd-shared-245.so file, which is needed by systemctl.
cverna commented 2020-05-26 18:34:18 +00:00
Copy link

I am not sure that there is a container images team :P

For info systemd has now been remove from both base image (fedora and fedora-minimal) in rawhide.

It would be nice to have people testing it to see if everything is working as expected :)

cc @siddharthvipul1

I am not sure that there is a container images team :P For info systemd has now been remove from both base image (fedora and fedora-minimal) in rawhide. It would be nice to have people testing it to see if everything is working as expected :) cc @siddharthvipul1
menantea commented 2020-05-27 08:17:06 +00:00
Copy link

I am not sure that there is a container images team :P
For info systemd has now been remove from both base image (fedora and fedora-minimal) in rawhide.
It would be nice to have people testing it to see if everything is working as expected :)
cc @siddharthvipul1
Yes, I confirm is working fine still Fedora-Container-Minimal-Base-30-20200525.0.ppc64le.tar.xz
Thanks

> I am not sure that there is a container images team :P > For info systemd has now been remove from both base image (fedora and fedora-minimal) in rawhide. > It would be nice to have people testing it to see if everything is working as expected :) > cc @siddharthvipul1 Yes, I confirm is working fine still Fedora-Container-Minimal-Base-30-20200525.0.ppc64le.tar.xz Thanks
siddharthvipul1 commented 2020-05-27 08:23:52 +00:00
Copy link

Yes, I confirm is working fine still Fedora-Container-Minimal-Base-30-20200525.0.ppc64le.tar.xz
Thanks

We have removed systemd just from the rawhide. Please test that :)
Thank you

here is a link to the build https://koji.fedoraproject.org/koji/buildinfo?buildID=1514234

> Yes, I confirm is working fine still Fedora-Container-Minimal-Base-30-20200525.0.ppc64le.tar.xz > Thanks We have removed systemd just from the rawhide. Please test that :) Thank you here is a link to the build https://koji.fedoraproject.org/koji/buildinfo?buildID=1514234
menantea commented 2020-05-27 09:07:12 +00:00
Copy link

argh, I looked to wrong tests, tests are running automatically in my openqa environment on available nightly composes.

Fedora-Container-Minimal-Base-30-20200525.0.ppc64le.tar.xz don't have the problem (I guess he never had).

Fedora-Container-Minimal-Base-31-20200525.0.ppc64le.tar.xz and
Fedora-Container-Minimal-Base-32-20200526.0.ppc64le.tar.xz still failed with: error while loading shared libraries: libsystemd-shared-245.so at hhttpd installation

and Fedora-Container-Minimal-Base-Rawhide-20200525.n.0.ppc64le.tar.xz don't have the problem on httpd install anymore.

Please confirm me your change is already in https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200525.n.0/compose/Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20200525.n.0.ppc64le.tar.xz

argh, I looked to wrong tests, tests are running automatically in my openqa environment on available nightly composes. Fedora-Container-Minimal-Base-30-20200525.0.ppc64le.tar.xz don't have the problem (I guess he never had). Fedora-Container-Minimal-Base-31-20200525.0.ppc64le.tar.xz and Fedora-Container-Minimal-Base-32-20200526.0.ppc64le.tar.xz still failed with: error while loading shared libraries: libsystemd-shared-245.so at hhttpd installation and Fedora-Container-Minimal-Base-Rawhide-20200525.n.0.ppc64le.tar.xz don't have the problem on httpd install anymore. Please confirm me your change is already in https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200525.n.0/compose/Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20200525.n.0.ppc64le.tar.xz
siddharthvipul1 commented 2020-05-27 09:48:33 +00:00
Copy link

Please confirm me your change is already in https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200525.n.0/compose/Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20200525.n.0.ppc64le.tar.xz

Yes! every rawhide nightly build after https://www.pagure.io/fedora-kickstarts/pull-request/645 getting merged should be without systemd

> Please confirm me your change is already in https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20200525.n.0/compose/Container/ppc64le/images/Fedora-Container-Minimal-Base-Rawhide-20200525.n.0.ppc64le.tar.xz Yes! every rawhide nightly build after https://www.pagure.io/fedora-kickstarts/pull-request/645 getting merged should be without systemd
menantea commented 2020-05-27 12:03:17 +00:00
Copy link

I don't see any side effect right now so this change can be applied on f31 and f32.

I don't see any side effect right now so this change can be applied on f31 and f32.
siddharthvipul1 commented 2020-06-03 09:37:20 +00:00
Copy link

I don't see any side effect right now so this change can be applied on f31 and f32.

done :)
Thank you for testing rawhide build, I will ping some more folks to confirm it working in these as well

> I don't see any side effect right now so this change can be applied on f31 and f32. done :) Thank you for testing rawhide build, I will ping some more folks to confirm it working in these as well
bowlofeggs commented 2020-07-14 16:52:02 +00:00
Copy link

I have proposed reverting this change for stable releases at https://pagure.io/fedora-kickstarts/pull-request/660

I think it would be good to have a solution for https://bugzilla.redhat.com/show_bug.cgi?id=1841139 before Fedora 33 is released. I saw a suggestion upthread to provide a fedora-init base image that still contains systemd, which I think would probably be acceptable (perhaps naming it fedora-systemd would aid users in discovering it?). I think it might be ideal to get the systemd units to a state where they somehow avoid failing when running in containers, though I'm not sure if that is feasible or not.

In any case, if we proceed as-is, I think this may be painful for users who are using systemd in containers since they need to do more than a simple dnf install systemd to have a working container.

I have proposed reverting this change for stable releases at https://pagure.io/fedora-kickstarts/pull-request/660 I think it would be good to have a solution for https://bugzilla.redhat.com/show_bug.cgi?id=1841139 before Fedora 33 is released. I saw a suggestion upthread to provide a fedora-init base image that still contains systemd, which I think would probably be acceptable (perhaps naming it fedora-systemd would aid users in discovering it?). I think it might be ideal to get the systemd units to a state where they somehow avoid failing when running in containers, though I'm not sure if that is feasible or not. In any case, if we proceed as-is, I think this may be painful for users who are using systemd in containers since they need to do more than a simple ```dnf install systemd``` to have a working container.
vasintalana commented 2020-07-15 02:40:56 +00:00
Copy link

What a nightmare
When the systemctl command doesn't exist in fedora 32
and just found out the systemd package was removed.
Will there be a fedora-init like @cverna said?

What a nightmare When the systemctl command doesn't exist in fedora 32 and just found out the systemd package was removed. Will there be a fedora-init like @cverna said?
aralbalkan commented 2022-08-16 14:13:54 +00:00
Copy link

Hi everyone,

As @cverna and @vasintalana have mentioned, not having a fedora-init image is making things harder for those of us that need one.

My use case: I’m a web developer and I use Fedora Silverblue. One of the things I make is a web server that I need to test from within a container.

Distrobox enables me to create a rootful container with an init system – which is what I need as a developer – but it needs an image that has systemd in it.

Please see this issue for more details.

Thanks for your time.

Hi everyone, As @cverna and @vasintalana have mentioned, not having a fedora-init image is making things harder for those of us that need one. My use case: I’m a web developer and I use Fedora Silverblue. One of the things I make is [a web server](https://sitejs.org) that I need to test from within a container. Distrobox enables me to create a rootful container with an init system – which is what I need as a developer – but it needs an image that has systemd in it. [Please see this issue for more details.](https://github.com/89luca89/distrobox/issues/379) Thanks for your time.
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
master
No results found.
Labels
Clear labels   
Discussion

Any general topic for discussion

  
Easy

   
Focus Area: Content Strategy

Focus Area

  
Focus Area: Ecosystems Exploration

Focus Area

  
Focus Area: Prototyping Tools

Focus Area

  
Focus Area: Use Case Analysis

Focus Area

  
Idea

   
Meeting
No labels
Discussion
Easy
Focus Area: Content Strategy
Focus Area: Ecosystems Exploration
Focus Area: Prototyping Tools
Focus Area: Use Case Analysis
Idea
Meeting
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
13 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Docs/minimization#2
No description provided.
Delete branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?