[TYPO3-core] Issue handling

[Ernesto Baschny [cron IT]]

Alexander Opitz schrieb am 10.05.2013 12:36:

>> It's the version where the reporter found it. Many reports are filed by
>> someone who has only one version available to test. They find something
>> and set the TYPO3 version to indicate where *they* found it.
>> It can exist in earlier or later versions. That's for testers or devs to
>> find out. It can be added in a comment that it was also found in version
>> x.y.z.
> 
> Yes, I meant it like that (but wrote it false), I meant the first in
> which the issuer found it. ;-)
> 
>> Sometimes it's set because someone plans to include it in a release.
>> Sometimes it's set because a RM likes to include it in a release.
>> Sometimes it's set because someone is working on it, or the issue is
>> under review.
> 
> Hmmm, so no really handling of this field. :-( That's bad for the
> Roadmap view of the issues.

Indeed as Jigal already pointed out, there is no way that we can have a
definitive "roadmap" of individual issues which we "would like" to
accomplished. So setting this for a future release is just an indicator
for the RM or the Team Leader of what is desired (or required) in the
next patch level release.

One idea which I might discuss in the release team meeting would be to
have roadmaps for individual sub-projects by using "meta versions" like
"6.2 FAL" or "6.2 Install Tool" so that these sub-projects could still
be part of the regular "Core Issue Tracker" but have separate roadmaps.

The "Target Version" of a resolved issue is not being used anywhere yet,
thus it's not always filled in correctly. The limitation of having to
choose one version is annoying. It's also not a matter of having a
"multiple select" field here, because a fix might be only targetting
some release but the backport is not finished yet.

Exactly this lack of flexibility in handling of the "Target Version" in
Redmine is what inspired me to create this overview [1].

[1] http://www.typo3-anbieter.de/typo3-merges/core.html

> So no easy way (with the issue tracker) to find what changed/will change
> in 6.0.6. :-/

No, but you have the above mentioned "merged into releases" script *and*
the ChangeLog included in the package itself.

Cheers,
Ernesto