On Wed, Jul 28, 2010 at 09:43:13PM -0500, Hyrum K. Wright wrote: > On Wed, Jul 28, 2010 at 6:28 PM, Talden <tal...@gmail.com> wrote: > >> It looks like we might be fairly close to having on-disk formats > >> stabilized, and hence rolling alphas. Prereleases may be fairly > >> prolific, since I want to work the bugs out of the transition to ASF > >> distribution infrastructure, and get fixes into the hands of users > >> rapidly. > > > > I'm very interested in experimenting with the alphas. I have little > > time or interest in building subversion myself (last time I looked at > > that in ~1.3 days, getting the appropriate tools, dependencies and > > environment set up was like gnawing off my own leg) but I'd very much > > like to perform some scripted experiments using our corporate > > repository content (a copy of course) with 1.7 on Win32 and Win64. > > The project doesn't typically provide binaries, partly because there > are so many different combinations that it's hard to justify which > ones to build and which not too.
I don't think deciding what platforms to build for is a problem. The answer is simply "as many as we can". Past experience has shown that if we only provide source releases, then virtually nobody will test them. And that has resulted in several problems not being found before release. Interested readers might want to take a loot at this talk given at Subconf 2009 by Hyrum and myself: http://2009.subconf.de/fileadmin/PDF_Dateien/CMConf___SubConf/PDF_Vortraege/S._Sperling_und_H._K._Wright.pdf Because of the substantial changes done for 1.7, we will need pre-release testing more than ever. So doing source-only 1.7 preview releases would pose a major problem. We will have to actively push for pre-release testing by providing binaries. > However, providing binaries of these releases may be really useful, > especially for people in your position. I *really* hope that our > volunteer packagers chose to build binaries of these interim releases > (with the appropriate warnings, of course). It would also be nice if > third-parties (such as Tortoise) used these as part of their own beta > processes. I'll raise my hand. The Subversion project has much closer ties to various Linux distributions now than it had around the time of the 1.6 pre-release phase. This is partly due to efforts by elego -- we actively help out with the official Debian, Ubuntu, and OpenSUSE packages. I also maintain OpenBSD packages in my spare time for the few folks who need them because they are crazy^Wsensible enough to run OpenBSD. For the platforms mentioned above, I will try to push for 1.7 binaries during all phases of pre-release testing (alpha, beta, rc). To encourage wide testing, the plan is to make these available in conveniently installable form: - launchpad PPA archives for Ubuntu - special add-on repositories for Debian (possibly hosted at elego, unless we can find a better location somewhere Debian-related) - OpenSUSE build service RPM archives for OpenSUSE (Hyrum, it would be great if we could synchronise such that links to binary package archives for various systems become part of the pre-release announcements.) Obviously, the standard source-distribution pre-release disclaimer will apply to the pre-release binaries as well. They won't be pushed into the distribution's standard set of packages during pre-release phase. I hope others will join the effort and help provide binary packages for additional platforms (Windows comes to mind). And I hope that our users will take these efforts seriously, and test the 1.7 pre-releases on non-production data in near-production environments as much as possible. That would help everyone in this community (developers and users) a whole lot. But of course, even with a lot of testing, 1.7.0 likely won't be free of known issues. We'll always have to live with a certain amounts of bugs in every release, or we could never make a release. But we'll need an exhaustive list of known problems to base our prioritizations on. And wide testing will provide that. I hope this will work out well and benefit the project. If it does, we should consider doing the same for all future 1.x releases. Stefan