Issue tracker usage stratagy

[Josef Templ]

Was split from: http://forum.blackboxframework.org/view ... 8&start=20

Do we all agree that fixes to issues should be assigned the same issue number as the original issue?
This means that issue-#57 would have to be moved to issue-#19?
Do we need a voting on that?

I think it should be obvious to anybody that a fix to an issue is not a new issue
to be listed in the redmine issue tracker but must be grouped such that all changes refer
to the original issue.

- Josef

[Ivan Denisov]

Josef, I do not know about numbers. I think that it will be the mess with old numbers. Let's ask everybody by voting.

I think it will be better to make the reference for both issues in commit Refs: #57, #19.

[Josef Templ]

Josef, I do not know about numbers. I think that it will be the mess with old numbers. Let's ask everybody by voting.

I think it will be better to make the reference for both issues in commit Refs: #57, #19.

There seems to be a lack of agreement about the meaning of an entry in the redmine issue tracker.
For me it documents the changes from 1.6 to 1.7, not an internal development step when fixing an
issue split across several merges. By using a single issue number even when we have to use multiple merges
we group all related changes and make it possible to see that they refer to one and the same issue.
Later we will have a Python script that creates a change protocol
for 1.7 that can be provided on our web server for download. Such a change protocol would be very confusing
if it contained internal development and bug fixing steps.
It is also simpler because we skip the step of adding a new issue and it is also simpler
because we don't have to remember a new issue number in the discussion topics.
On the other side, I don't see any advantage when using a new issue number.

Since it is not possible to remove an issue from redmine we must at least
remove the target 1.7 from such issues or set it to "Support".

- Josef

[Ivan Denisov]

Josef, it is too complicated even for me. Issue is issue, if I found the bug or want to discuss some feature I will create the issue in issue tracker with a description. The issues tracker is a tool for communication rather than for documentation. Please, do not make artificial barriers for communication.

We are making the topic in forum after creation of issue in the tracker, so it should not be very strict and difficult.

[Josef Templ]

The forum is the place for discussions, not the issue tracker.

How would you generate a list of changes for the change protocol from 1.6 to 1.7
if not from the issue tracker?

- Josef

[Ivan Denisov]

The forum is the place for discussions, not the issue tracker.

I am not agree. Now we have a pipeline which is requiring to make issue first, before creating the topic for discussion of a bug.
If we will change this, issue tracker can become documentation tool. However this is not preferred, because for discussion often is better to have a good demo and diff for other members can analyse your solution. We made the Redmine for this diff feature. It makes the discussion more substantial.
Are you ready by your self to discuss issue on the forum first and only after this create the issue in bug tracker?

How would you generate a list of changes for the change protocol from 1.6 to 1.7
if not from the issue tracker?

I do not think, that it will be readable anyway. From the issue tracker you will have a very good draft. The draft we can edit for make it readable.

[DGDanforth]

There are two needs for diff: (1) for discussion, (2) in redmine issues.

Is it possible to create a diff without creating an issue?

-Doug

[Ivan Denisov]

There are two needs for diff: (1) for discussion, (2) in redmine issues.

Is it possible to create a diff without creating an issue?

Yes, you can create branch in GitHub, without creating the issue and it is allowing to have a link with diff. However you need to name the branch somehow.

[Josef Templ]

There is no problem at all if we avoid creating a new issue in redmine
for something that is already listed and has a well defined issue number.
The voting(s), the discussion(s), the merge(s), everything can be related to this single issue number.
See for example issue-#50 where this also happened.

If a discussion topic is overloaded or if it has been closed a new one can be created
with the same issue number together with a more specific title text.

There is no advantage of having multiple issue numbers for one and the
same issue but there are disadvantages that I don't want to repeat again and again.

I have done the editing work for a lot of issues and I did not need multiple issue numbers so far.
This can be taken as a proof that it works fine without multiple issue numbers.

- Josef

[Ivan Denisov]

Are you suggesting to make some bug classifier???
#19 is all unicode issues.
#50 is all issues about SqlControl...

This will complicate the task for the bug reporter. I do not think that this idea is worthwhile.

Or do you mean that this is only temporary measure while we are not finish the fusion process of CPC version into Center one?