Re: [ros-dev] 0.3.12 milestones status

[victor martinez]

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

[Olaf Siejka]

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