Official Postfix source code repository?

[Dāvis Mosāns]

I couldn't find Postfix source code repository, I saw only tarballs.
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 would suggest using Git, but any other would be fine too like Mercurial,
Bazaar or even Subversion. Also I would suggest using GitHub for code
hosting, but Bitbucket or Gitorious would also be fine, or you might host
it yourself on your own server (such as GitLab).

Is there any particular reason why there's no source code repository?

Thanks.

[l***@rhsoft.net]

disclaimer: i am not the author of postfix, only *my* opinion

Post by Dāvis Mosāns
I couldn't find Postfix source code repository, I saw only tarballs.
Source control (SCM/VCS) is a MUST have.

says who?

Post by Dāvis Mosāns
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

it is unbelieve that people coming new here and pissing around
in context of the best maintained and documented software

you are hardly in the position to say what muste be

Post by Dāvis Mosāns
Sending patches over email is what people did last century...

so what

Post by Dāvis Mosāns
I would suggest using Git, but any other would be fine too like
Mercurial, Bazaar or even Subversion. Also I would suggest
using GitHub for code hosting, but Bitbucket or Gitorious would
also be fine, or you might host it yourself
on your own server (such as GitLab).

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

Post by Dāvis Mosāns
Is there any particular reason why there's no source code repository?

there is one and if you would inform you before shout how postfix
is maintained and documented you would ask for access instead
coming in like an elephant and get access or a explaination
why the author prefers to keep it closed and only release tarballs

[Jim Reid]

Post by Dāvis Mosāns
I couldn't find Postfix source code repository, I saw only tarballs.
Source control (SCM/VCS) is a MUST have. It's unbelievable that people just
work with tarballs without proper source control.

It's unbelievable that 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. [Resistance is futile. Your code will be assimilated.] Has it not dawned on you that the reason something like git is not provided might be that it is simply the wrong tool for the job?

You are of course free to take the tarballs and feed them into the version control repository of your choice. That does not mean everyone else who works on postfix is obliged to work with whatever is your flavour of the month VCS. BTW, what contributions have you actually made to postfix?

Post by Dāvis Mosāns
It doesn't matter which you use, but it must be available.

Why? The author of postfix gets to choose/control how others commit code. Put simply, it's Wietse's ball and he decides who can play with it and what they are allowed to do with it. You don't. One of the reasons why postfix has remained in good shape for ~20 years is because well-intentioned but clueless people don't get to throw in features or or chase passing fads or ride their personal hobby-horses. The most successful (and vital) open source projects operate in this way too. That's not a coincidence.

It will be a very sad day when someone is obliged to use git or subversion or... to get access to open source software. For 99%+ of the users, 99%+ of the time, all that's needed is to download a tarball -- kids, ask your dad about FTP -- unpack it and run make. Anything else is unnecessary overkill. That lesson appears to be lost on the next generation.

Post by Dāvis Mosāns
Sending patches over email is what people did last century...

So what? It ain't broke and therefore doesn't need fixing. Especially by bloatware like git. Tools like that have their place -- projects with a cast of thousands perhaps (monkeys and typewriters spring to mind) -- but IMO postfix is not one of them.

[Viktor Dukhovni]

Post by Jim Reid
So what? It ain't broke and therefore doesn't need fixing.
Especially by bloatware like git.

While the OP is trolling, and will be booted from the list if
trolling persists, please don't take the bait and launch into a
crusade against your favourite heresy.

Wietse does not use git, but he may some day. Whether he does or
does not use git, signed tarballs will for the forseeable future
continue to be the primary means by which Postfix releases are made
available.

[Wietse Venema]

Post by Jim Reid

Post by Dāvis Mosāns
I couldn't find Postfix source code repository, I saw only tarballs.
Source control (SCM/VCS) is a MUST have. It's unbelievable that people just
work with tarballs without proper source control.

It's unbelievable that 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. [Resistance is futile. Your
code will be assimilated.]

Viktor keeps an unofficial GIT repository which is based on Postfix
releases and stuff that he works on himself. I expect that there
will be some public repository that is updated with each release,
but the public one would not be authoritative. And I would never
ever want to share any of my code before it is released.

Wietse

[Quanah Gibson-Mount]

