> > 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.


"About discipline" and about having a lot of developers which can cover all the needs a project has. ;)
And let me not talk about some "serious open source pojects" with tons developers/users which has introduced and released with critical regressions.


 

 
> > 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.


Sure, I was just answering to your "What's the point in branching otherwise?" which seemed to be a question about an incompatibility with "avoiding critical commits" and "stabilizing trunk" before branching.
 

 
> > 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.


Just 2 words: Im-possible. :) You need a testing time frame. 
There is something called "Probability" of finding a regression(even more  finding an eisenbug). If you branch right after a critical commit and that critical commit has introduced a regression you have much less "Probability" to find it that if the last critical commit was made 1 month ago.
Even more, Release Candidates are mainly just tested by the Testers. So finding the regression depends mainly on "Probability Testers find a regression in one week"
But during that Quarantine month other commits (non critical ones) can be sent and developers can feel/find regressions too. So finding the regressions would depend mainly on "Probability Testers and Devs find a regression in one month". Notice that the testing group is wider and so the time.


We don't have Testing manpower to find a regression the next day/week it was commited.


 


> > 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.
 
Who talked about freezing trunk? I should define 1-month Quarantine better: "Avoid commiting to critical areas. The trunk is open for those non-critical ones. You can send meanwhile your critical patches to a branch and after the release pushing them to trunk.". You have a ReactOS branch if needed. 
 

> 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.


If we pay our developers we can ask for discipline meanwhile we  can just accept their patches or refuse them. 

Will you refuse a Patch? Or maybe revoke a Dev commit access to create discipline? Any useful ideas?


> 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.


Noone talked about Locking Trunk, and there are no duties. IIRC you were the first person that explained me why there are no dutie$ in this project. 



> Ged.



Vic