incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus (OOo)" <marcus.m...@wtnet.de>
Subject Re: [RELEASE] milestone build (Was: [RELEASE] 3.5, 4.0, fixpack, milestone build...)
Date Mon, 08 Oct 2012 19:06:00 GMT
Am 10/08/2012 04:58 PM, schrieb J├╝rgen Schmidt:
> On 10/8/12 3:36 PM, Shenfeng Liu wrote:
>> 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.
>
> thanks for picking it up again, we should definitely start with snapshot
> builds asap
>
>>    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.
>
> The build bots are still not build the same as we do for the binary
> releases (please correct me if I am wrong). Means as long as we don't
> have build bots which are building with the same configuration we should
> provide the builds manually in the same way we did it for the release.
>
> @Ariel, would that be ok for you fro now until we have a better solution?
>
> I will take care of Windows and MacOS.
>
>
>>   (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.
>
> We should include the languages that we have released and add all
> languages where we notice active volunteers who help us to support these
> further languages (eg. Polish, Danish, Scots Gaelic, ...)
>
>
>>   (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?
>
> I am not sure if understand you correct. The revision is a unique
> identifier and makes it clear what went in the snapshot. We probably
> upload the builds not all on the same day. Means I am not sure how a
> date can help here.

I also wouldn't rely on a date value, even if it's looking right on the 
fisrt view. The revision number is what referenced everywhere (SVN, BZ). 
So, whenthe developer asks you "In which build have you seen this or 
that?" then you can tell her/him just the rev number.

>> 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.
>
> 1 + 2 are good ideas to keep the info up-to-date and to reduce the work
> later on short in front of the release.
>
>>   (2) a web page to announce this milestone build.
>
> mmh, when we want to promote the dev builds more we should consider the
> use of the mirrors. But this means we have to do more "release"
> preparation. I am not sure if we can and want manage this additional
> overhead at the moment. But I am open and we should check what's
> necessary to achieve this.

For the normal testing IMHO we can rely on an en-US full build and 
langpacks only for all other languages.

For special issues (e.g., fixes for the installer and system 
integration) we could build special install files on demand.

BTW:
I think it's clear that - if we all agree that we want it - I can 
support this process with updating the download webpages to offer the 
dev builds here instead (or additionally) of the Wiki. ;-)

Marcus



>>    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.

Mime
View raw message