The way of team work with Center release candidate?
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
The way of team work with Center release candidate?
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?
We can make the forum section for Bugs discussion or use some special tracker system. How do you see this work?
- DGDanforth
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Re: The way of team work with Center release candidate?
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.Ivan Denisov wrote: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?
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
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: The way of team work with Center release candidate?
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.DGDanforth wrote: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?
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: The way of team work with Center release candidate?
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).
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
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: The way of team work with Center release candidate?
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
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
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: The way of team work with Center release candidate?
I am fully agree with your proposal. What do other think? Can we vote for this?Josef Templ wrote: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.
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
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Re: The way of team work with Center release candidate?
I agree with both of you.Ivan Denisov wrote:I am fully agree with your proposal. What do other think? Can we vote for this?Josef Templ wrote: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.
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.
We just need to make this a clean process (is 'roll back' possible?).
-Doug
-
- Posts: 1700
- Joined: Tue Sep 17, 2013 12:21 am
- Location: Russia
Re: The way of team work with Center release candidate?
What do you mean?DGDanforth wrote:is 'roll back' possible?
- Josef Templ
- Posts: 2047
- Joined: Tue Sep 17, 2013 6:50 am
Re: The way of team work with Center release candidate?
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
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
- Posts: 1061
- Joined: Tue Sep 17, 2013 1:16 am
- Location: Palo Alto, California, USA
- Contact:
Re: The way of team work with Center release candidate?
In relational database systems one can 'roll back' to a previous version. That is, the current version is replaced by the previous version.Ivan Denisov wrote:What do you mean?DGDanforth wrote:is 'roll back' possible?