7 ms·

Postfix has no public version control

OedipusRex 12y ago
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 12y ago
  So does Linux...
  - gouggoug 12y ago
    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.
    - brokenparser 12y ago
      Say "Torvald" one more time.
      - deleted 12y ago
        [deleted]
    - bigiain 12y ago
      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 12y ago
        Absolutely. Here's the link to "A short History of Git": http://git-scm.com/book/en/Getting-Started-A-Short-History-of-Git http://git-scm.com/book/en/Getting-Started-A-Short-History-o...
  - hblanks 12y ago
    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=kIU1scm4w6QC 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=PA117&dq=linux+vger+fork&source=bl&ots=-fXPLKcZ0g&sig=upmLnbpLkZ_BtPvwHXydSJzWRcQ&hl=en&sa=X&ei=zimdU7PJBYf8oASQ9IDIDA&ved=0CE4Q6AEwBg#v=onepage&q=linux%20vger%20fork&f=false 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 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.
- jevinskie 12y ago
  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.
jeremymcanally 12y ago
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.
- hhsnopek 12y ago
  If he is running on a Commodore 64 with todays products then damn I wanna see his setup :D
- sdkmvx 12y ago
  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 12y ago
    > 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 12y ago
      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 12y ago
        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.
Sir_Cmpwn 12y ago
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=19&t=25185 http://www.imagemagick.org/discourse-server/viewtopic.php?f=...
- mattl 12y ago
  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 12y ago
    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.
  - spacemanmatt 12y ago
    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.
- general_failure 12y ago
  I think your criticism of svn is off the mark. But I agree that the work flow that you listed there is terrible.
- pudquick 12y ago
  Which is one of the reasons why http://www.graphicsmagick.org http://www.graphicsmagick.org was started. You should check it out if you haven't already. Almost identical commands, much healthier dev environment.
- mmagin 12y ago
worrieddot 12y ago
I'm seeing a lot of misinformation in the thread about what public source control entails. Scary!
- boie0025 12y ago
  Care to enlighten us, or shall I just guess at what you're talking about?
spullara 12y ago
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 12y ago
  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.
- shadowfox 12y ago
  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.
quesera 12y ago
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 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.
general_failure 12y ago
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 12y ago
  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 12y ago
    > 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.
- jkrems 12y ago
  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.
ef4 12y ago
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.
Dorian-Marie 12y ago
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/HISTORY https://github.com/vdukhovni/postfix/blob/master/postfix/HIS...
- jlgaddis 12y ago
  That "someone" is, Viktor, one of the Postfix developers (who commented in the linked thread).
  - Dorian-Marie 12y ago
    Thanks, I googled his name and looked at his Github profile but couldn't find if he was a Postfix developer or not.
lsh123 12y ago
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 12y ago
  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.
thrillscience 12y ago
He uses source control; he just doesn't have a _public_ one. So what?
templeos2 12y ago
You're confused. You are the loser. I am the winner. The winner dictates terms. http://www.templeos.org/Wb/Doc/Demands.html http://www.templeos.org/Wb/Doc/Demands.html
spacemanmatt 12y ago
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.
ilaksh 12y ago
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 12y ago
  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

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 12y ago
So does Linux...
- gouggoug 12y ago
  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.
  - brokenparser 12y ago
    Say "Torvald" one more time.
    - deleted 12y ago
      [deleted]
  - bigiain 12y ago
    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 12y ago
      Absolutely. Here's the link to "A short History of Git": http://git-scm.com/book/en/Getting-Started-A-Short-History-of-Git http://git-scm.com/book/en/Getting-Started-A-Short-History-o...
- hblanks 12y ago
  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=kIU1scm4w6QC 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=PA117&dq=linux+vger+fork&source=bl&ots=-fXPLKcZ0g&sig=upmLnbpLkZ_BtPvwHXydSJzWRcQ&hl=en&sa=X&ei=zimdU7PJBYf8oASQ9IDIDA&ved=0CE4Q6AEwBg#v=onepage&q=linux%20vger%20fork&f=false 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 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.
jevinskie 12y ago
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.

jeremymcanally 12y ago

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.

hhsnopek 12y ago
If he is running on a Commodore 64 with todays products then damn I wanna see his setup :D
sdkmvx 12y ago
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 12y ago
  > 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 12y ago
    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 12y ago
      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.

Sir_Cmpwn 12y ago

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

mattl 12y ago
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 12y ago
  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.
- spacemanmatt 12y ago
  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.
general_failure 12y ago
I think your criticism of svn is off the mark. But I agree that the work flow that you listed there is terrible.
pudquick 12y ago
Which is one of the reasons why http://www.graphicsmagick.org http://www.graphicsmagick.org was started. You should check it out if you haven't already. Almost identical commands, much healthier dev environment.
mmagin 12y ago

worrieddot 12y ago

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

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

spullara 12y ago

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 12y ago
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.
shadowfox 12y ago
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.

quesera 12y ago

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

general_failure 12y ago

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 12y ago
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 12y ago
  > 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.
jkrems 12y ago
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.

ef4 12y ago

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.

Dorian-Marie 12y ago

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/HISTORY https://github.com/vdukhovni/postfix/blob/master/postfix/HIS...

jlgaddis 12y ago
That "someone" is, Viktor, one of the Postfix developers (who commented in the linked thread).
- Dorian-Marie 12y ago
  Thanks, I googled his name and looked at his Github profile but couldn't find if he was a Postfix developer or not.

lsh123 12y ago

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 12y ago
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.

thrillscience 12y ago

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

templeos2 12y ago

You're confused. You are the loser. I am the winner. The winner dictates terms. http://www.templeos.org/Wb/Doc/Demands.html http://www.templeos.org/Wb/Doc/Demands.html

spacemanmatt 12y ago

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.

ilaksh 12y ago

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 12y ago
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