23 Sep
2010
23 Sep
'10
2:37 p.m.
The root of this problem, and it's not one that can be dealt with in the
short term, is because we are treating trunk as basically the "stable"
branch for "stable" releases. Most mature projects have a separate branch
for every major release point where things are either known to work or known
to not work, and they concentrate mostly on bugfixes that do not add new
functionality or break existing ones or security patches. This lets them
break trunk as *needed* and as another major point release comes up, they
take some care to make sure trunk is at least in good enough shape to branch
to create the new release. We can't do this, since major lower level
components change too fast. This would be akin to us still be patching the
0.3.0 codebase, which would mean using the pre-rewrote kernel. And not
having sound. And who knows how many other nice things that have been added
so far. Thus for the short term, we're stuck with trunk acting as both the
point of development and release. Not an ideal situation.
Ged is actually right when he says we actually don't have a need to create
entire branches for a release, we could just tag and release. The only
thing stopping us is we add in some hacks to work around known issues, hacks
that we don't want leaking into trunk. That and we revert some random stuff
here and there that are actually correct but break other incorrect things.
Breaking things is pretty much unavoidable, even if completely unintended.
Which is probably why yarotows and other branches were created, since these
are efforts to add new functionality into ReactOS. That is always going to
bring risks. But we need that new functionality if we're to get to a point
where we can actually have a genuine "stable" branch instead of constantly
releasing off of trunk.
This basically boils down to, for now, get all the risky stuff in right
after a branch is made for release. That way we can see quickly what breaks
and not suddenly have to deal with locking of trunk right before release
because people waited to commit their work or we delayed doing a winesync
and Wine did something to break our code.
On Thu, Sep 23, 2010 at 5:40 AM, victor martinez <vicmarcal(a)hotmail.com>wrote;wrote:
From: gedmurphy(a)gmail.com
To: ros-dev(a)reactos.org
Date: Thu, 23 Sep 2010 08:09:57 +0100
Subject: Re: [ros-dev] 0.3.12 milestones status
victor Martinez wrote:
and
In the same way, and imho, I think it is much
better
to avoid sending critical code one month before the release.
This isn't how you release.
The whole point in branching for a release is so you can stabalise the
branch whilst trunk continues to be 'bleeding edge'
What's the point in branching otherwise? We may as well just tag trunk do away with branching.
I am not agree :) As far as i see we have tried to (more or less)stabilize
trunk before branching at least in the 2 latest releases. An i.e is the
0.3.12 release, if we are following the "bleeding edge" concept then we
should have branched several months ago and just pulled the regression fixes
from trunk to the branch. Our approach was different: Stabilizing trunk
fixing the known regressions (which,btw,were marked as Milestones) and then
branching.
There is not an incompatibility with the "stabilizing trunk" and
"branching" concepts. First because exists the "Hack-releases" (fixes
just
applied for the release) and that just can be done in a branch. Second
because a (more or less) stabilized trunk doesn't mean a regression-free
trunk (but it could be).
The first main advantage (about avoid sending critical code in the month we
are going to release) is that we will have a whole month to check if the
critical changes has waken up underlying bugs (or if the critical changes
has introduced Eisenbugs).If we are following the "bleeding edge" approach
we can just pray to find those Eisenbugs in the Release Candidate ISO tests
and, since there aren't a lot of testers checking the RC ISO, it is quite
unprovable.
The second main advantage is that we reduce the Release Engineers amount of
work. It is not the same bugging them to create just one RC ISO than bugging
them to create 2 or 3 because playing with the "bleeding edge" concept.
_______________________________________________
Ros-dev mailing list
Ros-dev(a)reactos.org
http://www.reactos.org/mailman/listinfo/ros-dev