trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: March 2014

Re: [trinity-devel] R14.0.0 soft freeze

From: Slávek Banko <slavek.banko@...>
Date: Mon, 3 Mar 2014 20:20:46 +0100
Dne po 3. března 2014 David C. Rankin napsal(a):
> On 03/03/2014 12:45 PM, Slávek Banko wrote:
> > Dne po 3. března 2014 Darrell napsal(a):
> >>> this is to remind everybody that as of today, R14.0.0 has been
> >>> declared feature-frozen (soft-freeze). No new apps, kde->tde
> >>> renames, major enhancement will be included in R14.0.0 and they
> >>> will have to wait for the next release.
> >>
> >> I have a pytdeextensions patch I finished yesterday that does
> >> nothing but kde->tde and qt->tqt renames. I can push or open a bug
> >> report. Based upon everything I saw , I suspect nobody uses
> >> pytdeextensions anyway.
> >
> > pytdeextensions is necessary for tde-guidance. And tde-guidance now
> > FTBFS. This is not good.
> >
> >>> Once the list is fully completed and agreed upon, we should make it
> >>> the official list and IMO we should declare R14.0.0 as hard-frozen.
> >>
> >> I think we ought to play wack-o-mole and get a nice hunk of bugs
> >> resolved before moving to hard freeze.
> >
> > I agree - not good freeze when serious bugs. For example, as of now
> > FTBFS in kchmviewer and tde-guidance.
> >
> >>> In the meantime, feel free to suggest what bugs you would like to
> >>> see fixed in R14.0.0 and if you are willing to work on any of them.
> >>> Please keep in mind that we want to keep the list as short as
> >>> possible, in order to release R14.0.0 in a timely manner. Therefore
> >>> bugs should fit in one of the next categories (in order of
> >>> priority): - blockers
> >>> - criticals
> >>> - cause major loss of functionality to the system or to the user
> >>> - results in loss of functionality that could affect R14 release
> >>> reviews negatively (such as help buttons not working for example)
> >>>
> >>> Please do not suggest bugs that do not fit in one of these
> >>> categories.
> >>
> >> Every time this kind of discussion arises I am the lone voice that
> >> is ignored. Everybody focuses on Blocker and Critical bugs. The bug
> >> list needs to include paper cut issues.
> >>
> >> http://bugs.pearsoncomputing.net/buglist.cgi?cmdtype=runnamed&namedc
> >>md= Regressions&list_id=237
> >> http://bugs.pearsoncomputing.net/buglist.cgi?cmdtype=runnamed&namedc
> >>md= stdout%2Fstderr&list_id=236
> >
> > For this reason, I'm not sure if just now he have to deal with
> > KXMLEditor and Katesort plugin. There are several other applications
> > on which François worked hard, and which also waiting for inclusion
> > into GIT. The only difference is that around them at present is not
> > such a stir.
> >
> > For example, for me, is critical twinkle. Francois on it did a lot of
> > effort, but because it is a complicated application, its integration
> > I've had to postpone - regardless of the fact that "for me" is
> > critical.
> >
> >> Darrell
>
> Then it looks like we are freezing too soon. If we do not even have
> time to include things that are already complete and simply need to be
> added, DO NOT FREEZE ANYTHING.
>
> SECOND -- as long as renaming continues DO NOT FREEZE. Renaming is
> guaranteed to BREAK things intended or not.
>
> Solution - Until renaming is complete DO NOT FREEZE -- it is pointless
> while renaming continues. Nobody can give any type of educated "it's
> ready to freeze" when nobody has had a chance to build the code that is
> to be frozen.
>
> If we must continue to rename, then set the soft freeze date 3 days
> after renaming is complete -- otherwise we are setting ourselves up for
> failure and we are pushing off functional additions to TDE for sake of
> renaming.
>
> We should not be in this position on the proposed soft-freeze date.

Yes, David, you're right. It is not a good idea to freeze when some 
applications FTBFS and when going another renaming, which may cause 
further FTBFS. This is not a good time to freeze.

-- 
Slavek