4 ms·

>the mailing list does not serve the function of email address discoverability in any form. Instead, the source is the source code itself, in which the target e

by jasode 6y ago

>the mailing list does not serve the function of email address discoverability in any form. Instead, the source is the source code itself, in which the target email addresses will be recorded ad nauseam. Not every project records email addresses in the source code. Yes, the project maintainers could do that, but some don't. I'm looking inside the latest "youtube-dl-2020.11.01.1.tar.gz" source archive and it does not have maintainers' email addresses in it. The main Python source code file "YoutubeDL.py" and other .py files do not have email addresses. The archive also has a text file "AUTHORS" for historical credits -- but no actual email addresses. I suppose the current maintainer could explicitly put his email address in that source, but he/she didn't. (Maybe there are good reasons to avoid putting an email address in the source code.) >To carve it out: You, as a holder of the source code, will always be able to send patches, ask questions, as well as start discussions that others will organically be added to, using no other sources of information than the source, irrespective of mailing list availability, as long as you can send email, and that at least one of the maintainers or contributors of the source can still receive email. Based on what you wrote, it seems you still have not fully internalized the difficulties of a Schelling Point for something like Youtube-dl. Even if "youtube-dl-2020.11.01.1.tar.gz" contained the actual email address of the current maintainer, if that maintainer decides to quit because of RIAA hassles and someone else (unknown to us because we can't predict identities of future authors) takes over and creates a new "youtube-dl-2021.03.15.1.tar.gz", the old "tar.gz" file does not point to the existence of the new file or new canonical location. The world still needs a Schelling Point so people know where to download the latest trusted non-malware version of Youtube-dl even if they don't know the identity of the new maintainer. You claim the "source" can be the starting point ex nihilo but you still need a trusted Schelling Point to obtain the source in the first place to enable the subsequent steps of private email correspondence that make a mailing list server irrelevant. How do people get the latest "youtube-dl-202x.xx.xx.x.tar.gz" without a Schelling Point?!? Your answer: start with the source code. My response: isn't that circular logic? I can only guess that you're using mental model of Linux kernel development. The problem with trying to transfer that collaboration workflow over to youtube-dl is the Linux project does not have adversaries like RIAA trying to kill it. Schelling Points are stable in that world of mainstream projects and seemingly trivial. E.g. just read the Linux kernel .h/.c file for email addresses.

iudqnolq 6y ago
Don't you have the email addresses in the gut commit history?
arghwhat 6y ago
> Not every project records email addresses in the source code. You have missed the point entirely. The email Git workflow is based around—you guessed it—git. Git, being designed entirely around email-based workflows, stores the email authors and committers of every commit (they often differ), and furthermore, often also marks the reviewers. This is fully automatic. If you are looking for email addresses, you either A) do not have the prerequisites for doing the work in the first place, or B) do not understand git. Any Git tree that has not been intentionally butchered will contain the email address of every single maintainer and contributor to ever have contributed to the project, and that is always the only thing you need when doing email workflows. (Linux stores more than that, for convenient official subsystem maintainer lookup—but focusing on the extra processes that a project that in 2019 alone had over 74k commits from 4k authors with over 5 million lines of code changes needs is a little silly when we're talking about comparatively tiny projects where git info is fine.) > How do people get the latest "youtube-dl-202x.xx.xx.x.tar.gz" without a Schelling Point?!? You are derailing significantly. If you have not yet figured out how to obtain a git tree, then you have clearly gotten ahead of yourself with most of your arguing. How can you be discussing how to create issues if you don't even know how to get the software in the first place to discover issues with? How do you even know of the software if you had not already found a place which could contain the starting point for your process? Nothing with relation to workflows and VCS has any important before you manage to get ahold of the software in the first place, whether that is on a website, forge, IPFS, USB dongle smuggled by a packer over a border, or whatever you'd like. The starting point, however, is nothing more than that. It serves no purpose once "recruitment" is complete, as you work on your machine-local repo from there. You may occasionally sync with other individuals trees, in what can be considered peer-to-peer transactions, but even that is mostly optional, and it can be done with any individual. You do not need full consensus in the tree. (The tarballs you refer to are not for development. They're only releases for end-users, which cannot be used to make patches from.) > I can only guess that you're using mental model of Linux kernel development. The development model are used for many other projects, including a handful of mine. If you think that there are no adversaries out to kill Linux, you'd be sorely mistaken, but it's moot as it has no single points of failure. Everyone works on their own trees, and send around patches, occasionally syncing in various directions. --- The fact that you have now assigned several disconnected components as focal points underlines the fact that there are, in fact, none. I have also come to the conclusion that you are not very familiar with neither git itself nor the email workflows it was developed to sustain. Granted, there will always be central individuals, in the form of the maintainers of the subtree you are contributing to (note: there can be any number of maintainers and subtrees for a given project). This is not due to infrastructure, but due to code changes losing meaning if arbitrary patches are applied in arbitrary order. But, there is no single point of failure and no single point of gathering. But, even then, they are not focal points. The various maintainers act as focal area of a particular subtree, but they are organic and redundant, and loss of one is is easily routed around as any holder of a tree can accept patches and act as a maintainer. And loss of one implies loss of an individual, not loss of a random hosting service.

