Re: EIS CWS AllowedRelease/AllowedTaskTargets Problems

Hi,

from my POV it's OK to go with the check as it is OK for me to remove 
it. In any case, the tooling team is not in a position to simply decide 
to remove it. It you would like to see the check removed, please contact 
the Program Managers, who had requested this feature.

Regards,

Jörg


Mathias Bauer schrieb:
> 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"? That's 
> exactly what Stephan said: bureaucratic humbug.
> 
> The check for "all tasks fixed" is another story. It makes sense to 
> check that before a CWS is waiting for QA approval.
> 
> Regards,
> Mathias
> 
> On 21.06.2010 12:00, Bernd Eilers wrote:
>>
>> Hi there!
>>
>> I think the real root cause is that the definitions of what can be done
>> on which codeline is currently often not done early enough. As soon as a
>> new target is being created for the bugtracking system the corresponding
>> rules should be configured in EIS also. If that would be the case we
>> wouldn´t have any annoyance either. If that doesn´t work somebody just
>> has to complain to the group of people which have been assigned to do
>> these administrative tasks and that is "program management".
>>
>> Doing such test only when the cws is being set to "ready for QA" just
>> because some developers don´t like to see the color red is IMHO not the
>> right solution. On the contrary I would argue that maybe even setting
>> the CWS to "ready for QA" shouldn´t be allowed at all if there are tasks
>> with the wrong target.
>>
>>
>> Kind regards,
>> Bernd Eilers
>>
>>
>> Mathias Bauer wrote:
>>> Hi,
>>>
>>> ACK.
>>>
>>> If we think that we need that bullshit, the status should at least not
>>> be set to "failed" before the CWS is ready for QA. That still would be
>>> bureaucratic humbug (because both fields are that per se), but at
>>> least some humbug that is less annoying.
>>>
>>> Regards,
>>> Mathias
>>>
>>> On 18.06.2010 12:06, Stephan Bergmann wrote:
>>>> What a heap of bureaucratic humbug.
>>>>
>>>> -Stephan
>>>>
>>>> On 06/18/10 11:43, Bernd Eilers wrote:
>>>>>
>>>>> Hi Stephan!
>>>>>
>>>>> There is no "error" in EIS, EIS behaves just as it was instructed to
>>>>> do.
>>>>>
>>>>> If you click on the "Details" link you will find the following
>>>>> information:
>>>>> ------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>> The release of this ChildWorkspace is OOo 3.4 . The release of the CWS
>>>>> is invalid.
>>>>>
>>>>> The allowed Releases for the MasterWorkspace of this CWS are: OOo 3.1
>>>>> , OOo 3.2 , OOo 3.1.1 , OOo 3.3 , OOo 3.2.1
>>>>>
>>>>> The List of allowed Releases for MasterWorkspaces is being maintained
>>>>> by program management.
>>>>> ------------------------------------------------------------------------- 
>>>>>
>>>>>
>>>>>
>>>>> This all basically means that if you think OOo 3.4 should be in the
>>>>> list for that MasterWorkspace but isn´t ask your friendly program
>>>>> manager next door to add it.
>>>>>
>>>>> Kind regards,
>>>>> Bernd Eilers
>>>>>
>>>>>
>>>>> Stephan Bergmann wrote:
>>>>>> For a CWS based on DEV300 with release set to OOo 3.4 and all
>>>>>> associated tasks having target OOo 3.4, AllowedRelease and
>>>>>> AllowedTaskTargets erroneously are both set to failed (e.g., see
>>>>>> <http://eis.services.openoffice.org/EIS2/cws.ShowCWS?Id=9434&OpenOnly=false&Section=All>). 
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> -Stephan
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: [email protected]
>>>> For additional commands, e-mail: [email protected]
>>>>
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [email protected]
>> For additional commands, e-mail: [email protected]
>>
> 
>