Why did you not use the released tarball and switched to using a git archive? Unless there is a bug in the released tarball, it goes against our policy to always try and use the tarballs that project release.

In D13750#288014, @mat wrote:

Why did you not use the released tarball and switched to using a git archive? Unless there is a bug in the released tarball, it goes against our policy to always try and use the tarballs that project release.

It's easier to try some other revisions when it is using GH_xxx tags. I did this many times. I submitted patches to this project, and have pending patches too.

In D13750#288062, @yuri wrote:

In D13750#288014, @mat wrote:

Why did you not use the released tarball and switched to using a git archive? Unless there is a bug in the released tarball, it goes against our policy to always try and use the tarballs that project release.

It's easier to try some other revisions when it is using GH_xxx tags. I did this many times. I submitted patches to this project, and have pending patches too.

The point is that people put work in making releases tarballs, that just work, do not need autoreconf, and what you do when you ignore those releases is say "let's ignore the work they did and do it again myself in here". Like I said, unless the release tarball is broken, use it. If you want to keep a "devel" version of the port on your side, it's fine, but do not force using git archives when it is not needed.

In D13750#288077, @mat wrote:

In D13750#288062, @yuri wrote:

In D13750#288014, @mat wrote:

Why did you not use the released tarball and switched to using a git archive? Unless there is a bug in the released tarball, it goes against our policy to always try and use the tarballs that project release.

It's easier to try some other revisions when it is using GH_xxx tags. I did this many times. I submitted patches to this project, and have pending patches too.

The point is that people put work in making releases tarballs, that just work, do not need autoreconf, and what you do when you ignore those releases is say "let's ignore the work they did and do it again myself in here". Like I said, unless the release tarball is broken, use it. If you want to keep a "devel" version of the port on your side, it's fine, but do not force using git archives when it is not needed.

"people put work" - the work is mostly in making sure that the release is stable, tested, verified, went through the period of freeze. We got all this as it is now. The version is exactly the same. It uses autoreconf, but after autoreconf it is the same configure/makefiles.

In D13750#288087, @yuri wrote:

In D13750#288077, @mat wrote:

Like I said, unless the release tarball is broken, use it. If you want to keep a "devel" version of the port on your side, it's fine, but do not force using git archives when it is not needed.

"people put work" - the work is mostly in making sure that the release is stable, tested, verified, went through the period of freeze. We got all this as it is now. The version is exactly the same. It uses autoreconf, but after autoreconf it is the same configure/makefiles.

Yuri, @mat's comments weren't suggestions, they're policy. Once you're released from mentorship, you'll have more freedom to decide how to manage your own ports (though situations like this one won't change). While you're on mentorship, arguing against policy (especially when it comes directly from a member of portmgr) isn't appropriate.

Please, follow the instructions @mat is giving you. The point of mentorship is to learn how your mentors manage ports. You need to learn it their way first, and then you can develop your own way.

Could you verify whether the dependencies still are happy?

In D13750#289145, @tcberner wrote:

Could you verify whether the dependencies still are happy?

Nobody depends on it in the default configuration.
I verified, Tor likes it when the corresponding option is selected.
Also perftool's interface never changes.