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 at hotmail.com> wrote:
>>> > From: gedmurphy at gmail.com>> > To: ros-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.reactos.org/pipermail/ros-dev/attachments/20100923/880acc0d/attachment-0001.htm>