Postfix has no public version control | Hacker News Reader

Postfix has no public version control

groups.google.com

I guess open source authors can work however they wish, but the sheer disdain displayed for good-but-differing practices is depressing.

So, now I'm a "kid" (with the obvious insinuation that I'm dumb and inexperienced) if I think maybe perhaps version control is a good idea, especially for open source projects that actually want contributions? Neat.

And git is "bloatware"? Is that guy running on a Commodore 64 or something? Bizarre.

If he is running on a Commodore 64 with todays products then damn I wanna see his setup :D

What would you do if someone shows up on your mailing list and demands that you change your decade-old workflow that works fine? Weitse and others replies are not inappropriate.

Some projects do not want contributors. It belongs to the maintainer. Knowing what not to put in is sometimes the best way to keep good code.

> Knowing what not to put in is sometimes the best way to keep good code.

What does that have to do with exposing a read only versioned history? Nobody is asking him to give the whole world commit privileges.

There is an existing, available source of read only versioned history, available online for anyone to see:

ftp://ftp.porcupine.org/mirrors/postfix-release/index.html

It's tarballs for each release, with associated patches for each release. That's a pretty complete read only versioned history.

Why does it have to be a VCS?

Because that history is way too coarse to answer the kind of questions that a VCS can answer.

And because they already have a VCS, and are just stubbornly unwilling to share all that useful information with the wider community.

What questions do you need to answer at a finer level of granularity? Is it really critical to know that someone fixed a typo in something day over day, but that the typo wasn't included in any releases?

I get that this clashes with the culture you're used to working in, but I don't see where it's actually impactful in a real world sense.

edit: a slight rewording

I search through other people's commit histories all the time. Commit logs are by far the most thorough documentation you'll find in the typical codebase. Not for the big things that appear in changelogs, but for the little things like "why the heck does this line work that way?"

Giving Weitse the benefit of the doubt, his commit logs are probably very useful indeed, and not sharing them makes the codebase that much less useful to everyone else.

Edit to add: the canonical example is bisection. When something breaks, it is awesome to bisect it down to the precise change that broke it. Bisection lets you narrow the scope down to a vastly smaller problem space than a whole release would.

How are you going to view the diff between more than two temporally adjacent commits? Or find the commit upon which an arbitrary line of source code was added? Or x, or y, or z reasons that are so painfully easy to enumerate?

I feel many people in here don't actually read the entire post. It mentions several times that there is a VCS. It even gives a link: https://github.com/vdukhovni/postfix

If they don't want contributors then why take patches via email? (Unless that bit wasn't actually true)

I understood it as: They don't want the low barrier to entry that "one-click let me hack this in the browser" a la Github enables.* E.g. they are not actively seeking to increase the number of contributors.

(*) Which is awesome for many/most projects. But there a valid reasons not to want it.

The first poster in that thread was just asking for trouble, bringing that know-it-all attitude.

> So, now I'm a "kid" (with the obvious insinuation that I'm dumb and inexperienced) if I think maybe perhaps version control is a good idea

You're misreading the thread. The specific comment was:

> kids these days see every software development/maintenance task as something that must get crushed under a git-shaped sledgehammer regardless of whether that's the reasonable or sensible thing to do.

which is seems more like a knock against git and possibly the culture around sites like github, than against version control per se. One person in the thread does say that the author uses VCS, but doesn't make it public.

The contributors to the project seem happy with the current setup and workflow, and frankly the guy who was looking for a public repository was kind of a dick about it.

sheer disdain displayed for good-but-differing practices is depressing.

Funny you should criticize the postfix community for this. Did you see what they are responding to?

Source control (SCM/VCS) is a MUST have. It's unbelievable that people just work with tarballs without proper source control. It doesn't matter which you use, but it must be available. Sending patches over email is what people did last century...

I think the "kids these days" comment was in reference to someone waltzing in, contributing nothing, and demanding everything immediately be done their way.

Contribution is not a prerequisite for criticism. Deserved criticism, in this case.

VCS is being used, so the criticism is unfounded:

"i would suggest that you ask questions first or be quiet the postfix author is using a VCS but he do not need to provide access to you or me "

Anyone can criticise anything for any reason.

Criticism is so easy to generate that it is worth absolutely nothing.

The process they use works for them.

I guarantee that I could come into your place of work and criticise pretty much everything you do, pointing out that there is a better way of doing it (because there will be, from some angle).

