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=9434OpenOnly=falseSection=All).
-Stephan
-
To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org
For additional commands, e-mail: dev-h...@tools.openoffice.org
-
To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org
For additional commands, e-mail: dev-h...@tools.openoffice.org
--
Mathias Bauer (mba) - Project Lead OpenOffice.org Writer
OpenOffice.org Engineering at Sun: http://blogs.sun.com/GullFOSS
Please don't reply to nospamfor...@gmx.de.
I use it for the OOo lists and only rarely read other mails sent to it.
-
To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org
For additional commands, e-mail: dev-h...@tools.openoffice.org
