incubator-ooo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ji Yan <yanji...@gmail.com>
Subject Re: Should we start posting regular dev snapshot builds for 3.4.1 or 3.5?
Date Fri, 15 Jun 2012 07:06:32 GMT
+1
Tester can use the snapshot build to verify fixed bug and do regression
test.
Currently, we have Linux 32/64 and Windows installer for AOO trunk stream
at buildbot http://ci.apache.org/projects/openoffice/
but lack of Mac installer. And also there is no build for branch stream. It
will be great to have snapshot build available for us.

2012/6/15 Jürgen Schmidt <jogischmidt@googlemail.com>

> On 6/14/12 11:33 PM, Andrew Rist wrote:
> >
> >
> > On 6/14/2012 8:20 AM, Jürgen Schmidt wrote:
> >> On 6/14/12 5:04 PM, Ariel Constenla-Haile wrote:
> >>> On Thu, Jun 14, 2012 at 10:53:51AM -0400, Rob Weir wrote:
> >>>> I've seeing a lot of bug fixes coming in.  This is great!
> >>>>
> >>>> But none of us are perfect.  Sometimes bug fixes don't work or fixing
> >>>> one bug causes another problem.    That is why we test.   And it is
> >>>> best to test a bug fix before too much time has elapsed.
> >>>>
> >>>> Would it make sense to agree on a date to post an updated dev
> >>>> snapshot, so we can verify the bug fixes and ensure that no new
> >>>> instability has been introduced?  Maybe get into the practice of doing
> >>>> this regularly, e.g., every 1 or 2 weeks or something.
> >>> IMO first we should decide if building 3.4.1 alphas/betas or 3.5
> >>> Developer
> >>> Snapshots; yes, the naming is a mess, we should clear this up, also
> >>> clear the page
> >>>
> https://cwiki.apache.org/confluence/display/OOOUSERS/AOO+3.4+Unofficial+Developer+Snapshots
> >>>
> >>> IIRC in OOo times, Developer Snapshots where builds from the main code
> >>> line, for example http://hg.services.openoffice.org/DEV300/
> >>> Betas where from the release code line, for example
> >>> http://hg.services.openoffice.org/OOO340/
> >>> http://hg.services.openoffice.org/OOO330/
> >>> http://hg.services.openoffice.org/OOO320/
> >>>
> >>> I guess we could build both, at different intervals, a 3.5 Dev.Snap.
> per
> >>> month and a 3.4.1 beta every week or two, for example.
> >>>
> >> When you see my proposed schedule for 3.4.1 I have proposed to start dev
> >> builds for 3.4.1 with the beginning of June. We are working on setting
> >> up some local machines that allow us to automate this a little bit. I
> >> hope we can start at least next week with this.
> >>
> >> And I agree to Ariel that it make sense to start with dev builds for 3.5
> >> (trunk) as well. And ideally we can use the binaries from the build bots
> >> directly. As I learned today we changed the configure flags already and
> >> we should check if we can these builds directly. Or if not we should
> >> check what we need to fix to make them usable. That would of course make
> >> things easier.
> > I think the builds from the buildbot could be directly used.  I think
> > there are a couple of things that would need to be changed:
> >  - create separate builds for 3.4.1 and trunk
> >  - create weekly 'dev builds' that will be a bit different than the
> > nightlies, with extra steps required and correct configure options.
> >  - create specific build for weekly rat + coverity + ??? for code
> > analysis that does not need to be run daily (or nightly)
> >
> I agree that makes absolutely sense.
>
> What do you think how much effort is it to adapt the existing scripts to
> support this? I have still no knowledge about the build bots, their
> setup... I should learn more about it ;-)
>
> We have to check how such a setup will work when we know more details
> about the code signing for our Windows binaries. That won't be easy from
> a security perspective...
>
> Do you know which compiler we use on the builds bots, do we use the
> professional version? We should ensure to enable ATL and ActiveX on the
> build bots as well.
>
> Juergen
>
> > A.
> >
> >>
> >> Juergen
> >>
> >
>
>
>


-- 


Thanks & Best Regards, Yan Ji

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