[cosmo-dev] steps to push new cosmo release out

[Jared Rhine]

> There have been a few bugs fixed, mostly ones seen on during hub  
> usage, and some security fixes, so its seems worthwhile to push out  
> a cosmo 0.12 release, which would be a bug fix only release, no new  
> features, no schema changes.

I haven't reviewed trunk changes since 0.11 yet; we definitely don't  
have any feature changes?

Trunk includes the standalone-WAR changes, which I haven't tested but  
I think trunk currently builds in "Hub style" (confirmable via the  
lab.osaf.us tool).

> In the past, we would branch the trunk  and spin a release candidate  
> from the branch.

Not exactly; we'd branch trunk, yeah, but would verify the results  
before a release candidate is cut.  I think we should continue that as  
it's lighter-weight.

> That candidate would be tested by verifying any bugs fixed in the  
> release, running any automated tests, and holding irc qa sessions,  
> before being certified for release.

Yup.  The automated tests include unit tests, protocol tests, windmill  
tests at least.  I feel like I'm forgetting one.  We might wind up  
relying on Travis to run the windmill tests if we do that in house, as  
currently-most-knowledgable there.

Bear, what's the current status of windmill tests performed by tbox?

As part of validation, Adam would watch the windmill tests run to see  
if anything weird happened, and also doing a manual run-through of  
currently-not-working windmill targets like IE6.  I doubt Adam's up  
for that anymore, so we either need to replace that whole round of  
work or reduce the number of windmill runs that we watch.

If Mikeal declines to run the protocol tests, we might need to have a  
volunteer learn how to run those.  I'd be up for running and  
maintaining what we have in that area.  I forget if tbox runs those,  
either.

> We no longer have qa resources, so what steps should we take to  
> verify the code is ready for release?

The collaborative sessions seem to be one of our best test procedures  
and it makes sense to focus on that (beyond automated tests).

We could consider branching 0.12 from 0.11 and applying specific  
patches if we want a fast release and are concerned about any large  
changes.  Branching from trunk would be more conventional and if there  
are no specific patches to flag as risky, seems the best route.

> I know in the past all testing was done on lab.osaf.us, which is  
> setup exactly like hub.  I need to figure out how to update the  
> server with a build.

I've passed Randy some additional info offline about how we kick off  
such test instances.

-- Jared