forrest-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ross Gardler <>
Subject Re: [RT] "Last known working snapshot" of Forrest head
Date Tue, 03 Jan 2006 11:47:21 GMT
David Crossley wrote:
> This gets us back to the "always releaseable trunk" concept.
> See the "Project participation and hackability" threads
> (plural because it got broken)


> More below ...
> Ross Gardler wrote:


>>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.

Yes. But mistakes do happen, always releasable trunk is an aim, whereas 
an always usable snapshot is a requirement.

>>They would not go through the usual release process, perhaps have only a 
>>"./ 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.

The con is that we have multiple versions of Forrest in SVN, each quite 
large. Therefore we are using up storage. I suspect some people would 
frown upon such activity.

> Only the official releases go to the mirrors, i.e.
> the /dist/ directory of

Not a problem. The only people using the snapshots would be those 
wanting to work with an almost cutting edge version, I doubt there will 
be too many, and it won't be the link coming from the downloads page, it 
will be from a deeper page, like the development process page.

> seems to be where most
> projects make milestones and such available. We should
> investigate what the other projects do.

Good idea.

> is for the
> 6-hourly automated snapshots.

I'd propose dropping those snapshots in favour of the always usable 
ones. People wanting to be this close to the cutting edge should be on 
it and therefore using SVN head.

Furthermore, these are the whole development tree, rather than a built 
and ready to use binary. They are larger and require manual building (I 
know it is a single command, but people are complaining about that!)

>>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.

In conjunction with Jira where bug reports should be filed anyway. The 
worst workflow would be:

- user reports bug (via mail list)
- dev puts it in jira (complete with note that it affects thable snapshot)
- dev calls vote to roll back the stable snapshot
- community votes on a snapshot release
- svn is rolled back with reference to the bug in commit log so it gets 
logged against the issue automatically

The fixing of the bug is just a normal part of our development process, 
once it is closed we can vote on doing another release.

The best workflow would be:

- user reports bug via jira and attaches patch
- dev applies patch as normal
- community votes on a snapshot release
- new snapshot is created

Is there any other meta-data we need?

>>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.

Yes, coupled with select sites running on our forrest zone as continuous 
integration tests we should find ourselves becoming quite stable (of 
course we already are, but having a page saying test site XYZ is passing 
seems to be the only way to make people recognise it).



View raw message