[Fwd: Renaming "docker" references to generic ones like "container"
or "OCI']
by Dennis Gilmore
I am forwarding to devel list as Sushma was not subscribed and it was
rejected.
Dennis
--------- Mensaje reenviado --------
De: Sushma Gajanur Shivakumar <sgajanur(a)redhat.com>
Para: devel-announce(a)lists.fedoraproject.org
Cc: Ben Breard <bbreard(a)redhat.com>, dennis(a)ausil.us, Mohan Boddu <mbod
du(a)redhat.com>, Greg Sterling <gsterlin(a)redhat.com>
Asunto: Renaming "docker" references to generic ones like "container"
or "OCI'
Fecha: Fri, 13 Apr 2018 16:15:32 +0200
Hi All,
As the container landscape has changed over the last few years, Docker
Inc. has changed what the term "docker" means. Along with changes in
the container namespace with tools like buildah, cri-o, rkt and other
ways to run containers, it makes sense to refer to containers in a more
generic sense, using terms like "container" or "OCI(Open Container
Initiative)" instead of "docker".
We have already renamed the Docker namespace to "containers" in dist-
git. The Bugzilla project for containers is under container as well.
Wherever possible to be consistent with using more generic terms,
"docker" should be renamed to an appropriate generic term. This will
allow us to more seamlessly adapt and change with the continuing
evolution of the container based world. A side effect is that the
changes will more closely align us with ongoing work within Red Hat.
There are several areas that can be evaluated for changes from "docker"
to "container" (or OCI). These include:
Changing a package description to be more generic
Working with upstream to rename the project and bringing that back to
Fedora
Changing labels and descriptions used within Dockerfiles
The non-exhaustive* full list of current containers[1] and packages[2]
to be considered is not a very large list and your consideration and
efforts to help are greatly appreciated.
* The bellow URLs will not show a package that is using docker only in
the package description which shows up in bugzilla along with other
locations
[1] https://src.fedoraproject.org/projects/container/%2A
[2] https://src.fedoraproject.org/projects/*docker*
Best Regards,
Sushma Shivakumar
RCM Project Manager
Red Hat, Brno
6 years, 2 months
Delay in upcoming Two Week Atomic Release
by Sinny Kumari
Hi all,
This email is to inform that there will be some delay in next Atomic Two
Week
Release. This is due to some issues with uploading Atomic AMIs. We are
working
on getting it fixed as soon as possible. Once we have AMIs back, we will do
next
Two week release.
Thanks,
Sinny
6 years, 2 months
RHEL 7.5 for aarch64
by Bojan Smojver
Anyone knows when RHEL 7.5 packages will be available for aarch64 in
koji, so that new dependencies get picked up? I'm trying to build EPEL7
xorgxrdp against the latest xorg-x11-server and all other arches have
1.19.5, but aarch64 is stuck on 1.19.3.
PS. Buildroot overrides don't work here, AFAICT.
Thanks,
--
Bojan
6 years, 2 months
Unacceptable size increase to ALL live images in F28 (caused by Annobin?)
by Kevin Kofler
Hi,
on #fedora-kde, we discussed a huge increase to the size of the KDE live
image:
F27 KDE GA: 1656752111 bytes
F27 KDE Respin: 1744830464 bytes
F28 KDE Beta: 2069889024 bytes
It turns out the LXQt live image is also hit:
F27 LXQt GA: < 1 GiB
F28 LXQt Beta: 1.4 GiB
and I am pretty sure that this is a global issue affecting ALL the live
images.
While there is certainly more than one cause (e.g., the difference between
F27 KDE GA and the F27 KDE Respin must be caused by package updates and/or
added dependencies), it is striking that between a recent F27 KDE Respin
(which has several of the KDE package updates that are also in the F28 Beta)
and the F28 Beta, there is a size increase of more than 300 MB!
Therefore, my question:
Is this size increase caused by Annobin?
If not, then WHAT causes this size increase? And can the offending change(s)
be reverted in time for F28 Final?
If yes, then IMHO it is time to enact the contingency plan, i.e.:
1. drop the annobin requirement from redhat-rpm-config, AND
2. perform an emergency mass rebuild to actually get rid of the bloat.
A global live image size increase of 19%-40% is just not acceptable.
Kevin Kofler
6 years, 2 months