trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: December 2014

Re: [trinity-devel] TDE R14 Hard Freeze

From: Slávek Banko <slavek.banko@...>
Date: Tue, 9 Dec 2014 20:11:44 +0100
Dne �t 9. prosince 2014 Michele Calgaro napsal(a):
> On 12/09/2014 02:53 AM, Sl�vek Banko wrote:
> > Three months seemed like a good time. The good news is that builds for
> > armel and armhf are now significantly faster. Tim recently announced a
> > change in the mirror system. All this should speed up the process of
> > releasing a new version. The question therefore is whether we will have
> > enough capacity to fixing bugs. We can do this, we will assume that three
> > months for release 14.0.1 and in the process we'll see if that's enough
> > time.
>
> Very good assessment Slavek, fully agree with you. Let's plan for 3 month
> release period, but if for any reason we are not able to fix a reasonable
> amount of bugs (let's say at least 20 or 30 bugs, other opinions are
> welcome) in that time, we should delay until we hit such minimum
> requirement.
>
> Also, talking about v14.1.0 and v14.0.1, IMO we should slightly rearrange
> the meta bugs. 1) Bug 2233 should be renamed from "v14.0.1 official bug
> list (meta-bug)" to "v14.1.0 official bug list (meta-bug)" and would
> contain bugs to fix in the next release / improvement suggestions 2) We
> should add a new meta bug called "v14.0.1 resolved bug list". When we
> resolve a bug that will go into v14.0.1, we will link that bug to the meta
> bug. This meta bug will serve as a summary of all the fixes made for
> v14.0.1.
>
> Later there will be a v14.0.2, v14.0.3... meta bugs, while bug 2233 will
> continue to serve as meta bug for the next minor release.
>
> What do you think? If you agree, I can do the changes required.
>
> Cheers
>    Michele
>

I agree that we should have a meta-bug for R14.1.0. It probably does not 
matter it will renamed an existing 2233 or create a new one.

Regarding the meta-bug for R14.0.x. I would suggest for each 'patch' release 
separate meta-bug. Thus, one for R14.0.1, separate for R14.0.2, and as well 
as for next patch releases. It allows to plan assignment bug reports for each 
patch release. A meta-bug also will then be an overview of bugs fixed in any 
particular patch release.

I would suggest for patch releases not focus only on the number of fixed bugs. 
Substantial could be, for example, the importance of fixed bugs. Sufficiently 
frequent release of new versions also seems like a good card viability of the 
project.

-- 
Sl�vek