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
Trunk lock is in my opinion a critical tool and shouldn't be abused. Ged is right, as it deters developers and hampers development process. On the other hand, Ged, this measure would not be necessary, if only bugfixing would be given at least the same priority as working on new features. Sadly, we all know how does it look like... Another critical issue, is... lack of dedicated testers. Our numbers are way smaller than the one of active developers, what also is hampering proper testing/bug handling. We barely have resources to upkeep all three major virtualising machines, not to mention the real hardware. Finally, please excuse my harsh words, developers ignore work of third party. We have more than a handful, waiting in bugzilla, with majority at least undecided, many unassigned, and many of those assigned - unreviewed. One random example - patch reported almost six months ago, assigned - over a month ago, still not even commented or acked by reviewer. How do we want to attract new developers, if we treat them like that?? Please excuse me Fireball, ARWINSS might be a good idea to attract new devs, but on the dark side of this project, we are making gross mistakes on things that are really very simple to succeed. We crave for resources we need, but at the same time we let them slip by, just because those are from individuals and not big corp, showering with money.
Best regards
-
Olaf Siejka -
victor martinez