[ros-dev] 0.3.12 milestones status

Aleksey Bragin aleksey at reactos.org
Thu Sep 23 16:09:21 UTC 2010

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.

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>

More information about the Ros-dev mailing list