by jasode 6y ago

iudqnolq 6y ago

Don't you have the email addresses in the gut commit history?

arghwhat 6y ago

> Not every project records email addresses in the source code. You have missed the point entirely. The email Git workflow is based around—you guessed it—git. Git, being designed entirely around email-based workflows, stores the email authors and committers of every commit (they often differ), and furthermore, often also marks the reviewers. This is fully automatic. If you are looking for email addresses, you either A) do not have the prerequisites for doing the work in the first place, or B) do not understand git. Any Git tree that has not been intentionally butchered will contain the email address of every single maintainer and contributor to ever have contributed to the project, and that is always the only thing you need when doing email workflows. (Linux stores more than that, for convenient official subsystem maintainer lookup—but focusing on the extra processes that a project that in 2019 alone had over 74k commits from 4k authors with over 5 million lines of code changes needs is a little silly when we're talking about comparatively tiny projects where git info is fine.) > How do people get the latest "youtube-dl-202x.xx.xx.x.tar.gz" without a Schelling Point?!? You are derailing significantly. If you have not yet figured out how to obtain a git tree, then you have clearly gotten ahead of yourself with most of your arguing. How can you be discussing how to create issues if you don't even know how to get the software in the first place to discover issues with? How do you even know of the software if you had not already found a place which could contain the starting point for your process? Nothing with relation to workflows and VCS has any important before you manage to get ahold of the software in the first place, whether that is on a website, forge, IPFS, USB dongle smuggled by a packer over a border, or whatever you'd like. The starting point, however, is nothing more than that. It serves no purpose once "recruitment" is complete, as you work on your machine-local repo from there. You may occasionally sync with other individuals trees, in what can be considered peer-to-peer transactions, but even that is mostly optional, and it can be done with any individual. You do not need full consensus in the tree. (The tarballs you refer to are not for development. They're only releases for end-users, which cannot be used to make patches from.) > I can only guess that you're using mental model of Linux kernel development. The development model are used for many other projects, including a handful of mine. If you think that there are no adversaries out to kill Linux, you'd be sorely mistaken, but it's moot as it has no single points of failure. Everyone works on their own trees, and send around patches, occasionally syncing in various directions. --- The fact that you have now assigned several disconnected components as focal points underlines the fact that there are, in fact, none. I have also come to the conclusion that you are not very familiar with neither git itself nor the email workflows it was developed to sustain. Granted, there will always be central individuals, in the form of the maintainers of the subtree you are contributing to (note: there can be any number of maintainers and subtrees for a given project). This is not due to infrastructure, but due to code changes losing meaning if arbitrary patches are applied in arbitrary order. But, there is no single point of failure and no single point of gathering. But, even then, they are not focal points. The various maintainers act as focal area of a particular subtree, but they are organic and redundant, and loss of one is is easily routed around as any holder of a tree can accept patches and act as a maintainer. And loss of one implies loss of an individual, not loss of a random hosting service.