Apache OpenOffice (AOO) Bugzilla – Issue 113866
EIS should have a target for cws (or at least it should be posssible to retarget all issues of a cws at once)
Last modified: 2013-03-29 00:46:48 UTC
There should be a "target" field for CWS on EIS. In should be set to a sensible default target for the MWS of the CWS by default. Whenever the target field of the CWS is changed, all added tasks of the cws will have their target updated. The comment to the issue tracker is: "EIS: Retargeting to $NEW_TARGET in cws $CWSNAME." rationale: Reliefs devs of errorprone manual target handling.
bei->b_michaelsen: so some developer by accident adds a task which currently has a target which does not fit to the default target of the masterworkspace of the CWS and we react on that not by giving the developer a hint that he/she might have been done something wrong and should have a look at what he/she was doing but react on it by automatically retargetting the issue without anyone having a look and a thougth or two about whether this is reasonable or not so how is that not errorprone? Well it might be less work for the developer but it is certainly not less errorprone.
@bei: if the issue is re-targeted then all subscribed users get a mail notification. surely somebody would notice the nonsensical target change and inquire why it was done. i consider this appropriate for the expected very rare occurrence of the problem.
There is absolutely nothing wrong with notifying the dev. Currently there is a terribly empty page with pretty much only a "Back"-Button diplayed after a task has been added. Feel free to use that screenspace for scary warnings on a red background when a suspicious retargeting has happened. But the process should be optimized for the default case and not the exceptional case that a dev adds an issue that he did not actually want to add.
bei->fma: Is there a chance that we might get some or all of the Oracle internal iBIS Task class functionally available also externally in order to implement something like this. I certainly would not want to reinvent the wheel of how to work with issues in a program if I don´t have too.
bei->b_michaelsen: By the way this does not get you out of the original dilema that let to this idea: the sensible default target can also only be maintained manually and if that was not done on time you will still also have to contact the maintainer. There is no way to guess a reasonable default and to automatically change it if any new target becomes available.
b_michaelsen->bei: Even if the default target would be badly maintained, keeping all targets of issues on a cws in sync is good and makes life a lot easier for developers (and thus less errorprone). Issues that are being integrated with one cws should never have different targets as cws are atomic. Because of our development model, the target is actually not a property of the issue, but of the cws. When a cws misses a release, _all_ issues change their target or the cws gets split -- and replaced by two new cws. So, being able to set all targets of issues at once not only makes life easier and less errorprone for the dev, it also keeps the data more consistent. Coming to think of it, I do not need to have the target stored on the cws (duplicate info is bad). But at least let us have a way to set the target of all added issues at once (and leaving those already on that target unchanged). This allows devs to make sure the targets are right or adjust them collectively without lots of annoying clicks.
bei->b_michaelsen: one problem though for developers at Oracle might be that there is not only the issuetracker at OpenOffice.org but there are also other internal bugtracking systems being used and target names do not always match between those bugtracking systems. So if a CWS has also internal Issues Issues that are being integrated with one cws can have different targets.
b_michaelsen->bei: Yes, I saw that too. However, that is another issue that needs to be fixed because it makes no sense at all. Fortunately, for this issue we do not need to take care of old targets that have already been passed -- we only need to make sure to keep at upcoming targets at sync. What keeps us from simply creating every target in the OOo issue tracker in the other bug trackers? I cant think of a use case for _not_ having every OOo target available in other trackers.
I don't really think that makes sense (what about targets like "extension release X.Y", which should not be changed at all?) ... Plus, I don't see the benefit. *After* a bug has been fixed, or maybe *after* the respective CWS has been integrated - what is the target on an issue good for? What information can you obtain from it? The release the bug fix went in? Well, that can be obtained from EIS (issue is part of a CWS => CWS has been integrated into release). Other than that? Don't know. Seriously, I think that a target expresses an intention where the bug fix should appear. After the bug fix manifested in a release, or even after it is in MWS, the target at the issue becomes rather meaningless. So, my gut feeling is that whoever uses the issue target in such a phase is simply evaluating the wrong data (feel free to prove me wrong on this). We should not support this by adding complex and error-prone extra functionality to EIS, but by providing a means to evaluate the proper data.
@fs: IMHO there is little worth in targets of issues that have not been started yet, as the environment is way to volatile to draw any conclusion from that. I see your point about targets being the wrong field to investigate for issues after integration. So this is more or less about the relative short timeframe between "started" and "resolved". Once an issue is started it will belong to one cws or another and all will be integrated with all other issues in that cws. Thus is target of the issue is the 'shortest' of all issues of the cws, and will be changed either for no or for all issues on a cws. Thus is should at least be possible to retarget all issues on a cws in one step. Updated summary accordingly.
EIS and cws no longer exist.