[Moonlight-list] branches, betas, oh my
sebastien.pouliot at gmail.com
Wed Nov 11 08:23:56 EST 2009
On Tue, 2009-11-10 at 23:43 -0800, Chris Toshok wrote:
> I branched trunk for the moonlight-2.0 release tonight. Trunk is now
> open for 3.0 work, pixel shaders, pal work, video4linux work, etc.
> I also tagged from the 2.0 branch for beta 8 (1.99.8), which we'll
> hopefully get out the door tomorrow.
> Things are going to be a little more complicated wrt the beta with the
> number of branches to cherrypick between, but I think we're sitting ok
> for it and shouldn't need any fixes.
> From here on out all changes potentially targeted at 2.0 should first
> be checked into trunk. instead of passing diffs around via monobin or
> urls or pasting into irc, we can just refer to svn revisions. That way
> we can all see if the tests pass with a given revision (basically trunk
> becomes the try-server). We need to be real sticklers for what makes it
> into 2.0. At this point the default should be "no", unless there's a
> compelling reason to accept it, and only after many of us have taken a
> look at a given change. Verification/security fixes, as well as good
> performance fixes get pretty much a free pass to "compelling", but other
> feature/bug related things need a closer eye. No more rubber stamping
> reviews, please.
> The more complicated state of affairs for the beta would obviously
> require checking into 2 different locations on top of trunk, so let's
> just not put anything else in the beta :)
> the urls are:
> 2.0 branch: svn+ssh://mono-cvs.ximian.com/source/branches/moon/moon-2-0/
> 1.99.8 tag: svn+ssh://mono-cvs.ximian.com/source/branches/moon/1.99.8/
> I also think tomorrow we should move the bulk of the bots to running
> against the 2.0 branch, with a skeleton crew of bots on trunk.
* cherrypicking fixes from mono/mcs might be hard. Not sure people (like
Rodrigo) are looking forward to backport fixes (like the verifier) to
* do we move moon trunk now (or later) to mono/mcs trunk (2.7) ? I think
the right question is "will Mono 2.8 be stable before, or at the time,
we plan to release 3.0?". IMO better wait a bit to know the answer...
* if we stage all (well most since 2.0/3.0 incompatibilities obviously
are bad candidates) changes on trunk first then we need more bots
there (than the less used 2.0 branch)
* speaking of 2.0/3.0 incompatibilities, should we start fixing them now
or later ? It's gonna be hard (unless people use several VM) to have
both SL2 and SL3 running on Windows to compare results. Updating or not
SL will cause a different set of problems.
 another bad candidate are the changes to security attributes (and
audit data) since they need to be generated on the branch itself (not
copied over from a different code base)
More information about the Moonlight-list