Re: [TWiki-Dev] bugs lifecycle

[Kenneth L. <ke...@la...>]

I'll try to wrap things up.

1. I really do not want to approve all bug fixes going into Patch04x01. 
It may be the right thing to do but in an open source project I simply 
cannot commit to a constant work load that this requires. And I am sure 
noone else can either. The problem is especially that you cannot be away 
for a few days without having lost the overview. So instead we need to 
agree on a simple set of rules for what goes into Patch04x01.

2. The simple rule is - only well tested bug fixes goes into Patch 
branch. No enhancements! No code-refactorings. No risks. Doc fixes are 
always OK. No check-ins to Patch04x01 without having run both unit and 
TestCases web tests.

3. Anything you do goes into MAIN. MAIN is for bug fixes, enhancements 
etc etc following the same release process we used for 4.1.0. And here 
it is not a release manager that rules but the bi-weekly release 
meetings and with the 14-day acceptance rule if noone argues against a 
proposal.

4. Patch release checkins after 4.1.2 should be rare and only for the 
urgent bugs. It is impossible to keep two parallel branches alive and 
parallel check-in everything. When 4.1 is stable only very urgent fixes 
and security fixes should be merged in. Like I did with the 4.0.3-4.0.5. 
Each release there had round 5-10 fixes per release and that is not a 
bug deal to handle. But I guess we had more bugs in 4.1.0 than expected 
and this fact is something we need to analyse further how to avoid in 
Freetown. MAIN is our primary branch that drives the development. Patch 
branches are for patches and should have very short life cycle.

5. We have a practical thing to fix in bugs with patch fixes that arrive 
just before a release - and that the RM decides are too risky to take in 
and defer to next PATCH RELEASE. How do we queue them up? Maybe you 
Crawford can propose an enhancement to bugs for this. Until we have this 
the best is to set them to Waiting for Feedback from me. But 4.1.1 is 
out now so just check in the bug fixes that should to go into 4.1.2 both 
in Patch04x01 and MAIN.

6. For Freetown we need someone to volunteer to be customer advocate. We 
need to be 3-4 people in that role. You do not need any programming 
skills to take that role. I would even say that it is a qualification 
not to have programming skills. The role is to keep an eye on the Codev 
topics with proposals for features and spec changes and make sure that 
if there are voices of concern raised and the Codev topic does not reach 
consensus then the proposal is taken to a release meeting to be voted for.

I'll be happy to be one of them but we should be 3-4 sharing this. And I 
encourage some non-core developers to step forward. If we are 3-4 people 
it only takes a few hours per week for each of us and we can be away for 
a week or two without feeling bad about it.

Kenneth


Crawford Currie wrote:
> Kenneth Lavrsen wrote:
>   
>> The work load imposed by people setting to waiting for feedback is OK if 
>> it is only when in doubt that you have to ask. It should be the 
>> exception and not the rule that you ask the release manager for 
>> permission. Except maybe a time window of say 48 hours before a release.
>>
>> We should be in the situation that only 2-3 items are ever in this state 
>> so no special search should be needed.
>>   
>>     
> Hmmm. My concern with using this last release as an example was that we
> only dealt with bugs, and most of those were minor. I personally think
> it's important to have a consistent managed process in place so that we
> don't end up with code being merged to a patch branch that brings in
> unwanted enhancements.
>   
>> The waiting for release was used and worked well. The bugs were put in 
>> closed right after I had built the release. Jason kindly offered to do that.
>>   
>>     
> That's good. So "Waiting for Release" is effectively listing the
> contents of the next patch.
>   
>> We have effectively only TWO active branches. Bugs right now has major, 
>> minor, patch. In reality we do not need to seperate major and minor.
>>   
>>     
> OK, so we actually have two "pending release" states. One says "the
> issue is fixed and is waiting for authorisation to release"
> (TargetRelease=major, minor). The other says "the fix has been
> authorised and is in the build branch for the next release"
> (TargetRelease=patch).
>
> It might be clearer to rename these states.
>   
>> When there are several weeks till next patch release we have no problem. 
>> People just check in.
>>   
>>     
> This is fine for bugfixes, be we have to consider enhancements as well,
> which are constantly going on. As I said I prefer to have a process that
> dictates consistent handling for *all* classes of change.
>
> I don't want to impose a burden on you, though I am nervous that we seem
> to have revolved around to the same situation we had with
> TWikiRelease04x00 and DEVELOP. We abandoned that approach because
> DEVELOP branch wasn't getting updated. There is IMHO a real risk that
> the same happens again, especially when occasional contributors check in
> without reading the doc first.
>
> However at the end of the day, that end of the lifecycle is yours, and
> if you prefer to work this way I'm not going to try and force an
> unwelcome change on you. I just find it very disorienting, myself.
>
> Regards,
>
> C.
>
>