On Wed, 2018-01-10 at 22:11 +0000, Matthew Toseland wrote: > On 10/01/18 21:51, Florent Daigniere wrote: > > On Wed, 2018-01-10 at 21:36 +0000, Matthew Toseland wrote: > > > On 10/01/18 21:15, Florent Daigniere wrote: > > > > On Wed, 2018-01-10 at 21:10 +0000, Matthew Toseland wrote: > > > > > So what is going on, and why? > > > > > > > > > > > > > > > > > > What's happening is that Arne is refusing to move forward... and > > > > keeps > > > > releasing off the old release tools and Ant. > > > > > > > > The rest of the team has been working on next (I've done most of > > > > the > > > > current gradle support, including deterministic builds, ... > > > > steve > > > > has > > > > been working on the release tools, ...) > > > > > > So you are checking the hashes of the downloaded components? > > > > > > I thought Gradle was just an evolution of Maven, with all the > > > problems > > > that implies: Recursively pulling random JAR files, with very > > > little > > > authentication, pay-for-only signature checking, and a guarantee > > > that > > > everyone who uploaded those JARs hasn't paid for that feature. In > > > other > > > words, malware galore. > > > > > > If that's the world that Gradle takes Freenet into, then I can > > > entirely > > > understand why Arne would have a problem with it. > > > > We do check the hashes of downloaded components... and produce > > reproducible jars by default. > > https://github.com/freenet/fred/blob/next/build.gradle#L227 > > > > Security is clearly not the concern here. > > Annoying that it can't easily work over Freenet... but not a serious > concern, any HTTP(S) fetches can easily go via Tor etc. >
I'm not sure I get what you mean here. We could configure a repository where the data would be fetched by fproxy (easy)... or extend gradle with a plugin that would talk FCP (harder but way easier than with ant/maven)... both solutions would work adequately and prioritize fetches over Freenet when a node is available. Anyways, you're talking about a feature we didn't have with the legacy build system here... > What about the deployment side of the question? > That's where little progress has been made (bare steve's work)... it is difficult to work on the toolset used exclusively by RMs without the acting RM's support. > I recall somebody arguing for getting rid of the installer and using > some third party packaging system instead? What is the status of that? > I don't think anyone has suggested to get rid of the installers... but I do recall mentioning that the future of the last-resort recovery mechanism (the current update\.(sh|cmd) ) ought to be https://github.com/steveatinfincia/fred-updater This could be platform-independent. Florent
signature.asc
Description: This is a digitally signed message part
