Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Wietse uses source control. He just doesn't open it up to the hoi polloi.

In the era before social coding (when postfix originated), this wasn't uncommon for open source projects. qmail and sendmail didn't have public VCS either.

Not everything has to be like everything else. Wietse is a dedicated, responsive, talented steward of his project. We don't need to see his WIP commits, and he might not have the inclination to accept patches from unvetted strangers.

I'm ok with letting him run it the way he thinks works best.



> 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.


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.


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.


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.


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.


Wietse obviously wants to benefit people who use Postfix, which is why he releases tarballs, Makefiles, and documentation, so people who want to use Postfix can get it, compile it, and learn how to use it. VCS does not further those goals, but instead benefits would-be developers (and an insignificant minority of users who aren't worth optimizing for).


A writeable open VCS would also make heartbleed-like vulnerabilities more likely. As such the OP's comments should be evaluated as potential astroturf. Were the NSA looking to introduce new and effective backdoors, and we know they are, this would be one way to pressure IBM/Weitse for access.


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.


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.


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.


>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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: