Skip to content
This repository has been archived by the owner on May 8, 2021. It is now read-only.

Fira out of date #13

Open
techdragon opened this issue Feb 1, 2016 · 3 comments
Open

Fira out of date #13

techdragon opened this issue Feb 1, 2016 · 3 comments

Comments

@techdragon
Copy link

The Fira font from Mozilla is out of date.
https://github.com/mozilla/Fira

@davelab6
Copy link

davelab6 commented Feb 3, 2016

I wonder that this should NOT include binaries, but just link to a curated collection of links for where to fetch the fonts from upstreams.... or git submodules or something. :)

@bnvk
Copy link
Member

bnvk commented Feb 3, 2016

that's a good question @davelab6 I just opened #14 which is slightly different, but relevant as is #3 so I just created #15 to look at this from a larger POV

@techdragon
Copy link
Author

@davelab6 @bnvk From past experience with this sort of 'meta project' bundling up things from various places. It proved advantageous to organise things to best facilitate tracking upstream automatically. To use this Issue and the Fira font repo as an example:

The config/code to solve #14 and create Debian packages might get in the way of other packaging tools one example of this sort of 'getting in the way' that I see semi-frequently is Gentoo packages which when setup correctly in their own repo, can be sourced direct from 'upstream' on github for hassle free tracking of upstream. But this pretty much only works if the gentoo packaging 'stuff' lives in its own repo.

And on the question of including binaries in this repo opensourcedesign/fonts, both gentoo and debian (and most other packaging toolchains) would be smart enough to go use the original mozilla/Fira repo, but in the interests of 'future proofing' it would be good to also have a fork/copy of Fira under the control of the organization so that if Mozilla ever decided, in some dystopian future, to delete the original Fira repo, then the fork remains and the packages wont become useless.

Its just a suggestion and typing this out I realize it sounds like it could become lots of work, but the point of me suggesting the creation of separate repositories like this, is to suggest the whole situation aim for making it mostly automated to keep the ongoing maintenance burden down, and to retain enough flexibility that almost anyone could come along and use the resources with nearly zero extra effort.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

3 participants