This is not useful, and whether or not I am correct on any specific point it is unlikely to be well received.

If you can come into my place of work and find out that we don't have backups, we're not hashing customer passwords, everyone is sharing a single user account, or we don't lock the doors at night, please do criticize.

Rejecting widely accepted good/necessary practice like that for no apparent reason other than "it's working for us so far" is stupid, arrogant, irresponsible, and wrong.

In this case, however, the criticism is unfounded because Postfix is using source control internally. Whether the system is exposed to the public is inconsequential as long as it's being used.

There is no way you can spin it as anything even remotely close to okay if there was no change tracking in the Postfix project at all.

It's absolutely useful and it's telling that you think it is not.

Open source, closed VCS.

That was never appropriate.

"You MUST" isn't criticism, it's a demand.

This is Postfix, which is older than some of you here on HN. Possibly the OP studied it when he was at college. Bearing that in mind, the tone of that email shows a total lack of respect. Write the email, fine, but word it in a manner that gives the Postfix devs the benefit of the doubt.

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.

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.

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.

It seems like the very old projects are very set in their ways (unsurprisingly). I complained about ImageMagick's process a while ago to no avail: http://www.imagemagick.org/discourse-server/viewtopic.php?f=...

Is using Subversion really so bad?

Until pretty recently tools like git, hg, bzr didn't exist. Now one of those is looking abandoned in its own right.

Switching repos and tools isn't trivial, and really if the tool is free software and works across common OSs, I really don't see the problem. DVCS doesn't have to work for everyone.

No, using subversion isn't that bad. It's the rest of ImageMagick's workflow that was bad. SVN was just the cherry on top.

Now that I have used git for a while, SVN makes me want to throw things. It's a turd. Whether you use git for dvcs or simple local versioning, it is all-around better. Unless you're just done learning new things. I understand that some people are done learning new things.

I think your criticism of svn is off the mark. But I agree that the work flow that you listed there is terrible.

Which is one of the reasons why http://www.graphicsmagick.org was started. You should check it out if you haven't already. Almost identical commands, much healthier dev environment.

While your frustration is understandable, when approaching a new open source project, it seems like it might help to be a bit more tactful and understanding.

Disclaimer: I am a primary maintainer for a couple open source projects and I contribute to a few others for 10+ years now. And I've seen quite a few email threads similar to this one :)

1) If you don't like how postfix is run then feel free to use other tools, fork it, or start your own project. This is open source and you have the power to do it better. If you are indeed right then your project will be successful. Put the money (effort) where you mouth is.

2) You can politely suggest something but you will get a much better traction if you first establish your reputation among people who work on this project by contributing code, documentation, whatever or even simply answering the questions in the mailing list (after about a year it gets really boring since questions are always the same).

3) (IMHO) There is no silver bullet. Git (or any other tool) will not make your code/project better. Moreover you might find that Git (or any other tool) is not perfect and there are problems with it in a particular environment (hint: there is no free lunch). Recognizing the tradeoffs is a very important skill for a software developer. Learn it early and you'll make less mistakes.

Having worked with CVS, Perforce, subversion, bzr, mercurial, and git, in distributed teams, as a sole developer and in large local teams for over 20 years, I can't think of a single plausible situation in which git is not superior in every way to all the other version control systems.

Git is a tool, and it's certainly not going to be a 'flip a switch and everything is better'. It does require that you define how you're going to use it in your particular context, but the only tradeoff I can see with git is learning it. It's interface and naming is an absolute horror show of usability, but its no worse that something like regular expressions or vim/emacs. But once it's in place, you have change management calculus, and everything else was algebra at best.

I understand the frustration of people who are used to having the benefits of open history in addition to open source. And who don't want to step back 10 years and learn dead end technologies, and who aren't used to being confronted with ivory towerism or gatekeeperism.

Otoh, I also understand why a maintainer would want to keep their codebases close to their chest, when they've achieved expert level finesse in a project/codebase, and the noob hordes with their ill-conceived ideas demand responses to their pull requests because they spent their free time writing some crap, and demand you spend your free time educating them on why their patch is a tub full of fail.

I've replied to another comment - there are scenarios when Git is not the best choice (imho) :)

Said that I am using Git for pretty much everything right now simply because it is "good enough" and I am lazy to switch between tools.

I can't think of a single plausible situation in which git is not superior in every way to all the other version control systems.

I don't want to get into an emacs/vi style flamewar but other VCSs have their own advantages, and are better in some situations:

