openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matthias Seidel <matthias.sei...@hamburg.de>
Subject Re: [discussion] Release process
Date Sun, 07 Oct 2018 09:46:43 GMT
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: dev-unsubscribe@openoffice.apache.org
> For additional commands, e-mail: dev-help@openoffice.apache.org
>



Mime
View raw message