5 ms·

So where is the development continuing with all this?

quyleanh 6y ago
https://github.com/blackjack4494/yt-dlc https://github.com/blackjack4494/yt-dlc Community version with much better support.
- resoluteteeth 6y ago
  I think the question was about where development of the original youtube-dl was happening since there is a new release, not "which fork do you like the best."
- agilob 6y ago
  This project seems to be merging most of what comes its way, but it's not what YT-DL needs now. It needs certainty, security and accountability showing that this isn't harmful fork, there is real person behind the project. You're not getting it by accepting PR that have title "ignore." or "ignore the second.." or by merging 20PR in 8 days. The original author moved to gitlab and started GPG signing commits with his real GPG key. This gives packagers certainty they can replace old github links with new gitlab links, it tells us this project hasn't been compromised and is safe to be redistributed, unlike blackjack4494/yt-dlc
  - TimWolla 6y ago
    > The original author moved to gitlab and started GPG signing commits with his real GPG key. Signed commits from them go back at least 1 year. So its not "started", but rather "continued" signing.
  - kevin_thibedeau 6y ago
    The package index version updated too. That is as certain as it gets.
  - ldarby 6y ago
    Youtube-dlc was discussed here before all this: https://news.ycombinator.com/item?id=24450560 https://news.ycombinator.com/item?id=24450560
  - makeworld 6y ago
    This fork has existed for a long time (under blackjack4494), it isn't some random fork. I don't believe it merges PRs just randomly either, it's just a more active maintainer. This is explained on the README. I'm not totally sure which tool I should use, but I'm leaning towards the fork, because it has more support in general, and has fixed things faster.
agilob 6y ago
Official author moved to GitLab and his commits are GPG signed with his key https://gitlab.com/dstftw/youtube-dl/-/commits/master https://gitlab.com/dstftw/youtube-dl/-/commits/master
- contravariant 6y ago
  I wonder why they called it a "Temporary youtube-dl repository". Are they still planning to go back to GitHub if things work out?
  - agilob 6y ago
    We can't open issues or PR there, it is a read-only repo.
    - Arnavion 6y ago
      TBH given the state that the issue tracker on GH used to be in, I would understand if they never opened up the issue tracker to the general public again. That issue tracker was a great way to lose faith in humanity, just from the sheer number of people who couldn't follow instructions to search for existing issues before opening new ones, or to provide all the answers the issue template asked for.
      - anuila 6y ago
        Open source is bad enough. When open source meets the general public you can enjoy a nice disaster cake.
        londons_explore 6y ago
        A neat way to solve this is with a team of bug triag-ers. Get the developers to never look at a bug unless it has the "triaged' label. Then have trusted volunteers who read each bug, assist the bugreporters to get stack traces and whatever is necessary, dedup, and then finally apply the label. It's a good task for people who have some technical expertise but aren't yet confident to be submitting their own PR's.

https://github.com/blackjack4494/yt-dlc https://github.com/blackjack4494/yt-dlc Community version with much better support.

resoluteteeth 6y ago
I think the question was about where development of the original youtube-dl was happening since there is a new release, not "which fork do you like the best."
agilob 6y ago
This project seems to be merging most of what comes its way, but it's not what YT-DL needs now. It needs certainty, security and accountability showing that this isn't harmful fork, there is real person behind the project. You're not getting it by accepting PR that have title "ignore." or "ignore the second.." or by merging 20PR in 8 days. The original author moved to gitlab and started GPG signing commits with his real GPG key. This gives packagers certainty they can replace old github links with new gitlab links, it tells us this project hasn't been compromised and is safe to be redistributed, unlike blackjack4494/yt-dlc
- TimWolla 6y ago
  > The original author moved to gitlab and started GPG signing commits with his real GPG key. Signed commits from them go back at least 1 year. So its not "started", but rather "continued" signing.
- kevin_thibedeau 6y ago
  The package index version updated too. That is as certain as it gets.
- ldarby 6y ago
  Youtube-dlc was discussed here before all this: https://news.ycombinator.com/item?id=24450560 https://news.ycombinator.com/item?id=24450560
- makeworld 6y ago
  This fork has existed for a long time (under blackjack4494), it isn't some random fork. I don't believe it merges PRs just randomly either, it's just a more active maintainer. This is explained on the README. I'm not totally sure which tool I should use, but I'm leaning towards the fork, because it has more support in general, and has fixed things faster.

agilob 6y ago

Official author moved to GitLab and his commits are GPG signed with his key https://gitlab.com/dstftw/youtube-dl/-/commits/master https://gitlab.com/dstftw/youtube-dl/-/commits/master

contravariant 6y ago
I wonder why they called it a "Temporary youtube-dl repository". Are they still planning to go back to GitHub if things work out?
- agilob 6y ago
  We can't open issues or PR there, it is a read-only repo.
  - Arnavion 6y ago
    TBH given the state that the issue tracker on GH used to be in, I would understand if they never opened up the issue tracker to the general public again. That issue tracker was a great way to lose faith in humanity, just from the sheer number of people who couldn't follow instructions to search for existing issues before opening new ones, or to provide all the answers the issue template asked for.
    - anuila 6y ago
      Open source is bad enough. When open source meets the general public you can enjoy a nice disaster cake.
      - londons_explore 6y ago
        A neat way to solve this is with a team of bug triag-ers. Get the developers to never look at a bug unless it has the "triaged' label. Then have trusted volunteers who read each bug, assist the bugreporters to get stack traces and whatever is necessary, dedup, and then finally apply the label. It's a good task for people who have some technical expertise but aren't yet confident to be submitting their own PR's.