search

vapoursynth / vapoursynth

A video processing framework with simplicity in mind
http://www.vapoursynth.com/
GNU Lesser General Public License v2.1
1.62k stars 150 forks source link

Who is maintaining VapourSynth packages #455

Closed stuxcrystal closed 3 years ago

stuxcrystal commented 5 years ago

I think, we're at a point where we need to coordinate who is packaging vapoursynth in various package managers.

After the djcj-ppa's were removed, there was no ppa that is officially encouraged by the documentation.

I think, we need a point where we coordinate packages for various package-managers in order to A) Avoid duplicate work as two prospective maintainers might be working at the same thing, for example I do not know who is this gogo who registered the VapourSynth team. (Especially because other people don't do so too.) B) Make sure someone knows who to contact if there are issues or questions C) Allow reclaiming of the vapoursynth name in case someone took that name and abandoning maintainance.

To make this problem more clear, consider this recent example:

A: Hey, the djcj-ppa is down what do we do
B: Here's a new one.
Myr: Awesome add it to the docs. We have no idea who it is or if he wants to maintain it longterm.
C: Well, hybrid is also dead.

Related: https://github.com/vapoursynth/vapoursynth/issues/214 https://github.com/vapoursynth/vapoursynth/issues/443#issuecomment-506977626

stuxcrystal commented 5 years ago

For the record: I am maintaining the PyPI-Packages for VapourSynth.

theChaosCoder commented 5 years ago

MacOS packages https://forum.doom9.org/showthread.php?t=175499

myrsloik commented 5 years ago

That's only plugins. The main VS packages are maintained by wm4 on OSX. I agree that this mess should be dealt with so we at least get OSX with plugins (already wm4 does a very good job maintaining VS itself) and Ubuntu well supported.

stuxcrystal commented 5 years ago

PPAs, homebrew and stuff is very important for a project in this stage as it is usually the first contact point with vapoursynth. This is why I think we need to clean up this mess ASAP.

I have chatted with @Youka yesterday. He complained that it is very hard for him to incorporate VapourSynth into his CI-Pipeline as there is no official PPA supporting Ubuntu 16.04 LTS (as you may know, Travis-CI is very slow at adapting new LTS versions while being the defacto standard for CIs). I had the same problem with installing VapourSynth on my system a few days ago

On the other hand, I somehow got this feeling you don't actually care about who and how packaging is being done. This means you rely on third-parties like me to maintain vapoursynth between various package-managers.

However this means, we should have a protocol in place to coordinate who is maintaining the packages. And when we say "he stopped maintaining it".

As I'm pretty sure you're unwilling to maintain previous versions of vapoursynth, (Which I totally understand) I think there need to be strict guidelines when a new release must be done.

With that in mind, I propose the following process:

  1. Please mark your RCs with pre-releases on GitHub. That way, people don't need to scan doom9 for new pre-releases and can automate generating the new pre-release packages and get it out for testing. (You don't need to generate an installer and stuff for those releases) Also it gives us warning that a new production release is imminent.

  2. Prospective new maintainers must create a new issue stating their intentions. If they are accepted, they may officially begin the process to claim the vapoursynth and vsrepo name in the package-manager they chose (including opening disputes).

  3. When a new official package is registered, the maintainer posts the link to the package in the corresponding issue. The link is added to a list hosted on the vapoursynth.com-wordpress-page (as the page is not subject to the vapoursynth release cycle.) The issue will be closed then.

  4. After releasing a new production release of VapourSynth, I motion that we let people two months time to release the new vapoursynth version on their package-managers (except where the package-repository doesn't allow it for some reason; in those cases the maintainer should backport bug-fixes until he can upgrade to the new version.) If they don't manage it, they are removed from the official package-manager list.

  5. I suppose, an Issue-Template would be a good idea to make sure users report how VapourSynth was installed and which version they are using. This can then be used to police point 4.

  6. Packages that are part of an official OS-Level Package-Repository (Debian, NixOS, Gentoo...) are exempt as they usually follow their own QA policy. As such issues with their software should be redirected to the respective maintainer of that package.

This is just a proposal. If you're going to accept it, we also need to speak about where to put this proposal so it official.

EDIT 1: Point 6 OS-Level Package Repositories.

stuxcrystal commented 5 years ago

We conclude: Nothing happened for three weeks. And now?

myrsloik commented 5 years ago

On the other hand, I somehow got this feeling you don't actually care about who and how packaging is being done. This means you rely on third-parties like me to maintain vapoursynth between various package-managers.

Correct. No development would happen if I spent all the time distributing things. Write portable code and people will come along and help with the rest usually.

  1. Please mark your RCs with pre-releases on GitHub. That way, people don't need to scan doom9 for new pre-releases and can automate generating the new pre-release packages and get it out for testing. (You don't need to generate an installer and stuff for those releases) Also it gives us warning that a new production release is imminent.

