incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Shenfeng Liu <>
Subject Re: [RELEASE] milestone build (Was: [RELEASE] 3.5, 4.0, fixpack, milestone build...)
Date Thu, 11 Oct 2012 14:59:21 GMT
2012/10/10 Marcus (OOo) <>

> Am 10/09/2012 03:58 AM, schrieb Shenfeng Liu:
>  2012/10/9 Ariel Constenla-Haile<arielch@** <>
>> >
>>  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
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
>>> 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:
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

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