openoffice-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ariel Constenla-Haile <arie...@apache.org>
Subject Re: 4.1.4 Release Manager?
Date Fri, 16 Sep 2016 03:18:39 GMT
On Thu, Sep 15, 2016 at 09:14:33PM +0200, Marcus wrote:
> Am 09/15/2016 05:44 PM, schrieb Pedro Giffuni:
> >I am rather amazed by the idea of 4.1.4, shouldn't we release
> >4.2.0 instead? I mean ...
> >
> >- I thought the idea behind 4.1.3 was to make a quick fix for
> >4.1.2 and to give more time for the 4.2.0 release process.
> >- the code in trunk has over two years of development and is
> >more secure than what lives in the 41* branch. It is rather
> >disappointing to not see the code out sooner.

trunk does not even compile on MacOSX, gbuild integration is broken, so
until this gets fixed, it's IMHO better to keep the AOO41* branches
buildable.


> >I believe you should continue as Release Manager for 4.1.4,
> >or 4.2.0; the changes for 4.1.3 will already have to be
> >included in future releases and we could benefit from the
> >momentum of the dot release. Your vacations should also
> >not be a problem as other people are likely to be in
> >vacations during December as well.
> 
> I still think we should put more QA effort into a 4.2.0 as we have changed
> to many things. I cannot remember anymore which libraryies we have changed
> in the last time. So, at least this is a risk in my eyes that deserves much
> more attention.

Most of the library updates do not even have a bug report where the
change can be tracked by QA. Updating a library should not be outside of
the normal QA process, it means not only checking the source builds in
all platforms, there should be a bug report where the developer that did
the change identifies what functionality should be tested by QA
volunteers.

> Up to now I think tests where done here and there, e.g., when using a 4.2.0
> dev build for daily tasks. But I would like to see more efforts for deeper
> tests before release this.

AFAIK there is no formal QA for the library updates. Quality should be
a priority.


Regards
-- 
Ariel Constenla-Haile

Mime
View raw message