On Thu, Jul 29, 2010 at 4:59 AM, Stefan Sperling <stsp_at_elego.de> wrote:
> On Wed, Jul 28, 2010 at 09:43:13PM -0500, Hyrum K. Wright wrote:
>> On Wed, Jul 28, 2010 at 6:28 PM, Talden <talden_at_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:
I'll also plug my paper about what went wrong in the 1.5 release
process. This is what we're trying to avoid:
> 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
> 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
I'm happy to help coordinate the release announcements. I would warn
folks that I expect the pre-release series to be fast and furious, and
I'd like not to wait around for binary packagers. So please monitor
dev@, and work hard to build your packages quickly after the
pre-releases are posted for signing (so they may be released in
conjunction with the source distribution).
> 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.
Yep. At some point, I'd like to give the "Managing Releases" section
of HACKING, depending on the outcome of this exercise.
Received on 2010-07-29 15:16:35 CEST