- I prefer SVNs handling of trees/subtrees. I can checkout and work on one small part of a large project.

- Fossil has ticketing and wiki out of the box. It is easier to set up a server and enables true distributed offline working.

- Mercurial is easier to use for the most frequent use cases.

Git's submodules and git-subtree are definitely clumsy to work with, but you can always use sparse checkout if you want to work on a small part of a large project.

Ticket handling/wiki aren't really version control features. Decoupling those features from your VCS allows you to select the one that works best for your situation.

Mercurial is easier to learn for the most frequent use cases, and its interface make a lot more sense. No argument there. But like I said earlier, once you do learn it, its no more difficult to use, follows the same paradigms, but really allows for the edge cases to shine.

Note that I'm not disagreeing with you, but I can't see where using a DVCS like Git could be a negative?

IMHO, for a single commiter use-case DVCS add an un-necessary level of complexity. I use Git for my personal projects simply because I am lazy to switch between different tools. And even for multiple contributors, Git is not ideal. For example, the "single" source tree version doesn't allow parallel check-ins in different parts of the code. I've seen a 50+ developers project with an active trunk where Git was a blocker because it was hard to push your code because of other people pushes. For example, SVN is much better in this regard and allows commits as long as it is not in the same files. Yes, one can split the big project into sub-projects, etc. but sometimes it is not really possible.

"I've seen a 50+ developers project with an active trunk where Git was a blocker because it was hard to push your code because of other people pushes"

That's a clear misunderstanding of how to use git. The whole idea of having a single source tree is unnecessarily limiting - everybody works in their own branches, pushes to a origin/github remote, and when their work is gtg for the trunk, they, in their branch do a git pull --rebase, or alternately do a `git fetch; git rebase origin/master`. If they haven't touched any files that other people have touched, it just moves their branch point off of the current tip of origin/master, and they can merge their changes into master and push.

The only time it should be hard to push code is if both people made changes to the same file, and realistically, the same lines of a file. Then you get a merge conflict which is awesome, because it's made you aware that what you're working on and what somebody else is working on may be overlapping.

People can run their own projects how they want. But this is not just a question of preference -- an open source project developed this way is strictly less useful than one that exposes its true fine-grained history.

They quite literally throw away (or keep locked up, which is the same for us non-insiders) information that is relevant to understanding and debugging the project.

The only reason for that is misplaced vanity.

Note that nobody is asking to see your code before you're ready. You still get to choose when to push that fancy new release to the public repository. And nobody is asking you for write access.

It is pretty off-putting to me that such a critical piece of infrastructure isn't developed completely in the open, especially with such a large amount of security code. Companies get criticized all the time for this style of open source development.

It's not like the postfix code is hidden, or even difficult to find. Nothing is being done in secret here.

If you want to work on a new feature that'll take a long time and require several people, grab the code, stick it in git, and work on it with your team. Once the work is done, send a patch to the postfix maintainer, and he'll merge it if it's worthwhile.

Linus created git because the above workflow was killing him trying to handle the patches for the Linux kernel. He was doing it almost exactly as described above for a long time. I suspect postfix sees a far lower volume, and the above workflow probably works just fine.

You still can audit the code for security purposes pretty easily using the tarballs if you were so inclined. While granular commits (of the sort you see with public repos) are useful, they are by no means necessary for this sort of thing.

Someone did a github mirror: https://github.com/vdukhovni/postfix

Their worklflow seems to be:

    * Make a change
    * Write the meaning of the change in the HISTORY file
    * Release a tarball of the source with the change

Here is the HISTORY file: https://github.com/vdukhovni/postfix/blob/master/postfix/HIS...

That "someone" is, Viktor, one of the Postfix developers (who commented in the linked thread).

Thanks, I googled his name and looked at his Github profile but couldn't find if he was a Postfix developer or not.

Postfix (1998) predates Git (2005) by 7 years. That isn't to say that a VCS of some kind wouldn't have its benefits, but it's completely up to the author's decision.

So does Linux...

Well, except that git was created for Linux by its creator, Torvalds. It still was the author's (Torvalds) decision to use a VCS. But no need to fall into the troll. The author of the original thread is obviously clueless.

edit: fixed 2 pretty big typos.

Say "Torvald" one more time.

Keep in mid the story is a bit more complicated than than - Linus/Linux was using Bitkeeper, until their free license to all kernel devs and interested parties went away - _then_ Linus wrote git.

The need/usefulness of version control was orthogonal to (and preceded) the decision to write his own (d)vcs.

