Re: EIS CWS AllowedRelease/AllowedTaskTargets Problems

On 23.06.2010 00:13, Mathias Bauer wrote:
> On 22.06.2010 14:49, Bernd Eilers wrote:
>> Mathias Bauer wrote:
>>> Hi,
>>>
>>
>> Hi,
>>
>>> the "right solution" would be to remove the check. A target milestone
>>> is a hint when a particular should be fixed or is planned to be fixed.
>>> The same is true for a CWS. If a developers decided to fix an issue
>>> earlier or finish a CWS earlier, why should that be marked as "failed"?
>>
>> Because the data of the issue doesn´t match the data of the CWS and we
>> have an inconsistent state in the tools that document what we are doing.
>>
>> Where is the point of not wanting to also change the issue data if the
>> decision when to fix the issue did change. Why do you want to refuse to
>> document that by changing the issue data.
>>
>> The "failed" status in this case is just a "hint" to the developer that
>> there are issues on his CWS which either need to be fixed on another CWS
>> which is based on another codeline or which need to be adjusted to be
>> fixed on another target which might eventually also need an agreement
>> about that with other stakeholders involved.
>>
>>> That's exactly what Stephan said: bureaucratic humbug.
>>>
>>
>> Well I know we do have some members in an
>> implement_as_you_want_when_you_want_and_dont_care_about_qa-needs_roadmaps_or_documentation 
>>
>> camp but I didn´t really expect you two to be in there ;-)
>
> That's complete nonsense. Setting a target to an issue or CWS can be 
> done short before or even after a CWS is integrated. If you ever had 
> to change the targets of issues or CWS just because you had set them 
> to the "allowed" target but then - when the CWS did not make it into 
> the release - had to change it again, you might understand why I think 
> that is bureaucratic humbug. The target release of an issue or CWS 
> *before* it gets integrated is unrelated to what is documented or even 
> to what exactly ends in the release. In a "train model" you never know 
> the time of arrival exactly before the train really arrives. So a 
> "target release" is just a declaration of what is aimed for, nothing 
> else. Why else are we retargetting so much issues each and every release?
>
 From my experience from the 10 past years we should only set the target 
milestone when the code actually get integrated. From my point of view 
we should only set target milestones for regression issues and stoppers 
only. Nevertheless I think a cws should only be integrated if all issues 
have the right milestone set, so that we can track with Issuezilla what 
actually got into the release. Making this random will lead that the 
target milestone will randomly set. I will set the nomination right 
anyhow for 3.4 for release management only, so these people will be the 
only one to fight their bureaucratic humbug theirself :-).

Martin

> Ciao,
> Mathias
>