4 ms·

> and he might not have the inclination to accept patches from unvetted strangers. I keep seeing this implication, but it simply doesn't follow at all. Nobody

by ef4 12y ago

> and he might not have the inclination to accept patches from unvetted strangers. I keep seeing this implication, but it simply doesn't follow at all. Nobody said anything about letting everyone commit changes in a free-for-all.

deleted 12y ago
[deleted]
quesera 12y ago
True. I should have written "might not have the inclination to invite unvetted strangers into the development process". Having a relatively high bar for participation (email Wietse, courteously, and suggest some useful modifications, and offer to work on them) seems like a completely valid filter process to me. It takes a special kind of personality to be the public facing patch czar of a hugely popular open source project that runs everywhere with elevated privileges and firewall rules set to allow direct connections from anywhere. Perhaps Wietse has decided that's not the life he wants to live.
- ef4 12y ago
  Again, none of that is precluded by a read-only public VCS. The process of discussing changes and patches on the mailing list can still be identical if that's what they like. People seem to be equating "expose some VCS" with "run a github-style repo where anybody can stick pull requests into your queue". The two are not the same. It is entirely reasonable to ask an open source project to stop hiding useful information that they already have and could share at zero cost.
  - quesera 12y ago
    I disagree about the usefulness of seeing code in progress. The inter-release diffs aren't very large, typically. I read them all, carefully. Why would Wietse want to have a public conversation about unfinished work? He's not looking for help.
    - ef4 12y ago
      >The inter-release diffs aren't very large, typically. But they're much bigger than the individual commits, and so if something breaks in release X, I can ponder the whole diff or I can bisect the history and ponder a handful of lines.
agwa 12y ago
Since Wietse is wary of accepting patches from other people, publishing even a read-only version control repository does absolutely nothing for him. Instead it would only be a burden, not only because he might have to change his workflow, but also because it would invite patches from people who only know how to use version control and can't make it over the barrier of using tar, diff, and patch.
- ef4 12y ago
  Doesn't follow at all. There are open source projects that expose read-only VCS and still only accept patches via email. Postgres, for example.
  - agwa 12y ago
    The point is that public VCS doesn't benefit Wietse, and by extension Postfix, so why should he have one? A public VCS only benefits other people, most of whom aren't even contributing to Postfix development. Postgres is a different project and they no doubt see a different cost/benefit ratio for public VCS, probably because they have many more core developers and contributors than Postfix. I've actually had a patch accepted to Postfix and while I found it inconvenient not to use my usual VCS-based workflow, I also realized that the Postfix world revolves around Wietse, not me, and as a user of Postfix I benefit most when the project is optimized for him and not other people.
    - ef4 12y ago
      Let's rewrite this: "The point is that public VCS doesn't benefit Wietse, and by extension Postfix, so why should he have one? A public VCS only benefits other people, most of whom aren't even contributing to Postfix development." Like this: "The point is that publishing source tarballs doesn't benefit Wietse, and by extension Postfix, so why should he? Publishing the source only benefits other people, most of whom aren't even contributing to Postfix development." The answer to both question is "he doesn't have to, but if he takes seriously the goals of open source it would be silly not to." It's not unlike choosing to withhold your Makefiles, or documentation.

by ef4 12y ago

deleted 12y ago

[deleted]

quesera 12y ago

True. I should have written "might not have the inclination to invite unvetted strangers into the development process". Having a relatively high bar for participation (email Wietse, courteously, and suggest some useful modifications, and offer to work on them) seems like a completely valid filter process to me. It takes a special kind of personality to be the public facing patch czar of a hugely popular open source project that runs everywhere with elevated privileges and firewall rules set to allow direct connections from anywhere. Perhaps Wietse has decided that's not the life he wants to live.

ef4 12y ago
Again, none of that is precluded by a read-only public VCS. The process of discussing changes and patches on the mailing list can still be identical if that's what they like. People seem to be equating "expose some VCS" with "run a github-style repo where anybody can stick pull requests into your queue". The two are not the same. It is entirely reasonable to ask an open source project to stop hiding useful information that they already have and could share at zero cost.
- quesera 12y ago
  I disagree about the usefulness of seeing code in progress. The inter-release diffs aren't very large, typically. I read them all, carefully. Why would Wietse want to have a public conversation about unfinished work? He's not looking for help.
  - ef4 12y ago
    >The inter-release diffs aren't very large, typically. But they're much bigger than the individual commits, and so if something breaks in release X, I can ponder the whole diff or I can bisect the history and ponder a handful of lines.

agwa 12y ago

Since Wietse is wary of accepting patches from other people, publishing even a read-only version control repository does absolutely nothing for him. Instead it would only be a burden, not only because he might have to change his workflow, but also because it would invite patches from people who only know how to use version control and can't make it over the barrier of using tar, diff, and patch.

ef4 12y ago
Doesn't follow at all. There are open source projects that expose read-only VCS and still only accept patches via email. Postgres, for example.
- agwa 12y ago
  The point is that public VCS doesn't benefit Wietse, and by extension Postfix, so why should he have one? A public VCS only benefits other people, most of whom aren't even contributing to Postfix development. Postgres is a different project and they no doubt see a different cost/benefit ratio for public VCS, probably because they have many more core developers and contributors than Postfix. I've actually had a patch accepted to Postfix and while I found it inconvenient not to use my usual VCS-based workflow, I also realized that the Postfix world revolves around Wietse, not me, and as a user of Postfix I benefit most when the project is optimized for him and not other people.
  - ef4 12y ago
    Let's rewrite this: "The point is that public VCS doesn't benefit Wietse, and by extension Postfix, so why should he have one? A public VCS only benefits other people, most of whom aren't even contributing to Postfix development." Like this: "The point is that publishing source tarballs doesn't benefit Wietse, and by extension Postfix, so why should he? Publishing the source only benefits other people, most of whom aren't even contributing to Postfix development." The answer to both question is "he doesn't have to, but if he takes seriously the goals of open source it would be silly not to." It's not unlike choosing to withhold your Makefiles, or documentation.