Re: EIS CWS AllowedRelease/AllowedTaskTargets Problems

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


-- 
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to "[email protected]".
I use it for the OOo lists and only rarely read other mails sent to it.