incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shenfeng Liu <liush...@gmail.com>
Subject Re: [RELEASE] 3.5, 4.0, fixpack, milestone build...
Date Thu, 27 Sep 2012 02:40:07 GMT
Xue Fei,
  I think BVT + fidelity automation will be good.
  And since we are still facing the buildbots limitation, we can start from
only some of the platforms and expand to more gradually.
  Thanks!

- Simon


2012/9/27 Xue Fei Duan <duanxf06@gmail.com>

> For milestone build, I think BVT + fidelity automation(load/save some
> samples) running is ok. we needn't have extra test plan on it, how do you
> think about it?
> -Xue Fei
>
> On Wed, Sep 26, 2012 at 6:50 PM, Shenfeng Liu <liushenf@gmail.com> wrote:
>
> > 2012/9/26 Ji Yan <yanji.yj@gmail.com>
> >
> > > Simon,
> > >
> > >   IMO, milestone test plan should base on milestone schedule and
> feature
> > > plan, what feature goes in and which defects are fixed in this
> milestone.
> > > Based on this scope we can define our testing plan. Otherwise we are
> > > running into target unclear testing, defects will be missed.
> > >
> > >
> > Ji,
> >   Thanks for your complete thought!
> >   While IMO, the milestone build is still a development snapshot. We
> don't
> > need to ensure a kind of GA quality on it. And we just need to ensure
> this
> > build:
> >
> > 1. Will not cause data lost (e.g. damage the file in editing).
> > 2. Will not lead to operation system crash.
> > 3. No severe defects that blocks user to try out the new features in this
> > build.
> >
> >   Of course we need to test the new features, but I think it should fall
> to
> > another category of our planned testing. And for milestone build
> testing, I
> > think an acceptance test should be able to cover above goals, and we can
> > record the tested scenarios/platforms/languages on a wiki page.
> >   We don't need to define a perfect test plan from beginning. Let's just
> > practise and refine.
> >
> > - Simon
> >
> >
> >
> > > 2012/9/26 Shenfeng Liu <liushenf@gmail.com>
> > >
> > > > 2012/9/26 Kay Schenk <kay.schenk@gmail.com>
> > > >
> > > > > On Tue, Sep 25, 2012 at 7:51 AM, Shenfeng Liu <liushenf@gmail.com>
> > > > wrote:
> > > > >
> > > > > > 2012/9/24 Keith N. McKenna <keith.mckenna@comcast.net>
> > > > > >
> > > > > > > Rob Weir wrote:
> > > > > > >
> > > > > > >> On Mon, Sep 24, 2012 at 8:59 AM, Keith N. McKenna
> > > > > > >> <keith.mckenna@comcast.net> wrote:
> > > > > > >>
> > > > > > >>> Rob Weir wrote:
> > > > > > >>>
> > > > > > >>>>
> > > > > > >>>> On Sun, Sep 23, 2012 at 10:13 AM, Shenfeng
Liu <
> > > > liushenf@gmail.com>
> > > > > > >>>> wrote:
> > > > > > >>>>
> > > > > > >>>>>
> > > > > > >>>>> Hi, all,
> > > > > > >>>>>     After 3.4.1, we are focusing on preparation
of the
> > > community
> > > > > > >>>>> graduation.
> > > > > > >>>>> But I still want to remind us to take some
time to think
> > about
> > > > our
> > > > > > >>>>> future
> > > > > > >>>>> releases.
> > > > > > >>>>>
> > > > > > >>>>>     We have the discussion early about
what 3.5 and 4.0
> > should
> > > > look
> > > > > > >>>>> like.
> > > > > > >>>>> If
> > > > > > >>>>> I remember correctly:
> > > > > > >>>>> (1) 3.5 should be more about fidelity,
reliability,
> > performance
> > > > and
> > > > > > >>>>> translation, new platform support...
> > > > > > >>>>> (2) While 4.0, in addition to the same
focuses as 3.5,
> should
> > > > also
> > > > > > add
> > > > > > >>>>> significant UX enhancements (e.g. sidebar,
modern UI) and
> new
> > > > > values
> > > > > > >>>>> (e.g.
> > > > > > >>>>> Accessibility, social integration capability,
enhanced
> > > installer,
> > > > > new
> > > > > > >>>>> features...). If we make good progress
on those items at
> the
> > > same
> > > > > > time,
> > > > > > >>>>> we
> > > > > > >>>>> may consider to skip 3.5.
> > > > > > >>>>> (3) There are also more requirements (e.g.
fixpack
> mechanism,
> > > > > > >>>>> simplifying
> > > > > > >>>>> the build structure, OOMXL export, smartArt...)
we need  to
> > put
> > > > > into
> > > > > > >>>>> our
> > > > > > >>>>> backlog and consider their priority.
> > > > > > >>>>>
> > > > > > >>>>>     Even we don't need to discuss the solid
plan now, but
> > there
> > > > are
> > > > > > >>>>> already a
> > > > > > >>>>> lot of development activities on the trunk.
So I think we
> > need
> > > to
> > > > > > keep
> > > > > > >>>>> certain track on it. Though it may be too
early to set a
> > target
> > > > > date
> > > > > > >>>>> for
> > > > > > >>>>> the next release, but it is important for
us to tell more
> > about
> > > > > what
> > > > > > we
> > > > > > >>>>> think the next release should contain.
> > > > > > >>>>>
> > > > > > >>>>>     So I'm suggesting the following:
> > > > > > >>>>>
> > > > > > >>>>> 1. Keep updating the current release planning
wiki:
> > > > > > >>>>>        -
> > > > > > >>>>>
> > > > > > >>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
> > > > > > >>>>> AOO+3.5+Release+Planning<
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.5+Release+Planning
> > > > > > >
> > > > > > >>>>>        -
> > > > > > >>>>>
> > > > > > >>>>> https://cwiki.apache.org/**confluence/display/OOOUSERS/**
> > > > > > >>>>> AOO+4.0+Release+Planning<
> > > > > >
> > > > >
> > > >
> > >
> >
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+4.0+Release+Planning
> > > > > > >
> > > > > > >>>>>      I know it is a little confusing for
2 places to input.
> > But
> > > > > think
> > > > > > >>>>> about
> > > > > > >>>>> the scope we agreed above. You can input
to the wiki that
> you
> > > > think
> > > > > > >>>>> your
> > > > > > >>>>> work belong to. I personally will monitor
both wiki pages.
> > > > > > >>>>>
> > > > > > >>>>> 2. Figure out a better way to manage our
release backlog.
> > e.g.
> > > > set
> > > > > > >>>>> Target
> > > > > > >>>>> Milestone to 3.5 or 4.0 in Bugzilla for
what we
> recommended.
> > > > > > >>>>>
> > > > > > >>>>> 3. Deliver milestone builds to harvest
our development
> > fruits.
> > > A
> > > > > > >>>>> milestone
> > > > > > >>>>> build is:
> > > > > > >>>>>        (a) a development snapshot that
contains the
> > > > > > >>>>> features/enhancements
> > > > > > >>>>> that implemented till now;
> > > > > > >>>>>        (b) passed regression test to ensure
no severe
> > defects;
> > > > > > >>>>>        (c) announced on a development wiki;
> > > > > > >>>>>        (d) with documents on the wiki for
the list of
> > features
> > > > and
> > > > > > bug
> > > > > > >>>>> fixes
> > > > > > >>>>> in this milestone build (like a release
notes).
> > > > > > >>>>>      Since whatever 3.5 or 4.0 sounds to
me like some thing
> > in
> > > > next
> > > > > > >>>>> year
> > > > > > >>>>> or
> > > > > > >>>>> at least close to the end of this year,
milestone builds
> can
> > be
> > > > > light
> > > > > > >>>>> weigh
> > > > > > >>>>> on process to show our development progress,
and give
> people
> > a
> > > > more
> > > > > > >>>>> clear
> > > > > > >>>>> view on how far are we to the next release.
> > > > > > >>>>>
> > > > > > >>>>>     Looking forward every one's comments!
> > > > > > >>>>>
> > > > > > >>>>>
> > > > > > >>>> Maybe also start a "release notes" page on
the wiki.
> >  Whenever a
> > > > new
> > > > > > >>>> feature or important bug fix is added to the
trunk also add
> > > > > something
> > > > > > >>>> to the release notes.   If something can be
show with a
> > "before
> > > > and
> > > > > > >>>> after" screen shot, include that.  This might
be easier than
> > > > waiting
> > > > > > >>>> until the end to prepare the release notes.
> > > > > > >>>>
> > > > > > >>>> -Rob
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>> - Simon
> > > > > > >>>>>
> > > > > > >>>>
> > > > > > >>>>
> > > > > > >>>>  Rob;
> > > > > > >>>
> > > > > > >>> A Release Notes page already exists or 3.5 and
one or 4.0 can
> > be
> > > > > easily
> > > > > > >>> added. The complication I see here is since we
have not
> decided
> > > > > whether
> > > > > > >>> the
> > > > > > >>> next release will be 3.5 or 4.0 that would require
adding it
> in
> > > two
> > > > > > >>> places.
> > > > > > >>> I see that as a lot of overhead at this point.
> > > > > > >>>
> > > > > > >>>
> > > > > > >> IMHO, the name is not so important.  Everything in
the trunk
> > goes
> > > > into
> > > > > > >> the next release.  Nothing not in the trunk goes into
the next
> > > > > > >> release.  So if we want a wiki page that is called
"Release
> > notes
> > > > for
> > > > > > >> AOO Target January 2013" then it would be sufficient.
 Just
