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?
Ciao,
Mathias
--
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
