Bug 200767
| Summary: | [PATCH] games/pioneer: Update to 20150610 | ||
|---|---|---|---|
| Product: | Ports & Packages | Reporter: | lightside <lightside> |
| Component: | Individual Port(s) | Assignee: | Dmitry Marakasov <amdmi3> |
| Status: | Closed Not Accepted | ||
| Severity: | Affects Only Me | CC: | amdmi3 |
| Priority: | --- | ||
| Version: | Latest | ||
| Hardware: | Any | ||
| OS: | Any | ||
| Attachments: | |||
|
Description
lightside
2015-06-10 14:38:17 UTC
Created attachment 157618 [details]
The poudriere testport log (FreeBSD 10 amd64)
What is the purpose of DISTNAME change? (In reply to comment #2) > What is the purpose of DISTNAME change? The purpose is default DISTNAME, i.e. ${PORTNAME}-${DISTVERSIONFULL}, e.g. "pioneer-0.0.20150610". Instead of suggested by current USE_GITHUB: "pioneerspacesim-pioneer-0.0.20150610-20150610". Otherwise, this is just my personal preference, which was realised before new USE_GITHUB changes (based on different preferences of its developers for the ports, which they maintain). I didn't approve the changes of last committer (ports r386691, the cause of which is re-downloading of distfile(s) without any (acceptable) reason, other than exceeding its powers), therefore I proposed to correct these changes (with comment about it). I plan to remove this bit, as it serves no purpose. We have standard naming scheme for github distfiles and ports should stick to it, otherwise it's POLA violation and maintenance burden. Created attachment 157632 [details] Proposed patch (since 386691 revision) (In reply to comment #4) > I plan to remove this bit, as it serves no purpose. We have standard naming > scheme for github distfiles and ports should stick to it, otherwise it's POLA > violation and maintenance burden. Ok, then the only acceptable result of this is to release the maintainership of the port. I proposed the new version of the changes. Thanks. Created attachment 157633 [details]
Proposed patch (since 386691 revision)
Created attachment 157635 [details]
Proposed patch (since 386691 revision)
The distinfo file fixes.
It is not an acceptable result. As it had been told already, ports tree is not a place for personal preference: ports should be understandable and readable by other people. Do not be childish, I'm committing the original patch without DISTNAME bit with updated distinfo after some testing. Created attachment 157639 [details]
The poudriere testport log (FreeBSD 10 amd64)
(In reply to comment #8) > It is not an acceptable result. As it had been told already, ports tree is not > a place for personal preference: ports should be understandable and readable > by other people. Do not be childish, I'm committing the original patch without > DISTNAME bit with updated distinfo after some testing. Well, no need to underestimate my reasons. The distfile is the core of the port. I don't like spontaneous changes to default DISTNAME, which caused troubles already. You are not a cause of this. Thanks for your open explanation, which I comprehend already (from other places). The current version of the port is complete and doesn't require the maintainership, in my opinion. If ports managers (or other committers) will like to do other changes, they will free to do this without my attention (and acceptance). > Well, no need to underestimate my reasons. You just told it's based on personal preference. > The distfile is the core of the port. I don't like spontaneous changes to default DISTNAME, which caused troubles already. Not quite correct. With github, there is no real distfile in the first place and thus no upstream name for it, so we're not changing anything upstreamish as there's nothing to change. Instead, ports framework provides fool-proof and consistent naming scheme for github distfiles, and you're trying to spontaneously change /that/, which is, as explained, a bad idea. (In reply to comment #11) > Instead, ports framework provides fool-proof and consistent naming scheme for > github distfiles, and you're trying to spontaneously change /that/, which is, > as explained, a bad idea. I didn't start these changes, instead I returned what was before, in case of new version of the software, which was acceptable moment to do this. (In reply to comment #11) > You just told it's based on personal preference. Yes. And releasing of the maintainership is also based on my personal preference (and opinion). I'm not in position of the POLA violation. My first intention was to propose the workable port in the past, where it was acceptable to do this. Now, it's time to release the maintainership (to not cause other troubles, because of broken artificial rules). May be, I chose a not right moment to request releasing of the maintainership. Perhaps, someone might think, that I wanted something in exchange of the maintainership. This is not true. Personally, I thought about decision of releasing of maintainership before creation of PR. The reason is complicated and based on unsuccessful attempts to propose changes for USE_GITHUB. The time of replacing correct MASTER_SITES in favor of USE_GITHUB has come to this port (and even without my attention to this, as if I did something wrong and someone fixed it for me), therefore it was a right moment to release the maintainership from the port, where my main disagreement was a proposed DISTNAME changes. Now, I just request to release my maintainership from this port. If Dmitry Marakasov wants, he can get a maintainership of this port, because he is the right person who has an experience with it. I'm sorry, that I didn't propose this before creation of PR. The port is ok and there was a no need for such explanations. I think, there are no real reasons to forbid the usage of DISTNAME inside of the port, even because of new USE_GITHUB. For example, there are no collisions between distfiles, in case of default DISTNAME, which was used before (at least, for this port). I guess, there are possible artificial reasons, created in the process of the development of new USE_GITHUB:
1. Instead of waiting for new version of the software, which was a possible moment to convert the port from GH_COMMIT to GH_TAGNAME, or the (temporary) usage of DISTVERSIONSUFFIX for other cases, there was a decision, which ignored the maintainership of other people in favor of _GH* suffix (i.e. DISTNAME:=${DISTNAME}_GH0).
2. Almost at the same time, someone tried to propose new DISTNAME scheme in case of USE_GITHUB, result of which was a massive distinfo changes for the ports and possible re-downloading of distfiles for the same port versions.
If 1 is architectural decision, which was prepared for the possibility of GitHub changes for distfile contents. The 2 is just a suggestion about how DISTNAME for GitHub ports might look like (because of ?= assigment).
But some developers of new USE_GITHUB didn't stop on that. They created new policy for other ports, which may use distfiles from GitHub. And now, I in the process of reconsider about the trust in a whole ports framework infrastructure for the ports, which I maintain.
I know, that I may be wrong about my assumptions. The one line of DISTNAME do not cost so much attention to it. But something feels wrong, especially my public monologue/discussion about this.
Ok, let's close this PR. There is no need for public record in the SCM logs about it. Dmitry Marakasov, there are new changes in Git repository of the port, which may fix some issues, related to saved games. I plan to create a new PR with just an update and what you suggested for some new release Git tag. Thanks. |
