With what Greg Troxel has said already, I say we just go for a GEOS 3.5.0 release and if people have issues, we'll fix and cut a GEOS 3.5.1.
So 3 PSC have voted - Paul gave his +1, I gave my +1, Strk -- as I recall, you said okay to a release, if I closed all the tickets. Paul is willing to do the release if you aren't. I'm going to take this - https://lists.osgeo.org/pipermail/geos-devel/2015-August/007208.html (as a +1 from you) Remaining PSC members - please speak now or forever hold your peace - https://trac.osgeo.org/geos/wiki/PSC Package maintainers please stand by to test. And let's get the show on the road! Thanks, Regina ---------------------- GREG's NOTE BELOW > On Tue, Aug 04, 2015 at 08:15:02AM -0400, Paragon Corporation wrote: >> > Did anyone respond to the call-for-testing on geos lists ? >> What call? People, especially package maintainers don't like testing stuff >> unless it's in an unchanging tar ball. > > Uhm, I though you sent a call for testing, evidently you didn't. > Would tagging an RC1 give packagers an unchanging tarball ? I actually did run tests, but I made my own tarball. I think I posted a note about it, but it seemed to build/run/check ok on NetBSD 6 i386. As a package maintainer, what I'd like for testing is a distfile that's just like what would be released, except with a different version. And of course it should unpack to a name consistent with the tarball and version. Basically the output of "make dist", and in cases where that really is how releases are generated, it's easy enough to do myself. The other big thing for packaging is that once a file is published with a version number, it can be withdrawn, but no file with the same name and different contents should be published. The reason is that packaging systems record checksums to guard against distfile partial fetches and tampering. So "fixing" a distfile is indistinguishable >From tampering. If that's needed, just increase the point version (e.g. 3.5.1) and people can update. Updating pain is proportional to structural changes and the amount of code that newly doesn't work with compilers, etc., plus about 3 minutes of constant time, so trivial fixes like this take only the few minutes. --------------------------------------------------------------------- _______________________________________________ geos-devel mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/geos-devel
