Hi Peter, Am 07.10.2018 um 10:22 schrieb Peter Kovacs: > 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.
No, I want bugs to be fixed. That is what a release is for! And I know, that many people think that optical glitches don't qualify as a bug. But it helps to make a project look more professional... ;-) I am OK with the current amount of code fixes, but I think we should at least *try* to fix this bug on Linux: https://bz.apache.org/ooo/show_bug.cgi?id=127805 AOO is incompatible with FreeType 2.8 at the moment. Regards, Matthias > > 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: [email protected] > For additional commands, e-mail: [email protected] >
smime.p7s
Description: S/MIME Cryptographic Signature
