Page 1 of 3

The issues tracker

Posted: Fri Aug 01, 2014 8:07 am
by Josef Templ
I have done more experiments with GitHub and it seems to me that it offers a
very nice issue tracker. My question, in particular to Ivan, is:
Why are we using the redmine issue tracker?
What are its specific advantages over the GitHub issue tracker?

The advantages of the GitHub issue tracker are:
1. it allows you to stay in one and the same environment for both the code changes and the issue handling.
2. it is possible to add comments on issues
3. it supports cross linking between commits and issues
4. it provides an extension mechanism via GitHub's API
5. it is possible to create a fully customized and automatically generated changelog for a release
via the API and external postprocessing.
6. it does not need any resources from our Edis host

- Josef

Re: Feature #9: adding module Characters

Posted: Fri Aug 01, 2014 8:52 am
by Ivan Denisov
Josef Templ wrote:I have done more experiments with GitHub and it seems to me that it offers a
very nice issue tracker. My question, in particular to Ivan, is:
Why are we using the redmine issue tracker?
What are its specific advantages over the GitHub issue tracker?

The advantages of the GitHub issue tracker are:
1. it allows you to stay in one and the same environment for both the code changes and the issue handling.
2. it is possible to add comments on issues
3. it supports cross linking between commits and issues
4. it provides an extension mechanism via GitHub's API
5. it is possible to create a fully customized and automatically generated changelog for a release
via the API and external postprocessing.
6. it does not need any resources from our Edis host
We are using Redmine because we voted for this. We voted for this, because GitHub does not allowing to make binary-to-text-conversion for preview differences and we do not wants to store sources in plain text. Redmine is better for the whole project tracking, because it has much more features for this.

Now the troubles with locale is over and diff works fine. Redmine did not take much from our VPS, and we take this VPS. Now we made build pipeline, that uses local mirror of GitHub repository and Redmine is good for monitoring it's state. This local repository synced with GitHub by webhook and updated immediately after any push is made in the GitHub.

I really do not care about Center to use Redmine, I have one already for my own projects http://redmine.molpit.com. However it was an decision of the Center and I supported it, because think it will give benefits for tracking the changes keeping binary sources tradition.

Re: The issues tracker

Posted: Fri Aug 01, 2014 9:24 am
by Ivan Denisov
My opinion, that we should start working with a BlackBox sources more than with sites and tools. The time will show the benefits or disadvantages.

Now we have:
- The Board for general discussions and the Board for community support
- The GitHub for managing the repository, pull requests and public issues from the wide community
- The Redmine for project tracking, Center structured issues tracking and EDIS mirror repository review in converted form
- The Wiki for posting manual pages and informations about any definitions
- The Multilingual front-page for breath info about project, downloading the products and funds requesting
- The pipeline for building BlackBox from the sources

Re: The issues tracker

Posted: Fri Aug 01, 2014 9:25 am
by Josef Templ
redmine would still be required as a diff viewer and as a part of the toolchain.
There is no change in that.

I voted for redmine inclusion because of the diff viewer for .odc files.
But that has also problems in detail.
It is not possible to view a new file (because there is no difference available) and
for diffs it shows only a few lines of context for changed lines.
Center members didn't use it a lot so far, it seems.
If they use it they will see the problems.
As long as there is no alternative, of course redmine stays
as a diff viewer.

The issue tracking is different. There is an alternative and most
center members have not used any of them before, including me.
So we must be open for collecting experience and making an informed decision
as long as we are in the design phase of the tool chain and workflow.

I am also not sure if we explicitly voted for an issue tracking system.
The vote was entitled: "Repository and code versioning tool"
and the winner was: "Public GitHub synced with our own tuned Redmine"
Both have an issue tracker, so which one is it?
Was there another vote?

- Josef

Re: The issues tracker

Posted: Fri Aug 01, 2014 9:31 am
by Ivan Denisov
Josef Templ wrote:It is not possible to view a new file (because there is no difference available) and
for diffs it shows only a few lines of context for changed lines.
Center members didn't use it a lot so far, it seems.
If they use it they will see the problems.
As long as there is no alternative, of course redmine stays
as a diff viewer.
All the differences is shown during commits diff preview, including the code of new files.
The one-by-one preview can be tuned it future, because we have access to the source codes of Redmine. I have experience with that.

Re: The issues tracker

Posted: Fri Aug 01, 2014 9:32 am
by Ivan Denisov
Josef Templ wrote:The issue tracking is different. There is an alternative and most
center members have not used any of them before, including me.
So we must be open for collecting experience and making an informed decision
as long as we are in the design phase of the tool chain and workflow.

I am also not sure if we explicitly voted for an issue tracking system.
The vote was entitled: "Repository and code versioning tool"
and the winner was: "Public GitHub synced with our own tuned Redmine"
Both have an issue tracker, so which one is it?
Was there another vote?
I agree. You are right.

I am very happy with Redmine issues tracker :) I very like the system of commit and issue linking you showed to me in Redmine (I did not know about this before). But we really did not vote for this. I tried to initiate the discussion of issue tracker before, but in other aspect... http://forum.blackboxframework.org/view ... f=33&t=106

Re: The issues tracker

Posted: Sat Aug 02, 2014 4:50 am
by Ivan Denisov
Please take a look at this cool system of roadmap. This interactive online documentation for each version make changelog better and easier to prepare in online format.
http://redmine.blackboxframework.org/versions/1

Re: The issues tracker

Posted: Mon Aug 18, 2014 3:01 pm
by Josef Templ
Now, before starting to add more issues and commits.
We really must agree on which issue tracker should be used from now on!
This is a decision that will be with us for a long time.
It is not possible to change to another issue tracker without
introducing major consistency problems.

Currently we are using the redmine issue tracker.
The alternative would be to use the GitHub issue tracker.
Frankly, my preference is GitHub. There has not been any voting about which issue tracker to use.
The inclusion of redmine was related with using redmine as a diff viewer, which it
would continue to be!
The big advantage of GitHub would be that it is zero administration, zero cost,
i.e. no bandwidth, no storage, no CPU cycles on our Edis host.
It is available round the clock without any need for updates and the danger of creating
inconsistencies in the required packages and this kind of stuff.
Another advantage of the GitHub tracker is that you can stay in one and the same environment
when browsing the repository and the issues.
Regarding the functionality: for our purposes both can be considered equal.
Cross linking between issues and commits is also possible with GitHub.

- Josef

Re: The issues tracker

Posted: Mon Aug 18, 2014 10:20 pm
by DGDanforth
Is it possible to send us an example of what an issue looks like in GitHub?

Re: The issues tracker

Posted: Tue Aug 19, 2014 4:25 am
by Ivan Denisov
I agree, that we need to make the vote.

Josef, are you sure, that GitHub allows to make isolated issues tracker?

GitHub is open for everyone to post the issues, however we want to have the ability to control accessibility.

One more minus it to basing on any service, that we can not control. With our own tracker we have essential freedom to move it to any server, to make mirrors and so on.
DGDanforth wrote:Is it possible to send us an example of what an issue looks like in GitHub?
https://github.com/BlackBoxCenter/bbcb/issues/1