I'd like to add that, in my opinion, we should not put too much
resources into preparing a release. All this hacking and masking bugs
away in a release branch is pointless: our releases aren't supposed
to be used in any kind of production environment, so it's meaningless
to make them appear more beautiful than they really are.
Releases bring a lot of good stuff, make the team disciplined, but
what I want to accent is that there is no "stable"/"unstable"
division right now. There will be one in future, but definitily not now.
WBR,
Aleksey Bragin.
On Sep 23, 2010, at 6:37 PM, Zachary Gorden wrote:
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:
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:
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 and
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.