(Edit: misrememebred the actual vcs, originally posted Mercurial instead od Bitkeeper - http://en.wikipedia.org/wiki/BitKeeper#History )

Absolutely.

Here's the link to "A short History of Git": http://git-scm.com/book/en/Getting-Started-A-Short-History-o...

Even Linux only started using VCS in 1998. It was only tarballs maintained by Linus and e-mailed patches before then.

Rebel Code (http://books.google.com/books/about/Rebel_Code.html?id=kIU1s...) does a pretty good job summing up how Linux migrated from tarball source releases to BitKeeper (and eventually, of course, git). It appears that Steve Weber also writes on this, in a format that may be easier to read. (http://books.google.com/books?id=78SLSiWqy14C&pg=PA117&lpg=P...). The e-mails sent at the time around this make this thread seem, well, pretty friendly, actually. (http://lkml.iu.edu/hypermail/linux/kernel/9809.3/0493.html)

To the Postfix maintainers' point, Linus appears to have had quite reasonable reasons for maintaining the changes himself in the years up to then. Only when the number of active contributors got large (I suspect significantly larger than Postfix's) did this model break down. It's not the best for everyone, but I'm really glad they're maintaining a great open source product. The early 2000s in particular were not an easy time for MTAs.

The OP states that they do not care about the particular VCS, just that there is a public repo. Someone else responds that there is a private repo (without specifying a particular VCS). The crux of the matter here is public vs private and lump-sum version level changes vs something more granular.

I'm seeing a lot of misinformation in the thread about what public source control entails. Scary!

Care to enlighten us, or shall I just guess at what you're talking about?

I just read a thread about a bunch of grumpy software traditionalists who are probably close to my age, but the similarity stops there.

I have been working with software for over 20 years and I still think git is the coolest thing to hit development teams since dynamic languages.

I read somewhere that postfix is used by around 30% of the internets to send mail. That's really concerning because we have no history for the code, just a code drop. Given the amount of criticism for projects like android (which does have a public git repo but is also a code drop), I posted this here as I was wondering what people thought of such projects.

These days I think of free software to have a public version control as a given. So coming across this was a shocker for me. I think Wietse is free to do whatever he wants but it's just sad that we have to depend on this software so much :(

There's plenty of history:

ftp://ftp.reverse.net/pub/postfix/official/

Additionally, the history is mirrored on all the continents except Australia, http://www.postfix.org/download.html

Sure, there's no commit history for every change, but there's release notes for every version. What is the use case for knowing what intermediate things may have been available to some small group prior to release?

> What is the use case for knowing what intermediate things may have been available to some small group prior to release?

It's a use case that actually comes up a lot.

"This line looks funny, why does it do that?"

Go read the commit log and see why it was last touched.

I find and fix bugs in open source things I depend on all the time using this method. Or just as importantly, I realize my own understanding was mistaken and the author had a good reason for what they did, so I don't go asking stupid questions on a mailing list.

Given small releases, patches available, and a very detailed history file - what's the problem? It's enormously easy to construct a repository in your favorite VCS from that information. There's more than one way to keep a detailed history and just because they only have tarball releases doesn't mean it's a "code dump".

Not to say that their process is perfect and I'd chose the same process. But pretending like their process is highly problematic and we should be concerned for the future of the web because you can't run `git log` the moment you have the code seems a little over-dramatic.

Is there something like Postfix, except it has useful features that work out of the box without a lot of extra configuration that is hard to figure out? So I could actually send/receive encrypted email that would pass big provider's filters consistently without needing to use a mail API?

There must be some similar projects to Postfix that are written in modern programming languages and do use source control etc.

Being an MTA is a big complex thing, so it has a big complex configuration.

Postfix's configuration isn't bad compared to Sendmail. You might try exim instead, it's also well regarded.

I'm guessing if you use a distribution package of postfix to get a basic configuration, and follow the TLS documentation [1], you'll end up mail that's encrypted in transit (which I'm guessing is what you mean by encrypted mail). Make sure you have a relatively clean IP (not on any blacklists), and that forward and reverse dns match, setup SPF, DKIM, and DMARC, and you should be good. Do be sure you're not an open relay, cause you'll be found and abused (but I'm pretty sure most distro configs should start you off without being an open relay)

[1] http://www.postfix.org/TLS_README.html

He uses source control; he just doesn't have a _public_ one. So what?

Reply on news.ycombinator.com