On Sun, 2018-03-18 at 04:57 +0100, x...@freenetproject.org wrote: > 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. >
I am not abusing anything here... That's exactly the role of a RM to select/improve the code he picks for inclusion. If you can't stand criticism, don't submit PRs. If you are not happy with me closing your sub-par PRs, find a RM to re- open them and work with you... Playing the bullied special snowflake on the mailing list won't earn you any favour. > > 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. > I am not "teaching people to ignore its failures", I am complaining that Arne is fine with releasing code that doesn't even pass the CI tests. master and next are using different versions of BC and it's still unclear to me whether this is a real problem or not. Your PR fails at demonstrating anything. > > 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. > That's your opinion. You're not a RM, you don't get to make the calls related to what build system we support (or not). > > 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". > I am really trying to be polite here. The code you have submitted: 1) doesn't fix anything 2) doesn't do what you claim it does 3) obviously break things > > - 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 > Have you even read the contribution guidelines? It talks about the first line of the commit message, not using colons as a separator. > 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. So, it "fixes travis CI", by making the build process switch from the stage where "it builds successfully" to the stage where "it doesn't build anymore". That's your "fix"? > 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. > As I said, the problem most likely also affects master... and that doesn't prevent it from being shipped to users. > 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. > I have read it and none of it makes sense. You are doing more than one change at the time... the result "breaks the build" ... and you throw a tantrum repetitively (on the PR, on IRC, here) when I refuse to merge it. > > - 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. > Is https://travis-ci.org/freenet/fred/jobs/334276152#L643-L656 what you are talking about? That's a build-log from one of your commits! > > 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. You have no idea of what you are talking about. The Ant-based build- system has been broken for years with the built-in packaged version of ant shipped by Debian (with a matching version number). > 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? Are you sure you want me to unfold the argument and show how stupid that proposition is? The wrapper is there precisely to ensure that the version/flavour of gradle matches what we expect... and this is what you are messing with. > Either way, if you want someone to work on that please provide a > description > of the specific problem. > You are the one creating "problems" and "issues" here. As far as I am concerned, "next" builds (and Travis agrees)... > 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. > There is no binary you can't replace in the tree. If you don't trust the gradle wrapper we ship, you can overwrite it... but use the same version. gradle wrapper --gradle-version XXX > > 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. Answering any of your emails does feel like a total waste of time, yes... so is reviewing your PRs and looking through the myriad of tickets you touch on mantis. In fact I can't remember you contributing something useful to fred's core. NextGen$
signature.asc
Description: This is a digitally signed message part
