[RT] "Last known working snapshot" of Forrest head

[Ross Gardler <ro...@gardler.org>]

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.

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.

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.

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

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

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.

Ross

Re: [RT] "Last known working snapshot" of Forrest head

[Ross Gardler <rg...@apache.org>]

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)
> http://forrest.apache.org/guidelines.html#develop

Yes.

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

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 www.apache.org

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.

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

Good idea.

> http://svn.apache.org/snapshots/forrest/ 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).

Ross

Ross

Re: [RT] "Last known working snapshot" of Forrest head

[David Crossley <cr...@apache.org>]

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