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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tools.openoffice.org
For additional commands, e-mail: dev-h...@tools.openoffice.org
