Hi, I would like to request adding polarsys-b612-fonts to AutoSD.
Commissioned by Airbus and designed by Intactile Design, B612 is a digital font intended to be used in an aeronautical context. B612 is built with legibility as its core: every character is designed to be highly recognizable even in critical reading conditions. B612 drawing has been optimized for screen display, and full hinting has been added to all sizes of alphanumeric characters.
It's used on airplane cockpits, so within the digital cockpit team we think it makes sense to have it available for automotive cockpits as well.
The polarsys-b612-fonts package is already available in Fedora.
If approved, can you please add the polarsys-b612-fonts repo on https://gitlab.com/CentOS/automotive/rpms ? Thanks,
On Thu, Sep 21, 2023 at 12:06:00PM +0200, Sandro Bonazzola wrote:
Hi, I would like to request adding polarsys-b612-fonts to AutoSD.
Commissioned by Airbus and designed by Intactile Design, B612 is a digital font intended to be used in an aeronautical context. B612 is built with legibility as its core: every character is designed to be highly recognizable even in critical reading conditions. B612 drawing has been optimized for screen display, and full hinting has been added to all sizes of alphanumeric characters.
It's used on airplane cockpits, so within the digital cockpit team we think it makes sense to have it available for automotive cockpits as well.
The polarsys-b612-fonts package is already available in Fedora.
If approved, can you please add the polarsys-b612-fonts repo on https://gitlab.com/CentOS/automotive/rpms ? Thanks,
The project has been created: https://gitlab.com/CentOS/automotive/rpms/polarsys-b612-fonts/
Since it exists in Fedora, if I were you I would just import Fedora's rawhide branch and create an automotive or autosd9s branch for the work specific to our SIG or AutoSD (if you plan on including it there as well).
Pierre
On Thu, 21 Sept 2023 at 15:05, Pierre-Yves Chibon pingou@pingoured.fr wrote:
On Thu, Sep 21, 2023 at 12:06:00PM +0200, Sandro Bonazzola wrote:
Hi, I would like to request adding polarsys-b612-fonts to AutoSD.
Commissioned by Airbus and designed by Intactile Design, B612 is a digital font intended to be used in an aeronautical context. B612 is built with legibility as its core: every character is designed to be highly recognizable even in critical reading conditions. B612 drawing has been optimized for screen display, and full hinting has been added to all sizes of alphanumeric characters.
It's used on airplane cockpits, so within the digital cockpit team we think it makes sense to have it available for automotive cockpits as well.
The polarsys-b612-fonts package is already available in Fedora.
If approved, can you please add the polarsys-b612-fonts repo on https://gitlab.com/CentOS/automotive/rpms ? Thanks,
The project has been created: https://gitlab.com/CentOS/automotive/rpms/polarsys-b612-fonts/
Since it exists in Fedora, if I were you I would just import Fedora's rawhide branch and create an automotive or autosd9s branch for the work specific to our SIG or AutoSD (if you plan on including it there as well).
Another similar technique that's also helpful, is if we ask the Fedora maintainer to create an EPEL9 version of the package, that way the community can help maintain the package and you can just "mirror" EPEL (assuming you keep an eye on the changes they make).
I did this recently when I asked the erofs-utils maintainer to create an EPEL9 rpm for our erosfs related features we are working on:
https://src.fedoraproject.org/rpms/erofs-utils
Pierre _______________________________________________ CentOS-automotive-sig mailing list CentOS-automotive-sig@centos.org https://lists.centos.org/mailman/listinfo/centos-automotive-sig
Il giorno gio 21 set 2023 alle ore 16:38 Eric Curtin ecurtin@redhat.com ha scritto:
Another similar technique that's also helpful, is if we ask the Fedora maintainer to create an EPEL9 version of the package, that way the community can help maintain the package and you can just "mirror" EPEL (assuming you keep an eye on the changes they make).
I did this recently when I asked the erofs-utils maintainer to create an EPEL9 rpm for our erosfs related features we are working on:
I'm not sure this is a good idea. According to https://www.redhat.com/en/blog/whats-epel-and-how-do-i-use-it ``` EPEL is a selection of packages from Fedora, but only packages that are not in RHEL or its layered products to avoid conflicts. ```
And RHIVOS is a layered product so having stuff in EPEL may end up with conflicts later on. We had similar issues with mom https://koji.fedoraproject.org/koji/packageinfo?packageID=12742 and vdsm https://koji.fedoraproject.org/koji/packageinfo?packageID=12944 packages which were also shipped in Red Hat Virtualization (downstream of oVirt project) in the past and we had to drop them from EPEL to solve issues. I would rather avoid AutoSD collisions with EPEL if possible.
On Fri, 22 Sept 2023 at 08:45, Sandro Bonazzola sbonazzo@redhat.com wrote:
Il giorno gio 21 set 2023 alle ore 16:38 Eric Curtin ecurtin@redhat.com ha scritto:
Another similar technique that's also helpful, is if we ask the Fedora maintainer to create an EPEL9 version of the package, that way the community can help maintain the package and you can just "mirror" EPEL (assuming you keep an eye on the changes they make).
I did this recently when I asked the erofs-utils maintainer to create an EPEL9 rpm for our erosfs related features we are working on:
I'm not sure this is a good idea. According to https://www.redhat.com/en/blog/whats-epel-and-how-do-i-use-it
EPEL is a selection of packages from Fedora, but only packages that are not in RHEL or its layered products to avoid conflicts.
So this isn't 'correct'. EPEL is a selection of packages from Fedora, but only packages that are not in RHEL to avoid conflicts.
EPEL will ship things which are in layered products usually because the layered product is tired of getting requests for supporting libZZZ in RHEL when they don't want to but they know that a lot of people are needing it. [Or as some layered products have said the version they have is only there for 1 limited reason but they can't update it so no one should use that version.]
And RHIVOS is a layered product so having stuff in EPEL may end up with conflicts later on. We had similar issues with mom https://koji.fedoraproject.org/koji/packageinfo?packageID=12742 and vdsm https://koji.fedoraproject.org/koji/packageinfo?packageID=12944 packages which were also shipped in Red Hat Virtualization (downstream of oVirt project) in the past and we had to drop them from EPEL to solve issues.
I don't remember those specific packages being a problem on the EPEL side or what release that happened in. Most of the time we have dropped RHEL layered packages from EPEL because they got included in RHEL proper, or the packager was treating EPEL like Fedora with major unannounced updates every couple of weeks because the upstream was too active for enterprise.
I would rather avoid AutoSD collisions with EPEL if possible.
So up until now, the way I thought we have been getting things into AutoSD was: 0. Get it into a COPR 1. Get it in Fedora (so it could get an initial review and items) 2. Get it in EPEL (so it could be seen to work with RHEL and such) 3. Get it in Automotive SIG CBS (to work with CentOS Stream) to see if needed. 4. Get it into AutoSD if really needed.
Steps 3 and 4 have been generally harder than 0, 1 and 2. Plus a fair amount of stuff that has been 'requested' by partners eventually turns out not to be really wanted enough for us to take on the support burden.
I feel that most of the 'hard part' of getting things into 3 and 4 have been that we had a 'hole' in our policies around 'who owns this', 'what does it mean to own it', 'how do we properly review it', and a ton of other things. I believe this is what we are trying to formulate now?
--
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING
Red Hat In-Vehicle Operating System
Red Hat EMEA https://www.redhat.com/ https://www.redhat.com/
*Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.*
CentOS-automotive-sig mailing list CentOS-automotive-sig@centos.org https://lists.centos.org/mailman/listinfo/centos-automotive-sig
On Fri, 22 Sept 2023 at 14:32, Stephen Smoogen ssmoogen@redhat.com wrote:
On Fri, 22 Sept 2023 at 08:45, Sandro Bonazzola sbonazzo@redhat.com wrote:
Il giorno gio 21 set 2023 alle ore 16:38 Eric Curtin ecurtin@redhat.com ha scritto:
Another similar technique that's also helpful, is if we ask the Fedora maintainer to create an EPEL9 version of the package, that way the community can help maintain the package and you can just "mirror" EPEL (assuming you keep an eye on the changes they make).
I did this recently when I asked the erofs-utils maintainer to create an EPEL9 rpm for our erosfs related features we are working on:
I'm not sure this is a good idea. According to https://www.redhat.com/en/blog/whats-epel-and-how-do-i-use-it
EPEL is a selection of packages from Fedora, but only packages that are not in RHEL or its layered products to avoid conflicts.So this isn't 'correct'. EPEL is a selection of packages from Fedora, but only packages that are not in RHEL to avoid conflicts.
I understand these points, valid points. It's just a pity to not take some advantage of combined engineering efforts in the wider Fedora community for packages that are not automotive specific and already in Fedora but not RHEL. Which begs the question what would happen in the RHEL case if they needed to bring in a package that's already in Fedora? A Red Hat employee takes over maintenance or at least co-maintenance in Fedora?
We have to maintain our own packages ultimately though for them to end up in RHIVOS anyway, as EPEL is community supported and that doesn't fly. I suggested mirror loosely as we should have autonomy to fork anyway as needs be (and everything should be reviewed regardless).
EPEL will ship things which are in layered products usually because the layered product is tired of getting requests for supporting libZZZ in RHEL when they don't want to but they know that a lot of people are needing it. [Or as some layered products have said the version they have is only there for 1 limited reason but they can't update it so no one should use that version.]
And RHIVOS is a layered product so having stuff in EPEL may end up with conflicts later on. We had similar issues with mom and vdsm packages which were also shipped in Red Hat Virtualization (downstream of oVirt project) in the past and we had to drop them from EPEL to solve issues.
I don't remember those specific packages being a problem on the EPEL side or what release that happened in. Most of the time we have dropped RHEL layered packages from EPEL because they got included in RHEL proper, or the packager was treating EPEL like Fedora with major unannounced updates every couple of weeks because the upstream was too active for enterprise.
I would rather avoid AutoSD collisions with EPEL if possible.
We probably shouldn't have EPEL repo on at all, if you are treating an AutoSD build like a pending RHIVOS version. Maybe there's some exceptional cases, like development images.
So up until now, the way I thought we have been getting things into AutoSD was: 0. Get it into a COPR
- Get it in Fedora (so it could get an initial review and items)
- Get it in EPEL (so it could be seen to work with RHEL and such)
- Get it in Automotive SIG CBS (to work with CentOS Stream) to see if needed.
- Get it into AutoSD if really needed.
Steps 3 and 4 have been generally harder than 0, 1 and 2. Plus a fair amount of stuff that has been 'requested' by partners eventually turns out not to be really wanted enough for us to take on the support burden.
I feel that most of the 'hard part' of getting things into 3 and 4 have been that we had a 'hole' in our policies around 'who owns this', 'what does it mean to own it', 'how do we properly review it', and a ton of other things. I believe this is what we are trying to formulate now?
--
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING
Red Hat In-Vehicle Operating System
Red Hat EMEA
Red Hat respects your work life balance. Therefore there is no need to answer this email out of your office hours.
CentOS-automotive-sig mailing list CentOS-automotive-sig@centos.org https://lists.centos.org/mailman/listinfo/centos-automotive-sig
-- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren _______________________________________________ CentOS-automotive-sig mailing list CentOS-automotive-sig@centos.org https://lists.centos.org/mailman/listinfo/centos-automotive-sig
On Mon, 25 Sept 2023 at 08:47, Eric Curtin ecurtin@redhat.com wrote:
On Fri, 22 Sept 2023 at 14:32, Stephen Smoogen ssmoogen@redhat.com wrote:
On Fri, 22 Sept 2023 at 08:45, Sandro Bonazzola sbonazzo@redhat.com
wrote:
Il giorno gio 21 set 2023 alle ore 16:38 Eric Curtin <
ecurtin@redhat.com> ha scritto:
Another similar technique that's also helpful, is if we ask the Fedora maintainer to create an EPEL9 version of the package, that way the community can help maintain the package and you can just "mirror" EPEL (assuming you keep an eye on the changes they make).
I did this recently when I asked the erofs-utils maintainer to create an EPEL9 rpm for our erosfs related features we are working on:
I'm not sure this is a good idea. According to
https://www.redhat.com/en/blog/whats-epel-and-how-do-i-use-it
EPEL is a selection of packages from Fedora, but only packages that arenot in RHEL or its layered products to avoid conflicts.
So this isn't 'correct'. EPEL is a selection of packages from Fedora,
but only packages that are not in RHEL to avoid conflicts.
I understand these points, valid points. It's just a pity to not take some advantage of combined engineering efforts in the wider Fedora community for packages that are not automotive specific and already in Fedora but not RHEL. Which begs the question what would happen in the RHEL case if they needed to bring in a package that's already in Fedora? A Red Hat employee takes over maintenance or at least co-maintenance in Fedora?
Basically one of several things have happened in the past:
Before CentOS Stream 1. The group owning the package just start putting it in internal builds, and the community finds out when the next release came out. 2. The group talked with the Fedora packager to see if they could take co-maintainership. Depending on the packager, this would go OK or turn into a 'YOU CAN'T TOUCH MY PRECIOUS' argument. [Enough of the second happened that type 1 was the default plan for most packages.
If the package was in EPEL, then it would be removed at the next minor release. If the package was in Fedora, nothing would change.
After CentOS Stream. 1. The group owning the package puts it into internal builds, and the community finds out via scripts run to see if we have conflicts with CentOS Stream. [These scripts were run on an adhoc basis so things might take a while to go.] 2. The group owning the package would talk... (same)
Possible Future Enterprise Linux Next (ELN) state: 1. The group owning the package changes flags in content-resolver that they are the maintainers of said package. The group then asks for co-maintainership on the package, working out an agreement with the packager on what changes can be made in Fedora versus what would be ELN only. If the changes would not work in Fedora, the group would make an ELN branch where the changes happen. The group is then on the hook about keeping their ELN branch up to date with rawhide for overall package changes. (please see Stephen Gallagher's posts on rhel-devel and fedora devel@lists.fpo for full writeup. My version may be wrong.)
We have to maintain our own packages ultimately though for them to end up in RHIVOS anyway, as EPEL is community supported and that doesn't fly. I suggested mirror loosely as we should have autonomy to fork anyway as needs be (and everything should be reviewed regardless).
EPEL will ship things which are in layered products usually because the
layered product is tired of getting requests for supporting libZZZ in RHEL when they don't want to but they know that a lot of people are needing it. [Or as some layered products have said the version they have is only there for 1 limited reason but they can't update it so no one should use that version.]
And RHIVOS is a layered product so having stuff in EPEL may end up with
conflicts later on.
We had similar issues with mom and vdsm packages which were also
shipped in Red Hat Virtualization (downstream of oVirt project) in the past and we had to drop them from EPEL to solve issues.
I don't remember those specific packages being a problem on the EPEL
side or what release that happened in. Most of the time we have dropped RHEL layered packages from EPEL because they got included in RHEL proper, or the packager was treating EPEL like Fedora with major unannounced updates every couple of weeks because the upstream was too active for enterprise.
I would rather avoid AutoSD collisions with EPEL if possible.
We probably shouldn't have EPEL repo on at all, if you are treating an AutoSD build like a pending RHIVOS version. Maybe there's some exceptional cases, like development images.
So up until now, the way I thought we have been getting things into
AutoSD was:
- Get it into a COPR
- Get it in Fedora (so it could get an initial review and items)
- Get it in EPEL (so it could be seen to work with RHEL and such)
- Get it in Automotive SIG CBS (to work with CentOS Stream) to see if
needed.
- Get it into AutoSD if really needed.
Steps 3 and 4 have been generally harder than 0, 1 and 2. Plus a fair
amount of stuff that has been 'requested' by partners eventually turns out not to be really wanted enough for us to take on the support burden.
I feel that most of the 'hard part' of getting things into 3 and 4 have
been that we had a 'hole' in our policies around 'who owns this', 'what does it mean to own it', 'how do we properly review it', and a ton of other things. I believe this is what we are trying to formulate now?
--
Sandro Bonazzola
MANAGER, SOFTWARE ENGINEERING
Red Hat In-Vehicle Operating System
Red Hat EMEA
Red Hat respects your work life balance. Therefore there is no need to
answer this email out of your office hours.
CentOS-automotive-sig mailing list CentOS-automotive-sig@centos.org https://lists.centos.org/mailman/listinfo/centos-automotive-sig
-- Stephen Smoogen, Red Hat Automotive Let us be kind to one another, for most of us are fighting a hard
battle. -- Ian MacClaren
CentOS-automotive-sig mailing list CentOS-automotive-sig@centos.org https://lists.centos.org/mailman/listinfo/centos-automotive-sig
CentOS-automotive-sig mailing list CentOS-automotive-sig@centos.org https://lists.centos.org/mailman/listinfo/centos-automotive-sig
automotive-sig@lists.centos.org
-
Eric Curtin -
Pierre-Yves Chibon -
Sandro Bonazzola -
Stephen Smoogen