From: gedmurphy@gmail.com To: ros-dev@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.
victor Martinez wrote:
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.
This is because trunk has been in a mess for the past few releases. Due to its instability it wasn't worth branching it as it was so far from being releasable.
In the past we had (strived for) a 2 month release cycle. We branched every 2 months no matter what and then worked on getting that release out. This is how linux and most other serious open source projects work. It's all about discipline.
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).
This is exactly what it's for. Branch, fix bugs or hack bugs away. Merge real bug fixes back into trunk, tag and release.
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
This is the ongoing job of the testers to do both in trunk and more importantly, in release branch. If any serious bugs are found late in the process, drop the branch, fix in trunk and rebranch.
The second main advantage is that we reduce the Release Engineers amount
of work.
But you hamper development. Locking down trunk for a month before every release is a sure way to drive away all of your developers. I would refuse to work on a project which worked in this way, as would most other devs I assume.
If you're finding when release time comes that no devs work on fixing the release branch and instead continue adding new code to trunk, then you have a developer discipline issue not a release process issue. Locking trunk is just a way to work around your developer discipline problem instead of tackling the real problem, your devs can't be bothered to fix existing code and continue to ignore their duties and add new code instead.
Ged.
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@hotmail.comwrote:
From: gedmurphy@gmail.com
To: ros-dev@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.
Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
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@hotmail.com wrote:
From: gedmurphy@gmail.com
To: ros-dev@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.
Right. It's that lack of division that causes quite a few of the situations that leads to trunk locking. And I'm not advocating for one right now. But there is a divide between how some people view trunk. Some view it more as a stable repo, others more as an unstable. Causes all sorts of complications when those two viewpoints crash into each other. Such as that little debate above.
-
Aleksey Bragin -
Ged Murphy -
victor martinez -
Zachary Gorden