Sure, I guess I can push a button on github.

  1. Prospective new maintainers must create a new issue stating their intentions. If they are accepted, they may officially begin the process to claim the vapoursynth and vsrepo name in the package-manager they chose (including opening disputes).

  2. When a new official package is registered, the maintainer posts the link to the package in the corresponding issue. The link is added to a list hosted on the vapoursynth.com-wordpress-page (as the page is not subject to the vapoursynth release cycle.) The issue will be closed then.

Any sane communication method would do, really. The online docs aren't really release cycle dependent. I just don't run and update them with every small change. Otherwise I agree.

  1. After releasing a new production release of VapourSynth, I motion that we let people two months time to release the new vapoursynth version on their package-managers (except where the package-repository doesn't allow it for some reason; in those cases the maintainer should backport bug-fixes until he can upgrade to the new version.) If they don't manage it, they are removed from the official package-manager list.

I think we should require more beyond simply core VS. For example plugin compilation is a real pain in the butt when you have to hunt down the 20 or most important ones. Just my opinion.

  1. I suppose, an Issue-Template would be a good idea to make sure users report how VapourSynth was installed and which version they are using. This can then be used to police point 4.

Ok

  1. Packages that are part of an official OS-Level Package-Repository (Debian, NixOS, Gentoo...) are exempt as they usually follow their own QA policy. As such issues with their software should be redirected to the respective maintainer of that package.

Those are the worst. I'm not going to acknowledge them unless they allow fast updates. We should at most link PPAs and whatever the equivalent is everywhere else that can actually be updated quickly. I really don't feel like providing support for VS R<2016>.

This is just a proposal. If you're going to accept it, we also need to speak about where to put this proposal so it official.

EDIT 1: Point 6 OS-Level Package Repositories.

stuxcrystal commented 5 years ago

About Point 2: I'd like a central place where one can post his identity. You know, not in a forum where people need to wait 5 days and answer stupid questions if they want to do anything.

About Point 3: This is exactly why I suggested a WP-Page. It is easier to edit as I have this feeling that you might need to update this more often.

About Point 4: I think this is not always neccessary. For example PyPI doesn't need to have those 20 Plugins in PyPI. But otherwise, those Plugins should be noted down somewhere. And those should be sufficiently documented that figuring out their dependencies (if any) is not an exercise in trial and error.

About Point 6: I'm pretty sure they will come regardless. And the sentence "As such issues with their software should be redirected to the respective maintainer of that package." would establish where we will be sending them with their ancient version. But yes, acknowledging them is not a good idea.

YaLTeR commented 5 years ago

So what would be the best way to get vapoursynth for CI purposes? I need both 64-bit and 32-bit Linux variants, and last time I tried building them from source on Ubuntu I hit major roadblocks with the 32-bit one. I'm already using Docker so using a new version of Ubuntu is not an issue.

myrsloik commented 5 years ago

Roadblocks? Ubuntu version? Be more specific or try again and see if it works now...

myrsloik commented 5 years ago

About Point 2: I'd like a central place where one can post his identity. You know, not in a forum where people need to wait 5 days and answer stupid questions if they want to do anything.

Ok, makes sense I guess.

About Point 3: This is exactly why I suggested a WP-Page. It is easier to edit as I have this feeling that you might need to update this more often.

Makes sense as well.

About Point 4: I think this is not always neccessary. For example PyPI doesn't need to have those 20 Plugins in PyPI. But otherwise, those Plugins should be noted down somewhere. And those should be sufficiently documented that figuring out their dependencies (if any) is not an exercise in trial and error.

Sure, I'll simply encourage it where it makes sense. Doesn't need to be a hard requirement.

About Point 6: I'm pretty sure they will come regardless. And the sentence "As such issues with their software should be redirected to the respective maintainer of that package." would establish where we will be sending them with their ancient version. But yes, acknowledging them is not a good idea.

ghost commented 4 years ago

Why did you remove old versions from PPA Ubuntu 16.04? In 2018, I installed Vapoursynth 44 from there. Everything was there: vapoursynth, ffms2, d2v, vsedit. Everything worked. Now there is nothing. It is not builded from source code - an error appears. The new PPA doesn't have packages for Ubuntu 16.04. Packages for 18.04 are broken: there is a dependency on ffms2, but it is not built. Why didn't you save in the web archive at least?

dubhater commented 4 years ago

@denismn The PPA was/is maintained by a user, not by any VapourSynth developer.

If you encounter problems when compiling VapourSynth, you can put the details in a new issue and someone will probably help you with that.

myrsloik commented 3 years ago

Unresolved mess