I don't think the two of us should be discussing this any further, we can't manage to agree so we should wait for a third opinion to resolve the conflict.
This should also become our standard conflict resolution behavior in such issues. We waste too much time on arguing, and you're pushing your RM privileges very much by ignoring that we have more than one RM when you close things without reaching a consensus with the submitter. If you wait for a third person to provide an opinion the vote is always clear. For clarifying our misunderstandings and especially addressing your complaint about me naming you with your name an answer follows below anyway - but from my side you don't need to invest any of your time in replying to it. On Saturday, March 17, 2018 09:23:33 AM Florent Daigniere wrote: > 1) How is that different from what's on master? last time I've checked, > none of the CI builds have passed for the last few releases... and that > hasn't prevented releases from happening. > https://travis-ci.org/freenet/fred/branches What did you bother setting Travis CI for if you want to invalidate the work you've put into it by teaching people to ignore its failures by demanding that yourself in this discussion? Beyond that, previous failure to comply with best practices does not justify ignoring them forever. If that was done then all best practices would be ignored very quickly. > 2) Who said that we support ubuntu? The build target has always been > debian-stable. We have been talking about getting rid of JDK7 support > for a while and I don't have a problem with ignoring ubuntu's release > schedule. We'd not be doing ourselves a favor if we don't support the most popular flavor of Linux given that our privacy-focused target users are very likely to be using Linux. > 3) You still haven't demonstrated anything. Your pull request is garbage > and was rejected as such. You're not doing your level of education a favor by resorting to such "arguments" as "garbage". > - The title is misleading: > "Travis CI: Fix for OpenJDK 7 by not using wrapper; shows our own tests > fail on OpenJDK 7" > How the hell am I supposed not to assume it fixes "something"? If it > doesn't, why has it been submitted? Our commit guideline states that the context of a commit is what is before the colon in the commit subject: https://git.io/vxODd The PR was constituted by a single commit, hence the subject is identical. Thus the context is "Travis CI", and when it says "Fix" it thereby means that it fixes Travis CI. Travis was indeed not able to do its job of trying to produce a build on OpenJDK 7 before the PR, Gradle didn't work. It is able to try building with the PR. The job of a CI is explicitly also to prove failure of unit tests, so even if the tests fail now, the PR can still be considered to fix Travis. Beyond that, you're supposed to know what the PR does by not only reading the title but also reading the PR description text. If don't even have the time to at least read the description of something then don't call it "garbage" and throw it away. You're not qualified to judge things you haven't read completely. > - It doesn't do what you've explained above: it first changes the build > script not to use the gradle wrapper and THEN re-enables openjdk7. Sorry, I did consider the specific technical way how the PR manages to make Travis run the tests as too low level for discussing it on this mailing list. I thought whoever is interested could read the PR. > It fails at both proving that there is a problem and fixing it... Check again, the PR contains a link to the Travis build log of the failure it addresses. > but succeeds at removing determinism and breaking reproducible builds. The only thing it might change is the used Gradle version - by replacing usage of the hardcoded binary version of Gradle you put into the repository with usage of the Gradle which Travis CI has installed on their VMs. Gradle is the thing which is supposed to call the Java compiler, not the compiler itself. If your determinism code is affected by change of version of the thing which calls the compiler then perhaps the determinism code should be fixed to be independent of that? Either way, if you want someone to work on that please provide a description of the specific problem. Beyond that: I do accept your addition of the Gradle binary as a nice convenience method for allowing new developers to compile Freenet. Thanks for that. Still Git repositories are for source code, so they should work independent of specific binary versions. Sticking some arbitrary binary into the repository and saying it doesn't work with any other one is a good way of breeding unportable code. > 4) I don't call you by your first name, I would appreciate if you didn't > either... I don't know you. I address people on this mailing list with whatever name they have configured their mail client to use on it. Discussion on any public communication system is not possible if outsiders have to blindguess which nickname is associated with which actual name displayed by the system. As you are probably very well aware of the conventions on mailing lists it seems you're trying to grasp for any straw of an argument you can find. It would be nice if we could stop resorting to quarreling about boring human concepts such as the randomly generated strings aka names instead of seeking *technical* consensus. In a miniscule amount of years both your and my name likely won't be remembered by anyone. But if we don't screw up Freenet by wasting our time on such subjects it has a chance to still be known and used by then.
signature.asc
Description: This is a digitally signed message part.