--On Friday, April 18, 2014 5:51 PM +0000 Viktor Dukhovni

Post by Viktor Dukhovni
Wietse does not use git, but he may some day. Whether he does or
does not use git, signed tarballs will for the forseeable future
continue to be the primary means by which Postfix releases are made
available.

+1

I really detest the current trend of having no real releases and a lack of
tarballs from various source projects. While openldap has an entirely
public git repo, which is extremely useful for examinig discrete code
changes or gathering history, all official releases are and continue to be
done via tarballs. I.e., I think public source code repos can be extremely
useful tools, they are not a great way to push official releases of
software.

--Quanah


--

Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

[Quanah Gibson-Mount]

--On Friday, April 18, 2014 1:51 PM -0400 Wietse Venema

Post by Wietse Venema
Viktor keeps an unofficial GIT repository which is based on Postfix
releases and stuff that he works on himself. I expect that there
will be some public repository that is updated with each release,
but the public one would not be authoritative. And I would never
ever want to share any of my code before it is released.

As an aside, I would note that it is possible to do this with SCM systems.
I know Howard Chu maintains his own clone of the OpenLDAP source that he
works from, and then only pushes back into the public repo when he's
satisified with the results -- I.e., he only pushes what he feels is ready
to be available into the general code repo. It's also useful for testing
new strategies and features without affecting mainline.

--Quanah

--

Quanah Gibson-Mount
Architect - Server
Zimbra, Inc.
--------------------
Zimbra :: the leader in open source messaging and collaboration

[Viktor Dukhovni]

Post by Wietse Venema
Viktor keeps an unofficial GIT repository which is based on Postfix
releases and stuff that he works on himself.

Note, I do not promise a stable history for any of the development
branches. I squash commits at will, and delete branches once their
features are merged into an official release on the "master" branch
or the patch branch of an official release. (Thus the long-term
history includes only the official and snapshot releases, not
work-in-progress code).

My repository is useful for comparing past Postfix releases, enabling
one to quickly determine which Postfix release first added or
removed some block of code. It is also substantially more compact
than a separate copy of each of the ~1000 tarballs representing
each of the commits.

[Dāvis Mosāns]

I've nothing against tarballs and I'm not saying that there shouldn't be
tarballs. I'm also not saying that repository could work as release
distribution which it's not and I never said so. All I'm saying is that
there also should be a source code repository with full commit history so
that each code change could be reviewed. Tarballs only provide current
source code, but not changesets which are very important. It seems like
you're very ignorant and don't know what is right tool for right job. Do
you really expect for people diff over 100 tarball releases to find which
version introduced some bug or changed something on which you relied? Why
do you think I asked for repository? because I was intending to contribute.
Linux kernel uses git repository and that works perfectly fine.

Post by Jim Reid

Post by Dāvis Mosāns
I couldn't find Postfix source code repository, I saw only tarballs.
Source control (SCM/VCS) is a MUST have. It's unbelievable that people

just

Post by Dāvis Mosāns
work with tarballs without proper source control.

It's unbelievable that 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. [Resistance is futile. Your code will be
assimilated.] Has it not dawned on you that the reason something like git
is not provided might be that it is simply the wrong tool for the job?
You are of course free to take the tarballs and feed them into the version
control repository of your choice. That does not mean everyone else who
works on postfix is obliged to work with whatever is your flavour of the
month VCS. BTW, what contributions have you actually made to postfix?

Post by Dāvis Mosāns
It doesn't matter which you use, but it must be available.

Why? The author of postfix gets to choose/control how others commit code.
Put simply, it's Wietse's ball and he decides who can play with it and what
they are allowed to do with it. You don't. One of the reasons why postfix
has remained in good shape for ~20 years is because well-intentioned but
clueless people don't get to throw in features or or chase passing fads or
ride their personal hobby-horses. The most successful (and vital) open
source projects operate in this way too. That's not a coincidence.
It will be a very sad day when someone is obliged to use git or subversion
or... to get access to open source software. For 99%+ of the users, 99%+ of
the time, all that's needed is to download a tarball -- kids, ask your dad
about FTP -- unpack it and run make. Anything else is unnecessary overkill.
That lesson appears to be lost on the next generation.

Post by Dāvis Mosāns
Sending patches over email is what people did last century...

