Hi Jim,
Hi Matthias,
I had a little off list discussion with Matthias about the goal of 4.1.6.
I would like to return this discussion to the list, and start a
discussion on our process to do releases.
We have said we want to make a Release once a year and try to get in
sync with trunk quickly by making a big jump and have a beta phase. And
then all will be easier.
This plan is stuck, and as a reaction I have initiated a 4.1.6 in order
to avoid security patches and updates of dependencies are affected by
our release being stuck with this big jump.
Matthias would really like to put also more functional code and feature
updates in. I would like to keep the 4.1.6 release as narrow as it is now.
I suggest we burry the plan in making a big jump to 4.2.0 in a single
Jump. Instead we make a create a release process that does not get stuck
by development as long as there are code changes that can be released.
In order to honor the stay independent from development in trunk, we
create a release branch. In the release branch we test "development
ready" patches. If they are fine, they move into the next scheduled release.
A release is then tailored as we are used to do today. If they are not
okay, we revert the patch, or fix the code. Depending on severity and
available resources.
Maybe it would be a good Idea to also limit the size of a release to a
number of patches (i.e. 10. By that we limit the Release size for testing.)
We could do offer an early adopter build based, in order to provide a
simple test access.
How about we try this? We could use a trello board to test the approach,
and if this works out we talk how to change Bugzilla to follow the process.
What do you think? Any other Ideas? I am open for all. But I would like
to get on a base where we can move.
Also a benefit I see from this approach I think is that we can let new
people build on the release branch. Which should stay more stable then
trunk. Especially with the updates we are currently doing within the
build environment.
All the best
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org
