Potential supply-chain risks using third-party dependencies

[randshell]

See initial discussion in #110 (comment).

I'd like to focus specifically on the third-party dependencies that we include ourselves and not worry about the ones that Deezer officially includes. Some examples are the packages for the Discord integration and the better MPRIS management.

PS. I've tagged you here one more time aunetx, I hope that's okay. It'd be something that would need your feedback as well, so it was important enough I'd say. 🙂

[randshell]

As a side node, I did skim through the forks and their diffs a couple of months ago when we added them, but I'd feel more at ease to have them properly forked ourselves.

[aunetx]

Hi! Thanks for all your work, of course there is no problem in tagging me multiple times!

I think forking is indeed the best idea, but doing so under my username would not be ideal (because I'm way less involved than you in the project, and I don't want it to depend on my presence -- as you have seen multiple times, this often blocks the process).

So doing so under an organization would be ideal, in which case this repo would also be transferred to the same org, so we all share equal rights on the project (I'm not sure I want not to be involved anymore at all, simply right now and for the next year or so it will be difficult to give this project a lot of time). I never tried doing something like this, so I will try it on some mock repo of mine first; but my only questions are:

• the url of the repo will change (although github will probably redirect the old urls transparently), so we need to find if there are places that depend on it (I guess the flatpak build yaml, but idk what else)
• we need to figure a name for the project (to make it look neutral but not official), I guess something like deezer-linux-community or simply deezer-linux (if it makes it clear enough that the project does not originate from Deezer itself? I guess it is better if we make sure not to piss them off, although this is clearly some work they should be doing themselves...)
• and lastly, once the organisation is ready etc, do you think we should change the id of the flatpak package too? It is dev.aunetx.deezer right now, I guess org.deezer-community.deezer (or something like that) would be more adequate, but the flathub recommendations are that we would need to own the url (which is why I named it dev.aunetx.deezer in the first place, as I own aunetx.dev, however buying a domain name for this project would be completely overkill). But this is clearly secondary, so there is no need to discuss it too much, simply sharing my though on this!

So if you're all OK @randshell, @josselinonduty and @asyd, and we settle on a name, I guess I will create an org, add you to it and transfer this repo to the org -- and then let you fork the other packages with it!

[aunetx]

Well, just tried transferring a repo to an organization, it is pretty straightforward so I'll do this as soon as you're ok with that!

[josselinonduty]

the url of the repo will change

I can only think of flathub and here. Maybe snap later, but it would come afterwards

we need to figure a name for the project

I think @deezer-community/deezer-linux would make a great name.
It makes it be clear that this org and its repos are community-driven, and would be easily found.

We could also one day feature other projects that fit our objectives or values under the name @deezer-community/<some_project>, which would be great for centralisation. Some kind of "awesome-deezer" if you know this kind of lists

[randshell]

Hmm, generally I'd vote against using the original company / product name as I don't think it's a good idea. Check out for example Bitwarden_rs that was renamed to Vaultwarden to make it clear that it's not related. Though the thing here is that no one from Deezer ever reported this repo in years, so I'm not sure where my stance is on this.

What about, instead, just having the org for the new projects, so for the forks of the dependencies, while leaving this deezer-linux repo as-is? Could this be an options for you all? We already got the permissions working and approvals, so for that matter it's already working well.

I think @deezer-community/deezer-linux would make a great name.

I like this one. On the other hand, given what I said above, I'd be more comfortable with something like @deezer-community/linux if we decide the org will go for this repo too. It has no deezer-linux that could be misleading, but only deezer-community and the linux repo. It's similar to how https://github.com/standardnotes does it so it shouldn't be anything new or confusing. Actually, I'm all in for this option rather than keeping it as-is. I would say it should be even more future-proof. 😄

[aunetx]

About splitting the project between this repo hosted under my name and new repos under the deezer-community organization (I guess that's the right name to use indeed), I'm not sure this is a good idea: it makes the structure of the project a bit weird for newcomers (especially since that would mean only "secondary" repos would be hosted under the main organization), and it makes the lead of the project less clear (because I am clearly not leading it anymore, even though it is still under my name).

And if we indeed transfer this repo to a new organization, I think having it named "linux" is a bit unclear? I mean, if we want to use a generic name, we might as well use "app" (as standardnotes does), but I'm not even sure changing the name of the repo is really important, as long as the organization name makes it clear enough that it is not official.

But that is just my opinion I guess and not very important issues! So we might begin by simply creating a blank organization (with the name "deezer-community") to begin forking the dependencies directly, and then we will be able to transfer this repo to the org (if we decide so) later. If you're ok with that, just 👍 this message and I'll create it!

[randshell]

Yeah, that would be cool to just start with the dependencies first.

As for my idea to keep the app repo here, I think there could be SEO issues between the org and this repo, so I think I'll pass this option and would rather have a neutral name under deezer-community.

[randshell]

Side note, it looks like with the addition of Snaps we are doing quite a bit of building... We should check before moving this repo that we'll still have enough action minutes and space on a free org account, if there's any difference.

[aunetx]

Indeed, it looks like we used 66 minutes of action last month (over the 2000 free minutes/month for free orgs), so there is no problem on this side (even with snap building I guess).

Concerning the storage though, it is less clear: it looks like we would have 500 Mb of free package storage, but I think that is not referring to actual releases (which are the only important things for us), and according to this page we would actually have 2 Gb of release storage, which is perfect.

I think in general there would not be downgrades between a free user's repo and a free organization repo, so we should not have issue there!

[josselinonduty]

deps, then @deezer-community/linux is okay with me 👍

[aunetx]

@josselinonduty @randshell @asyd I created https://github.com/deezer-community and invited you as co-owners of the organization (idk if it is ok to have 4 owners at the same time but i guess we do what we want); so you can now fork the packages there! And we will see later to move this repo to the org