
Postfix has no public version control - general_failure
https://groups.google.com/forum/#!topic/mailing.postfix.users/6Kkel3J_nv4
======
jeremymcanally
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.

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

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

~~~
meepmorp
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?

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

~~~
meepmorp
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

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

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

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

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

~~~
agwa
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).

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

------
Sir_Cmpwn
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=...](http://www.imagemagick.org/discourse-
server/viewtopic.php?f=19&t=25185)

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

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

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

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

~~~
papaf
_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.

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

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

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

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

------
Dorian-Marie
Someone did a github mirror:
[https://github.com/vdukhovni/postfix](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...](https://github.com/vdukhovni/postfix/blob/master/postfix/HISTORY)

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

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

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

~~~
codezero
So does Linux...

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

~~~
bigiain
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](http://en.wikipedia.org/wiki/BitKeeper#History)
)

~~~
gouggoug
Absolutely.

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

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

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

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

------
general_failure
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 :(

~~~
toast0
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](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?

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

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

~~~
toast0
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](http://www.postfix.org/TLS_README.html)

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