> > > describe
> > > > > > >> significant changes there made in the trunk.  Maybe
in the end
> > we
> > > > call
> > > > > > >> it "Apache OpenOffice 2013", or "Apache OpenOffice
> Adventitious
> > > > > > >> Armadillo" or something like that.  That decision can
come
> > later.
> > > > > > >>
> > > > > > >> -Rob
> > > > > > >>
> > > > > > >>
> > > > > > > In that case lets use the existing 3.5 Release Notes as
Armin
> has
> > > > > already
> > > > > > > put a number of entries in there the "name can be change
to
> > protect
> > > > the
> > > > > > > innocent later".
> > > > > > >
> > > > > >
> > > > > > +1 to use the existing 3.5 Release Notes wiki.
> > > > > >
> > > > > > And I just made a query in BZ, for defects fixed after 3.4 (May
> 8),
> > > and
> > > > > > excluded (1) some Products as qa, www, (2) those Target Milestone
> > set
> > > > to
> > > > > > 3.4.1, and (3) Issue Type not in (DEFECT, FEATURE, ENHANCEMENT).
> > And
> > > I
> > > > > got
> > > > > > about 500 results. I picked some of them in the list and believe
> > > there
> > > > > are
> > > > > > still many items need to be taken out, e.g. those fixed 1 year
> ago,
> > > but
> > > > > > just validated recently. So I think I can quickly go through
> them,
> > > and
> > > > > for
> > > > > > those who are really fixed/implemented in trunk after 3.4 and
not
> > in
> > > > > 3.4.1,
> > > > > > I will set the Target Milestone to AOO 3.5.0. And this list
can
> be
> > a
> > > > base
> > > > > > for our release notes. How do you think?
> > > > > >
> > > > > > Another thing is that we need to define a test plan for the
> > milestone
> > > > > > build, which can be a lightweight regression test suite. The
plan
> > can
> > > > be
> > > > > > published on a wiki, and executed against very milestone build.
> > > > > > I agree with Juergen that we should start as early as possible.
> > > While I
> > > > > > still hope to get the confirmation from our QE team, since IMO
> they
> > > are
> > > > > the
> > > > > > key to this plan. :)
> > > > > >
> > > > > > - Simon
> > > > > >
> > > > >
> > > > > Simon --
> > > > >
> > > > > Great that you started this. Will all new features ( these seem to
> be
> > > all
> > > > > in Calc by the current 3.5 Release Planning doc), be given an issue
> > > > > assignment at some point to correspond to your BZ search filter?
> The
> > > one
> > > > > listed as i110133 doesn't seem to show up in either your "features"
> > or
> > > > > "all" filters you posted> I think it needs a target change (which
I
> > > > didn't
> > > > > make).
> > > > >
> > > > > All this will be very very helpful for planning our next release.
> So,
> > > > thank
> > > > > you.
> > > > >
> > > > >
> > > > Kay,
> > > >   The list on the wiki is out of date. So I update it and marked it
> > out.
> > > I
> > > > think i110133 is a defect that proposed to fix in 3.5, but further on
> > > there
> > > > is no update for this defect...
> > > >   Per our lesson&learned from 3.4.1, a better way is to leverage
> > Bugzilla
> > > > query. So I created one: TargetTo350AllFix. Also, I put the link on
> 3.5
> > > > wiki.
> > > >
> > > > - Simon
> > > >
> > > >
> > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Regards
> > > > > > > Keith
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >>  I could create a separate page as a sandbox where
what you
> > > suggest
> > > > > > could
> > > > > > >>> be
> > > > > > >>> input, then when the release comes it is just a
matter of
> > moving
> > > > the
> > > > > > data
> > > > > > >>> from the sandbox into the formal Release Notes
page.
> > > > > > >>>
> > > > > > >>> Regards
> > > > > > >>> Keith
> > > > > > >>>
> > > > > > >>>
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > >
> > > > >
> > > >
> > >
> >
> ----------------------------------------------------------------------------------------
> > > > > MzK
> > > > >
> > > > > "Just 'cause you got the monkey off your back
> > > > >  doesn't mean the circus has left town."
> > > > >                     -- George Carlin
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > >
> > >
> > > Thanks & Best Regards, Yan Ji
> > >
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message