Issue, Author, branch, Keeper

[DGDanforth]

Redmine maintains "issues"
that are created by an "Author".
From an issue a "branch" is made.
But we do not have a word for who edits a branch.
I suggest the name "Keeper" for the single individual who
"checks out" a branch. Others may copy the branch but only
the Keeper can push modifications of it.

I now see the roll of the Chair as (1) the creator of a branch given input from
the author. The branch consists of a set of files (of arbitrary type). Each
branch should be disjoint from all other branches so that no conflicts
arise from editing the same file in two different branches. (2) the Chair
issues a "Key" to anyone who requests being Keeper of a branch. The
Key can be fictitious. The Chair simply keeps track of who is the Keeper
of each branch. The software should also reject any push to the branch from a non Keeper.
(3) The Keeper can relinquish the Key when either completing the desired changes to the branch
or when other mitigating circumstances make it impossible for the Keeper to continue. The
Chair then either announces the need for a new Keeper or creates an unstable version of the
master merged with the branch.
(4) Given some reasonable time for discussion and use the Chair then asks for a vote to make the unstable version
be the master.
(5) Based on the outcome of the vote the Chair then does (or does not) merge the branch with the master.
===
The introduction of the idea of a Keeper clarifies the process of project management.
Comments?
-Doug

[Ivan Denisov]

I think, that it is very complicated rules you are suggesting.
Anyone who wants to report an issue, can make new issue and it is not obligatory to make any branches at this moment.
Then the first person who wants to prepare some demo build is making the branch and push first commit.
And then many people can contribute using some polite rules of communication.
It means that there are usually one person responsible for the issue, so this person often can be "branch keeper".
Another person can help and preparing commits or clean the branch like Josef did several times.
All this actions we discussed on the board leading some common rules of polite communication.
I prefer to keep this system as it is for some time to keep this process simpler as it's possible.

[Josef Templ]

I agree with Ivan.
We have worked on many issues with the current process and it worked out fairly well.
There is already a field called 'Assignee' in redmine that is intended to record the responsible person.
This is not checked formally but I am not aware of any git feature that could be used for that.

In general, before creating an issue it should be checked if it is really an issue worth to be recorded or
if it needs some prior discussion or education. This must be judged on a case-by-case level.
The community forum is the best place to start such a discussion or question.

- Josef

[DGDanforth]

Fine, I am just attempting to understand the process. It seems very disorganized to me but then I don't understand redmine either.
-Doug

[Robert]

I don't understand the process very well myself, but:

- The current system does not seem to be 'broken', so does not need to be 'fixed'.
- The proposed new process does seem to add complexity.

Robert

[Josef Templ]

The process is designed around the available tools.
The tools are the main driving force.
You need to go through a couple of issues to get the real taste of it.
It is not as bad as it may look from a first experiment. Doug's
problems with installing Tortoise, cloning, etc..., are setup problems,
not related with the process.

The core idea of the process besides the tools is the review required
for every change that goes to master. There is no commit to master and no push to master and
no merge anything into master without a prior discussion and voting.
This is very organized. Sometimes it may feel too bureaucratic but
I have seen so many trivial looking changes (even mine) that were wrong or in poor coding style
that it is a clear advantage to be bureaucratic when it comes to changing master.

@Ivan: The only open problem that concerns me right now is the limit of 100 issues
reported by Redmine in one XML file. Can this limit be lifted?
It would be a significant complication of the change list generation to
iterate over several files.

- Josef

[Ivan Denisov]

@Ivan: The only open problem that concerns me right now is the limit of 100 issues
reported by Redmine in one XML file. Can this limit be lifted?
It would be a significant complication of the change list generation to
iterate over several files.

The limit you can regulate by the limit variable. We can set this to thousand.
redmine.blackboxframework.org/projects/blackbox/issues.xml?status_id=5&fixed_version_id=2&offset=0&limit=1000
So there is no limit problem for amount of issues in the the xml.

[Josef Templ]

In my experiments there was a cutoff at 100 no matter what the limit was.
Ivan, did you try it out?

- Josef

[Ivan Denisov]

In my experiments there was a cutoff at 100 no matter what the limit was.
Ivan, did you try it out?

- Josef

I sow issue #117 and thought that it means that this limit variable is working well.
However you right, that such a limit exists!
http://www.redmine.org/projects/redmine ... pagination
100 is maximal limit.
They are suggesting to use offset variable if total_count is more then 100.

[Zinn]

We should vote #117 & #118 and then close the change list for BB 1.7
Where can I find the protocol of all changes until #118?
For BB 1.8 we can restart with change number 1.
Maybe with revised rules about how to work with Git.
-Helmut