The way of team work with Center release candidate?

[Ivan Denisov]

Let's start a discussion of stable fixes after 1.6 final, which can be applied, documented and released.

We can make the forum section for Bugs discussion or use some special tracker system. How do you see this work?

[DGDanforth]

Let's start a discussion of stable fixes after 1.6 final, which can be applied, documented and released.

We can make the forum section for Bugs discussion or use some special tracker system. How do you see this work?

I see the process consisting (as you suggest) of a Bugs list (that is verified by at least 2 people). That list pertains (applies) to a specific official release. As each new release occurs a new Bugs list is created for that release.

We have a problem. There is the Oberon Microsystems 1.6 release. There is Helmut's CPC release. How do we reconcile them? How do we merge them? Do we need to merge or do we simply accept Helmut's and the create a new Bugs list for it?

-Doug

[Ivan Denisov]

We have a problem. There is the Oberon Microsystems 1.6 release. There is Helmut's CPC release. How do we reconcile them? How do we merge them? Do we need to merge or do we simply accept Helmut's and the create a new Bugs list for it?

From my point of view, we should use Helmut, OberonCore, Krasnoyarsk and other versions as sources for the fixes. We need to evaluate fixes and apply over Oberon Microsystems 1.6 release step by step, fixing each change in numerated development releases. Such work is easy to do using git, mercurial or subversion repository. During previous discussion git repository was favoured.

[Ivan Denisov]

I made New category on the board and call it "BlackBox Issues Tracker".

We can use the forum for start doing something with BlackBox. After discussion somebody fix this in a code we can publish updated version in our simple webpage http://blackboxframework.org

Do you like this plan? I am suggesting that the poll can be created for each issue by the person who create the post (or some Admin will help to do this).

[Josef Templ]

It seems natural for me to use a Git Repository together with an issue tracker that comes
with GitHub or any other selected hosting platform.
I would not like to do issue tracking in the forum. It is (1) way too inconvenient and
(2) the commits in the repository should be connected with the issue being resolved.

As a starting piont we will probably use 1.6 final, but older releases could be included as well.
From 1.6 on there should be a list of issues and the commits should reference the resolved issue, one by one.

To the best of my knowledge, the most advanced version of BlackBox is the CPC edition by Helmut Zinn.
It has resolved a lot of issues from ominc, OberonCore etc. in a decent way.
The only problem is that the version history is not kept in a Repository but in a text file
that is rather hard to handle.

So my proposal is to move forward by simply adopting the CPC edition
but put it in a repository and equip it with a list of issues and one-by-one commits for each issue.

- Josef

[Ivan Denisov]

It seems natural for me to use a Git Repository together with an issue tracker that comes
with GitHub or any other selected hosting platform.
...
From 1.6 on there should be a list of issues and the commits should reference the resolved issue, one by one.

To the best of my knowledge, the most advanced version of BlackBox is the CPC edition by Helmut Zinn.
It has resolved a lot of issues from ominc, OberonCore etc. in a decent way.
The only problem is that the version history is not kept in a Repository but in a text file
that is rather hard to handle.

So my proposal is to move forward by simply adopting the CPC edition
but put it in a repository and equip it with a list of issues and one-by-one commits for each issue.

I am fully agree with your proposal. What do other think? Can we vote for this?

However we need to vote for fixes and features to be applied, and tracking systems have no such ability. I am suggest to use GitHub Issues tracking system for the fixation of forum decisions made by polls and for collecting unknown bugs from people outside the Center.

[DGDanforth]

It seems natural for me to use a Git Repository together with an issue tracker that comes
with GitHub or any other selected hosting platform.
...
From 1.6 on there should be a list of issues and the commits should reference the resolved issue, one by one.

To the best of my knowledge, the most advanced version of BlackBox is the CPC edition by Helmut Zinn.
It has resolved a lot of issues from ominc, OberonCore etc. in a decent way.
The only problem is that the version history is not kept in a Repository but in a text file
that is rather hard to handle.

So my proposal is to move forward by simply adopting the CPC edition
but put it in a repository and equip it with a list of issues and one-by-one commits for each issue.

I am fully agree with your proposal. What do other think? Can we vote for this?

However we need to vote for fixes and features to be applied, and tracking systems have no such ability. I am suggest to use GitHub Issues tracking system for the fixation of forum decisions made by polls and for collecting unknown bugs from people outside the Center.

I agree with both of you.
We just need to make this a clean process (is 'roll back' possible?).
-Doug

[Ivan Denisov]

is 'roll back' possible?

What do you mean?

[Josef Templ]

There is no rollback feature, as far as I know.
But you can always do a new commit that undoes a previous one.
Very much like in a financial accounting system where you enter a new
booking in order to cancel an erroneous previous booking.

Regarding the voting about the issues resolved in the CPC edition.
There are more than 50 issues resolved by now. So it will be a tedious process to
vote about each one separately. In the future this might be an option,
but for keeping up with the backlog I am afraid it is too much overhead.

- Josef

[DGDanforth]

is 'roll back' possible?

What do you mean?

In relational database systems one can 'roll back' to a previous version. That is, the current version is replaced by the previous version.