This sounds reasonable to me. It might also make since to enable LFS for this repository at the same time.

@ryanlerch: thoughts?

The possibility of a GitLab migration is foreseeable. The Fedora Marketing sub-team on gitlab.com/fedora could be a good landing place for this repository using the pagure-exporter tool.

@jflory7 , I'm a relative newcomer to the Magazine process and this issue made me wonder what the original use of the image repository was intended to be.

I've been dutifully adding the images I create to the repo but only because it was identified as the way things worked. I believe @glb is in a similar situation.

All the images from the articles are available from WP, though admittedly only JPG format. But I can only recall a small handful of times that I've actually had a reason to acquire a SVG image from it. In a couple of those situations I decided to go with a new image.

Is there a reason we are saving all these images? Do we even need the repo?

A secondary question is, assuming a need exists, is there a reason that we should move the images out of Pagure since it is being used for the Fedora Magazine WP theme as well as for our ticket tracking "Newroom"?

I'm not certain moving the images to gitlab as a sub of marketing is ideal. Is that the way some envision the magazine? I'm not convinced on it being marketing as a primary focus, but maybe I'm perceiving it differently. I would prefer to discuss this a bit more and also hearing what the idea of having the magazine as a sub of marketing is really about.
As @rlengland points out, it (pagure) handles the workflow for the magazine now.

@pfrields @bcotton Do either of you want to weigh in on this discussion about moving the magazine image repo to GitLab? Please see the previous (short) discussion so far.
I'm pinging you because of your historical association. Invite anyone else you believe might have background or interest.

Other hosting solutions are also fine, for example other forges or just
a bucket. If a git repository is used, having a separate repo for each
year or each 5 years would be great to keep the repository size
manageable. Some coordination with infra is needed, though there is an
offer to be able to use open shift for Fedora projects, I would be happy
to deploy something other than git which can perhaps offer image search
to allow for image reuse.

I would be happy to deploy something other than git which can perhaps offer image search
to allow for image reuse.

That sounds like an interesting idea. Git was never meant to be a binary file storage system. I'm not sure why we are trying to use it that way.

I'm still in the dark about why we are saving the images. Can anyone explain that to me please?

I'm still in the dark about why we are saving the images. Can anyone explain that to please?

That's a salient point. Do we need to store the images since they are also stored with the post itself? Why was it started ? Do the same reasons for doing it exist now, today? Aside from the concept of having the sources to "build" the post again?

The original idea behind this is reuse -- if we retain the SVG sources for these images, it makes it so simple to grab an existing image, tweak the text, and you have another image. That is impossible with the JPEGs on the magazine page.

Orignially, a lot of the cover images were pure SVG, without embedded bitmaps, so git made sense. Not sure if it still does.

Just my 2 cents on why this was created.

Orignially, a lot of the cover images were pure SVG, without embedded bitmaps, so git made sense. Not sure if it still does.

100%

For the larger collection of bitmaps that we have now, I think we should store them in the WP Engine media library. That library is designed to store, search, and preview images. For purposes of reusability, we just need to keep a copy of the "base" image without the overlaid text. If we adopt a simple naming convention (e.g. names that end with -base.jpg are base images), it should be easy to search for images for reuse.

I'm closing out this issue now so that it doesn't end up stuck in an open state forever when pagure.io goes ready only. If someone wants to discuss it further, you are welcome to bring the subject up in Fedora Magazine's Matrix channel.