So what? It ain't broke and therefore doesn't need fixing. Especially by
bloatware like git. Tools like that have their place -- projects with a
cast of thousands perhaps (monkeys and typewriters spring to mind) -- but
IMO postfix is not one of them.

[Wietse Venema]

I'm closing this thread: take it off list or be removed. Postfix
is not the Linux kernel, and any comparison between the two is not
applicable.

Wietse

[Dāvis Mosāns]

That is exactly what I was looking for, just public read-only repository
for main/master branch. It looks like it's this
https://github.com/vdukhovni/postfix ? Only downside is that there's no
useful commit messages. So basically have to look at commit individually to
see what exactly was changed. At least blame works fine and can see which
version changed respective code line. Do you also accept PRs or only way is
patches in email?

And it's great that public repository is planned. Thanks.

Post by Viktor Dukhovni

Post by Wietse Venema
Viktor keeps an unofficial GIT repository which is based on Postfix
releases and stuff that he works on himself.

Note, I do not promise a stable history for any of the development
branches. I squash commits at will, and delete branches once their
features are merged into an official release on the "master" branch
or the patch branch of an official release. (Thus the long-term
history includes only the official and snapshot releases, not
work-in-progress code).
My repository is useful for comparing past Postfix releases, enabling
one to quickly determine which Postfix release first added or
removed some block of code. It is also substantially more compact
than a separate copy of each of the ~1000 tarballs representing
each of the commits.
--
Viktor.

[h***@gmail.com]

I just found out that commit history in https://github.com/vdukhovni/postfix (one commit for each Postfix version) and the corresponding changes in HISTORY file can be enough to trace changes and understand the motivation for them.

That is exactly what I was looking for, just public read-only repository for main/master branch. It looks like it's this https://github.com/vdukhovni/postfix ? Only downside is that there's no useful commit messages. So basically have to look at commit individually to see what exactly was changed. At least blame works fine and can see which version changed respective code line. Do you also accept PRs or only way is patches in email?
And it's great that public repository is planned. Thanks.

Post by Wietse Venema
Viktor keeps an unofficial GIT repository which is based on Postfix
releases and stuff that he works on himself.

Note, I do not promise a stable history for any of the development
branches.  I squash commits at will, and delete branches once their
features are merged into an official release on the "master" branch
or the patch branch of an official release.  (Thus the long-term
history includes only the official and snapshot releases, not
work-in-progress code).
My repository is useful for comparing past Postfix releases, enabling
one to quickly determine which Postfix release first added or
removed some block of code.  It is also substantially more compact
than a separate copy of each of the ~1000 tarballs representing
each of the commits.
--
        Viktor.
That is exactly what I was looking for, just public read-only repository for main/master branch. It looks like it's this https://github.com/vdukhovni/postfix ? Only downside is that there's no useful commit messages. So basically have to look at commit individually to see what exactly was changed. At least blame works fine and can see which version changed respective code line. Do you also accept PRs or only way is patches in email?
And it's great that public repository is planned. Thanks.

Post by Wietse Venema
Viktor keeps an unofficial GIT repository which is based on Postfix
releases and stuff that he works on himself.

Note, I do not promise a stable history for any of the development
branches.  I squash commits at will, and delete branches once their
features are merged into an official release on the "master" branch
or the patch branch of an official release.  (Thus the long-term
history includes only the official and snapshot releases, not
work-in-progress code).
My repository is useful for comparing past Postfix releases, enabling
one to quickly determine which Postfix release first added or
removed some block of code.  It is also substantially more compact
than a separate copy of each of the ~1000 tarballs representing
each of the commits.
--
        Viktor.

[Viktor Dukhovni]

Just feeding in tarballs into one's own repo makes incremental
building of one's own distribution somewhat impossible because
the only diff one every gets is from release to release.

Postfix snapshot releases and patch releases make incremental
improvements in a mature software system. If you're maintaining
private feature branches, instead of applying changes in Postfix
to your code, apply your changes to new Postfix releases.

Sorry, we do not support cherry-picking individual Postfix features.

Justifying the Postfix software release process is not a good use
of our time. It has worked much better than many a project with
a public SCM containing substantially lower quality code.

This thread remains closed on and off-list.