You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@openoffice.apache.org by Shenfeng Liu <li...@gmail.com> on 2012/10/08 15:36:54 UTC
[RELEASE] milestone build (Was: [RELEASE] 3.5, 4.0, fixpack,
milestone build...)
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 <li...@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 <du...@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 <li...@gmail.com> wrote:
>>
>> > 2012/9/26 Ji Yan <ya...@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 <li...@gmail.com>
>> > >
>> > > > 2012/9/26 Kay Schenk <ka...@gmail.com>
>> > > >
>> > > > > On Tue, Sep 25, 2012 at 7:51 AM, Shenfeng Liu <liushenf@gmail.com
>> >
>> > > > wrote:
>> > > > >
>> > > > > > 2012/9/24 Keith N. McKenna <ke...@comcast.net>
>> > > > > >
>> > > > > > > Rob Weir wrote:
>> > > > > > >
>> > > > > > >> On Mon, Sep 24, 2012 at 8:59 AM, Keith N. McKenna
>> > > > > > >> <ke...@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
>> > >
>> >
>>
>
>
Re: [RELEASE] milestone build (Was: [RELEASE] 3.5, 4.0, fixpack,
milestone build...)
Posted by Shenfeng Liu <li...@gmail.com>.
2012/10/12 Regina Henschel <rb...@t-online.de>
> Hi Simon,
>
> Shenfeng Liu schrieb:
>
>
>
>> I went through all the implemented features and enhancements for 3.5.0,
>> added/removed the Target Milestone value to some of the records.
>> And I created a query *TargetTo350FEATURE_Fixed* that can be easier for us
>> to write release notes:
>> https://issues.apache.org/ooo/**buglist.cgi?cmdtype=dorem&**
>> remaction=run&namedcmd=**TargetTo350FEATURE_Fixed&**sharer_id=249089<https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=TargetTo350FEATURE_Fixed&sharer_id=249089>
>> I hope people can check the query and confirm the features/enhancements.
>> As
>> Arial pointed out in another mail, my reading from the issue history may
>> not be consistent with the code.
>>
>> I will continue to check the defects, which may take more time...
>> Currently
>> there are 175 per TargetTo350AllFixed .
>>
>
> I do not think, that a query for a milestone in Bugzilla is really
> reliable. If you will try a query nevertheless, a query for commenter
> "svnbot" catches all issues, where the committer has written a bug ID into
> the commit message, http://s.apache.org/kT.
>
> But that will still not catch all relevant issues. To get really all
> changes you need to look at the commit log.
>
> Regina,
Thanks for the explanation! svnbot comment is the thing I will check when
I mark the Target Milestone (in fact I will check all the comments and
change history when I'm going to change the Target Milestone). While I also
understand that there are code delivery without associated Bugzilla
record... So I hope the Bugzilla query can be an easy start point and cover
most of the cases, then input for those not covered. Though IMHO, I'd like
to advocate the tracing of all changes in Bugzilla.
- Simon
> Kind regards
> Regina
>
>
Re: [RELEASE] milestone build (Was: [RELEASE] 3.5, 4.0, fixpack,
milestone build...)
Posted by Regina Henschel <rb...@t-online.de>.
Hi Simon,
Shenfeng Liu schrieb:
>
> I went through all the implemented features and enhancements for 3.5.0,
> added/removed the Target Milestone value to some of the records.
> And I created a query *TargetTo350FEATURE_Fixed* that can be easier for us
> to write release notes:
> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=TargetTo350FEATURE_Fixed&sharer_id=249089
> I hope people can check the query and confirm the features/enhancements. As
> Arial pointed out in another mail, my reading from the issue history may
> not be consistent with the code.
>
> I will continue to check the defects, which may take more time... Currently
> there are 175 per TargetTo350AllFixed .
I do not think, that a query for a milestone in Bugzilla is really
reliable. If you will try a query nevertheless, a query for commenter
"svnbot" catches all issues, where the committer has written a bug ID
into the commit message, http://s.apache.org/kT.
But that will still not catch all relevant issues. To get really all
changes you need to look at the commit log.
Kind regards
Regina
Re: [RELEASE] milestone build (Was: [RELEASE] 3.5, 4.0, fixpack,
milestone build...)
Posted by Jürgen Schmidt <jo...@gmail.com>.
On 10/11/12 4:59 PM, Shenfeng Liu wrote:
> 2012/10/10 Marcus (OOo) <ma...@wtnet.de>
>
>> Am 10/09/2012 03:58 AM, schrieb Shenfeng Liu:
>>
>> 2012/10/9 Ariel Constenla-Haile<arielch@**apache.org <ar...@apache.org>
>>>>
>>>
>>> Hi Jürgen, *
>>>>
>>>> On Mon, Oct 08, 2012 at 04:58:03PM +0200, Jürgen Schmidt wrote:
>>>>
>>>>> 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?
>>>>>
>>>>
>>>> Yes, I will apply the set up described in
>>>> https://issues.apache.org/ooo/**show_bug.cgi?id=119385<https://issues.apache.org/ooo/show_bug.cgi?id=119385>, that is,
>>>> decreasing Linux system requirements to glibc 2.5
>>>>
>>>> Any one is welcome to take any of the two architectures (building on
>>>> Linux is multiplied by 4: rpm/deb, 32 and 64 bits; this counts on
>>>> building time and uploading the packages); if not, I will take care of
>>>> both.
>>>>
>>>>
>>>>> 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 guess that besides the revision, milestone builds can be identified by
>>>> their milestone number, which should be increased in every milestone
>>>> build: AOO350m1 AOO350m2 etc
>>>>
>>>> just like in OOo times there was DEV300m105 DEV300m106 etc
>>>> http://www.openoffice.org/**development/releases/**
>>>> DEV300m106_snapshot.html<http://www.openoffice.org/development/releases/DEV300m106_snapshot.html>
>>>> it could start now from DEV350m1
>>>>
>>>>
>>>> OK, I understand the revision now, and let's forget the "date".
>>> And I agree with Ariel that a milestone number like AOO350m1 will be
>>> better
>>> when we promote it.
>>> I personally do not think we need to use mirror. But a download page that
>>> Marcus suggested will be good.
>>>
>>
>> Sure, the download page can point to the builds on the mirror system or
>> the ASF people's directories (when the paths are unified then automatism is
>> much easier).
>>
>> But when using the mirrors we could:
>> - stear the timeframe how long a milestone should be online,
>> - when to release the next dev build,
>> - a simple point of downloadable dev builds,
>> - and of course we can see how often which file was downloaded. To see if
>> it's worth the efforts at all.
>>
>> So, I think we should try to distribute the dev builds via the mirror
>> system. If we laster think that it doesn't make sense anymore then we can
>> stop it.
>>
>> Marcus
>>
>
> You persuaded me, Marcus. :) I agree mirrors will be good for the milestone
> build. As far as we can contain the effort.
>
> I went through all the implemented features and enhancements for 3.5.0,
> added/removed the Target Milestone value to some of the records.
> And I created a query *TargetTo350FEATURE_Fixed* that can be easier for us
> to write release notes:
> https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=TargetTo350FEATURE_Fixed&sharer_id=249089
> I hope people can check the query and confirm the features/enhancements. As
> Arial pointed out in another mail, my reading from the issue history may
> not be consistent with the code.
>
> I will continue to check the defects, which may take more time... Currently
> there are 175 per TargetTo350AllFixed .
>
> Juergen & Arial, can I know where we are with the builds?
we don't have started yet because we haven't finally agreed on a
version. I will check the build bots tomorrow morning and will propose a
revision for the next dev snapshot. We can build and upload them over
the weekend and should have them on Monday ready.
Juergen
>
> Thanks very much for you all's support!
>
> - Simon
>
Re: [RELEASE] milestone build (Was: [RELEASE] 3.5, 4.0, fixpack,
milestone build...)
Posted by Shenfeng Liu <li...@gmail.com>.
2012/10/10 Marcus (OOo) <ma...@wtnet.de>
> Am 10/09/2012 03:58 AM, schrieb Shenfeng Liu:
>
> 2012/10/9 Ariel Constenla-Haile<arielch@**apache.org <ar...@apache.org>
>> >
>>
>> Hi Jürgen, *
>>>
>>> On Mon, Oct 08, 2012 at 04:58:03PM +0200, Jürgen Schmidt wrote:
>>>
>>>> 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?
>>>>
>>>
>>> Yes, I will apply the set up described in
>>> https://issues.apache.org/ooo/**show_bug.cgi?id=119385<https://issues.apache.org/ooo/show_bug.cgi?id=119385>, that is,
>>> decreasing Linux system requirements to glibc 2.5
>>>
>>> Any one is welcome to take any of the two architectures (building on
>>> Linux is multiplied by 4: rpm/deb, 32 and 64 bits; this counts on
>>> building time and uploading the packages); if not, I will take care of
>>> both.
>>>
>>>
>>>> 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 guess that besides the revision, milestone builds can be identified by
>>> their milestone number, which should be increased in every milestone
>>> build: AOO350m1 AOO350m2 etc
>>>
>>> just like in OOo times there was DEV300m105 DEV300m106 etc
>>> http://www.openoffice.org/**development/releases/**
>>> DEV300m106_snapshot.html<http://www.openoffice.org/development/releases/DEV300m106_snapshot.html>
>>> it could start now from DEV350m1
>>>
>>>
>>> OK, I understand the revision now, and let's forget the "date".
>> And I agree with Ariel that a milestone number like AOO350m1 will be
>> better
>> when we promote it.
>> I personally do not think we need to use mirror. But a download page that
>> Marcus suggested will be good.
>>
>
> Sure, the download page can point to the builds on the mirror system or
> the ASF people's directories (when the paths are unified then automatism is
> much easier).
>
> But when using the mirrors we could:
> - stear the timeframe how long a milestone should be online,
> - when to release the next dev build,
> - a simple point of downloadable dev builds,
> - and of course we can see how often which file was downloaded. To see if
> it's worth the efforts at all.
>
> So, I think we should try to distribute the dev builds via the mirror
> system. If we laster think that it doesn't make sense anymore then we can
> stop it.
>
> Marcus
>
You persuaded me, Marcus. :) I agree mirrors will be good for the milestone
build. As far as we can contain the effort.
I went through all the implemented features and enhancements for 3.5.0,
added/removed the Target Milestone value to some of the records.
And I created a query *TargetTo350FEATURE_Fixed* that can be easier for us
to write release notes:
https://issues.apache.org/ooo/buglist.cgi?cmdtype=dorem&remaction=run&namedcmd=TargetTo350FEATURE_Fixed&sharer_id=249089
I hope people can check the query and confirm the features/enhancements. As
Arial pointed out in another mail, my reading from the issue history may
not be consistent with the code.
I will continue to check the defects, which may take more time... Currently
there are 175 per TargetTo350AllFixed .
Juergen & Arial, can I know where we are with the builds?
Thanks very much for you all's support!
- Simon
Re: [RELEASE] milestone build (Was: [RELEASE] 3.5, 4.0, fixpack,
milestone build...)
Posted by Ji Yan <ya...@gmail.com>.
+1 for using mirrors system to distribute milestone build.
2012/10/10 Marcus (OOo) <ma...@wtnet.de>
> Am 10/09/2012 03:58 AM, schrieb Shenfeng Liu:
>
> 2012/10/9 Ariel Constenla-Haile<arielch@**apache.org <ar...@apache.org>
>> >
>>
>> Hi Jürgen, *
>>>
>>> On Mon, Oct 08, 2012 at 04:58:03PM +0200, Jürgen Schmidt wrote:
>>>
>>>> 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?
>>>>
>>>
>>> Yes, I will apply the set up described in
>>> https://issues.apache.org/ooo/**show_bug.cgi?id=119385<https://issues.apache.org/ooo/show_bug.cgi?id=119385>, that is,
>>> decreasing Linux system requirements to glibc 2.5
>>>
>>> Any one is welcome to take any of the two architectures (building on
>>> Linux is multiplied by 4: rpm/deb, 32 and 64 bits; this counts on
>>> building time and uploading the packages); if not, I will take care of
>>> both.
>>>
>>>
>>>> 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 guess that besides the revision, milestone builds can be identified by
>>> their milestone number, which should be increased in every milestone
>>> build: AOO350m1 AOO350m2 etc
>>>
>>> just like in OOo times there was DEV300m105 DEV300m106 etc
>>> http://www.openoffice.org/**development/releases/**
>>> DEV300m106_snapshot.html<http://www.openoffice.org/development/releases/DEV300m106_snapshot.html>
>>> it could start now from DEV350m1
>>>
>>>
>>> OK, I understand the revision now, and let's forget the "date".
>> And I agree with Ariel that a milestone number like AOO350m1 will be
>> better
>> when we promote it.
>> I personally do not think we need to use mirror. But a download page that
>> Marcus suggested will be good.
>>
>
> Sure, the download page can point to the builds on the mirror system or
> the ASF people's directories (when the paths are unified then automatism is
> much easier).
>
> But when using the mirrors we could:
> - stear the timeframe how long a milestone should be online,
> - when to release the next dev build,
> - a simple point of downloadable dev builds,
> - and of course we can see how often which file was downloaded. To see if
> it's worth the efforts at all.
>
> So, I think we should try to distribute the dev builds via the mirror
> system. If we laster think that it doesn't make sense anymore then we can
> stop it.
>
> Marcus
>
--
Thanks & Best Regards, Yan Ji
Re: [RELEASE] milestone build (Was: [RELEASE] 3.5, 4.0, fixpack,
milestone build...)
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
Am 10/09/2012 03:58 AM, schrieb Shenfeng Liu:
> 2012/10/9 Ariel Constenla-Haile<ar...@apache.org>
>
>> Hi Jürgen, *
>>
>> On Mon, Oct 08, 2012 at 04:58:03PM +0200, Jürgen Schmidt wrote:
>>> 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?
>>
>> Yes, I will apply the set up described in
>> https://issues.apache.org/ooo/show_bug.cgi?id=119385 , that is,
>> decreasing Linux system requirements to glibc 2.5
>>
>> Any one is welcome to take any of the two architectures (building on
>> Linux is multiplied by 4: rpm/deb, 32 and 64 bits; this counts on
>> building time and uploading the packages); if not, I will take care of
>> both.
>>
>>>
>>> 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 guess that besides the revision, milestone builds can be identified by
>> their milestone number, which should be increased in every milestone
>> build: AOO350m1 AOO350m2 etc
>>
>> just like in OOo times there was DEV300m105 DEV300m106 etc
>> http://www.openoffice.org/development/releases/DEV300m106_snapshot.html
>> it could start now from DEV350m1
>>
>>
> OK, I understand the revision now, and let's forget the "date".
> And I agree with Ariel that a milestone number like AOO350m1 will be better
> when we promote it.
> I personally do not think we need to use mirror. But a download page that
> Marcus suggested will be good.
Sure, the download page can point to the builds on the mirror system or
the ASF people's directories (when the paths are unified then automatism
is much easier).
But when using the mirrors we could:
- stear the timeframe how long a milestone should be online,
- when to release the next dev build,
- a simple point of downloadable dev builds,
- and of course we can see how often which file was downloaded. To see
if it's worth the efforts at all.
So, I think we should try to distribute the dev builds via the mirror
system. If we laster think that it doesn't make sense anymore then we
can stop it.
Marcus
Re: [RELEASE] milestone build (Was: [RELEASE] 3.5, 4.0, fixpack,
milestone build...)
Posted by Shenfeng Liu <li...@gmail.com>.
2012/10/9 Ariel Constenla-Haile <ar...@apache.org>
> Hi Jürgen, *
>
> On Mon, Oct 08, 2012 at 04:58:03PM +0200, Jürgen Schmidt wrote:
> > 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?
>
> Yes, I will apply the set up described in
> https://issues.apache.org/ooo/show_bug.cgi?id=119385 , that is,
> decreasing Linux system requirements to glibc 2.5
>
> Any one is welcome to take any of the two architectures (building on
> Linux is multiplied by 4: rpm/deb, 32 and 64 bits; this counts on
> building time and uploading the packages); if not, I will take care of
> both.
>
> >
> > 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 guess that besides the revision, milestone builds can be identified by
> their milestone number, which should be increased in every milestone
> build: AOO350m1 AOO350m2 etc
>
> just like in OOo times there was DEV300m105 DEV300m106 etc
> http://www.openoffice.org/development/releases/DEV300m106_snapshot.html
> it could start now from DEV350m1
>
>
OK, I understand the revision now, and let's forget the "date".
And I agree with Ariel that a milestone number like AOO350m1 will be better
when we promote it.
I personally do not think we need to use mirror. But a download page that
Marcus suggested will be good.
- Simon
>
> Regards
> --
> Ariel Constenla-Haile
> La Plata, Argentina
>
Re: [RELEASE] milestone build (Was: [RELEASE] 3.5, 4.0, fixpack,
milestone build...)
Posted by Ariel Constenla-Haile <ar...@apache.org>.
Hi Jürgen, *
On Mon, Oct 08, 2012 at 04:58:03PM +0200, Jürgen Schmidt wrote:
> 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?
Yes, I will apply the set up described in
https://issues.apache.org/ooo/show_bug.cgi?id=119385 , that is,
decreasing Linux system requirements to glibc 2.5
Any one is welcome to take any of the two architectures (building on
Linux is multiplied by 4: rpm/deb, 32 and 64 bits; this counts on
building time and uploading the packages); if not, I will take care of
both.
>
> 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 guess that besides the revision, milestone builds can be identified by
their milestone number, which should be increased in every milestone
build: AOO350m1 AOO350m2 etc
just like in OOo times there was DEV300m105 DEV300m106 etc
http://www.openoffice.org/development/releases/DEV300m106_snapshot.html
it could start now from DEV350m1
Regards
--
Ariel Constenla-Haile
La Plata, Argentina
Re: [RELEASE] milestone build (Was: [RELEASE] 3.5, 4.0, fixpack,
milestone build...)
Posted by "Marcus (OOo)" <ma...@wtnet.de>.
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<li...@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<du...@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<li...@gmail.com> wrote:
>>>>
>>>>> 2012/9/26 Ji Yan<ya...@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<li...@gmail.com>
>>>>>>
>>>>>>> 2012/9/26 Kay Schenk<ka...@gmail.com>
>>>>>>>
>>>>>>>> On Tue, Sep 25, 2012 at 7:51 AM, Shenfeng Liu<liushenf@gmail.com
>>>>>
>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> 2012/9/24 Keith N. McKenna<ke...@comcast.net>
>>>>>>>>>
>>>>>>>>>> Rob Weir wrote:
>>>>>>>>>>
>>>>>>>>>>> On Mon, Sep 24, 2012 at 8:59 AM, Keith N. McKenna
>>>>>>>>>>> <ke...@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.
Re: [RELEASE] milestone build (Was: [RELEASE] 3.5, 4.0, fixpack,
milestone build...)
Posted by Jürgen Schmidt <jo...@gmail.com>.
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.
>
> 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.
Juergen
>
> 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 <li...@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 <du...@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 <li...@gmail.com> wrote:
>>>
>>>> 2012/9/26 Ji Yan <ya...@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 <li...@gmail.com>
>>>>>
>>>>>> 2012/9/26 Kay Schenk <ka...@gmail.com>
>>>>>>
>>>>>>> On Tue, Sep 25, 2012 at 7:51 AM, Shenfeng Liu <liushenf@gmail.com
>>>>
>>>>>> wrote:
>>>>>>>
>>>>>>>> 2012/9/24 Keith N. McKenna <ke...@comcast.net>
>>>>>>>>
>>>>>>>>> Rob Weir wrote:
>>>>>>>>>
>>>>>>>>>> On Mon, Sep 24, 2012 at 8:59 AM, Keith N. McKenna
>>>>>>>>>> <ke...@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
>>>>>
>>>>
>>>
>>
>>
>
Re: [RELEASE] milestone build (Was: [RELEASE] 3.5, 4.0, fixpack, milestone build...)
Posted by Torokhov Sergey <to...@mail.ru>.
On Monday 08 of October 2012 21:36:54 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.
> 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+Bu
> ilds [b]
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.5+Release+Notes
>
>
>
Hi to all!
Does it planing to resolve some feature requests for AOO 3.5 release for Calc
application?
Please, consider some useful features like this:
The one is concern in "scientific" representation of charts that is often used
for publications:
Bug 6521 - formatting single characters in titles - subscript or superscript
in chart titles
https://issues.apache.org/ooo/show_bug.cgi?id=6521
And the other is for better language support:
Bug 62460 - Implement genitive forms of month names (posessive context)
https://issues.apache.org/ooo/show_bug.cgi?id=62460