Lets look at the "Bug fixing live cycle". Whereas everything that causes
code change I define as a bug.
My view is, broken down on a singular incident:
1) There is a unfixed Bug
2) Analysis of the Bug
3) Proposed Solution (pre Git as patch / post git as pull request / or
at all times we had branch commits)
4) Initial developer test
5) developer group sign off
6) Integration into the Code tree
7) Community Test
8) Community Sign off
9) Release
Note: After 6) we do not look at individual Bugs, more like of a group
of bugs.
Currently, we have a special Case at Situation 4. Currently we see
little to none participation in points 3 & 4.
I do not want to speculate on the reasons, I think they do not matter.
The current situation is at this low participation
the live cycle chain becomes broken. Our active times by the way are
more in the second half of a year.
Now we have 2 choices. We skip Point 4 and 5 and move the test and hope
a later stage will identify any flaws in the proposed solution.
Or we enforce 4 and 5 and risking the development halts. In order to
fight a halt I started this discussion, asking for participation.
I ask everyone who can code, but since I know there are a lot of people
whop can not code, I am open for their participation, too.
The worse thing that can happen is that they learn something. So I think
all steps are open to all at default. Everyone can describe a bug.
Everyone can propose solutions, and everyone can test the bug at
different stages.
I hesitate to criticize the Idea to contact Raphael, but for me it makes
sense if we have specific questions. If you look at his Blog, you will
see he
has changed his live substantially, and moved on. I respect that, and he
has communicated that in a open way and in my case in a clear way.
If he returns he is most welcome to participate.
And participation is all what the discussion is about. With as low entry
point as possible.
Am 27.04.20 um 06:25 schrieb Jörg Schmidt:
Hello Carl,
-----Original Message-----
From: Carl Marcum [mailto:cmar...@apache.org]
Sent: Sunday, April 26, 2020 7:58 PM
To: dev@openoffice.apache.org
Subject: Re: testers and reviewers for Github
Good advice is always welcome.
As the use of Git is fairly new to the project
yes
I think as we go along a workflow process for forks, patches, pull
requests, etc. will develop organically
My thought was that experience in processes is also valuable, because Git is
only one (interchangeable) tool
Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
