incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shenfeng Liu <liush...@gmail.com>
Subject [RELEASE] milestone build (Was: [RELEASE] 3.5, 4.0, fixpack, milestone build...)
Date Mon, 08 Oct 2012 13:36:54 GMT
Hi, all,
  I'm just back from China Mid-Autumn/National-Day holidays. So I'd like to
pick up the milestone build topic again.
  We already get the support from QE team for the test plan. So I think we
need to do the following:

1. build out the milestone build. I saw from the buildbot that we have the
Windows and Linux-64 build successfully today. So it can be the candidate
of our first milestone build. While my question are:
 (1) Can we add more platforms (e.g. Mac, Linux-32, OS2...)? They need to
be built manually.
 (2) How many language support can we get for this milestone build? Not
necessary to be 100% translated, but can be a base for volunteers to verify
the translation.
 (3) The current development snapshot naming [a] is a little confusing to
me. I wonder if we can change the naming to reflect the date of the build?

2. upload the build and update the development snapshot wiki [a].

3. Run the testing against the build.

4. prepare related documents.
 (1) update the release notes wiki [b] for new values in this milestone
build.
 (2) a wiki page to record the testing result to this milestone build.
 (2) a web page to announce this milestone build.

  I can contribute to #4.

  Any thing else to add? Or any suggestion/comments?


- Simon


[a]
https://cwiki.apache.org/confluence/display/OOOUSERS/Development+Snapshot+Builds
[b]
https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.5+Release+Notes



2012/9/27 Shenfeng Liu <liushenf@gmail.com>

> 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