Mailing-List: contact dev-help@forrest.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@forrest.apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Date: Tue, 3 Jan 2006 14:05:12 +1100
From: David Crossley <crossley@apache.org>
To: dev@forrest.apache.org
Subject: Re: [RT] "Last known working snapshot" of Forrest head
Message-ID: <20060103030512.GC13473@igg.indexgeo.com.au>
References: <43B86CC6.4060106@gardler.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <43B86CC6.4060106@gardler.org>
User-Agent: Mutt/1.4i

This gets us back to the "always releaseable trunk" concept.
See the "Project participation and hackability" threads
(plural because it got broken)
http://forrest.apache.org/guidelines.html#develop

More below ...

Ross Gardler wrote:
> This idea came to me earlier today when I was fixing my parent-in-laws 
> PC. Good old plug and play had resulted in the "blue screen of death" on 
> bootup. The PC automatically rebooted and came up with a console with 
> various boot options.
> 
> One of which was "boot with last known working configuration" - wo I 
> tried it.
> 
> I nearly fell off my chair when it worked and the PC was back in the 
> state of trying to do the plug and play installation.
> 
> Now this is hardly rocket science, but it's a brilliant idea.

Yeah, i try to do it here. I have a forrest-trunk-stable
working copy of our trunk SVN, and a text file to record
date, revision number, milestone (e.g. before-cocoon-upgrade).
Hard to keep it up-to-date.

> Then, when I came home I discover that the ongoing discussions on Infra 
> had resulted in the suggestion of them using a snapshot version of 
> Forrest to prevent them from having to build from an SVN branch (they 
> use the 0.7 branch).
> 
> A couple of weeks ago Johannes was asking if his commits to the 0.7 
> branch would make it through to a distribution server so he could point 
> his users at it.
> 
> What do people think about providing a "last known working snapshot" of 
> our 0.7 branch and of trunk. Users wanting to use a "not quite cutting 
> edge" version of Forrest could use these snapshots.

If we did the "always releaseable trunk" then we would
not need to have the snapshots for the branch. In fact
we would not even need a "release branch". A "release"
is just a special snapshot.

> They would not go through the usual release process, perhaps have only a 
> "./build.sh test". There would be big warnings on the download page to 
> the effect of "Whilst we endeavour to ensure these snapshots will run, 
> users should be aware that they have not gone our usual Quality Control 
> checks for a release. Use at your own risk."
> 
> The snapshots would be stored in SVN so that external projects could use 
> "svn:external" to include Forrest in their SVN downloads so that users 
> need not install a separate project in order to build local docs.

Not sure about the idea of storing snapshots in SVN.
Sounds good because easy to roll back and your externals
idea. Looking for cons, but cannot see any yet.

Only the official releases go to the mirrors, i.e.
the /dist/ directory of www.apache.org

http://svn.apache.org/dist/ seems to be where most
projects make milestones and such available. We should
investigate what the other projects do.

http://svn.apache.org/snapshots/forrest/ is for the
6-hourly automated snapshots.

> If we have a mjor problem reported by a user, simply roll back the 
> snapshot release to a previous version.

We need to track the metadata. Would the svn log suffice?
I wonder if "svn tags" are useful in this situation.

> We can use our forrestbot to build various test sites and only allow a 
> snapshot when they pass (in fact David has already set this up).

Very basic UNIX shell script.

> Any committer could create a snapshot at any time with a simple majority 
> vote. However, they would only be encouraged when there is a significant 
> bug fix or new feature.
> 
> I think that this would also make the testing of releases more through 
> since some people will have been using the release build for a while 
> without having to actively particpiate in the test process.

That would be a huge benefit.

-David