[squeak-dev] Is the FileList broken in trunk?

Chris Muller asqueaker at gmail.com
Sun Dec 15 22:03:44 UTC 2013


On Sat, Dec 14, 2013 at 5:13 PM, Frank Shearar <frank.shearar at gmail.com>wrote:

> On 14 December 2013 20:53, Chris Muller <asqueaker at gmail.com> wrote:
> > Hi Frank!  I actually put this message out to lure you into this
> discussion.
> > :)  Because, I want to move on 4.5 and I knew you had _something_ out
> there,
> > but couldn't remember all the details.
>
> You used the right kind of bait, that's for sure :)
>
> > The issues I faced with needing to get a new image were:
> >
>  > - I had to research the mailing list to find out where to download it.
>  An
> > automated build server is great for doing continuous *testing* and
> > reporting, but it seems like for end-user downloads we should have a copy
> > available at the usual place (ftp.squeak.org).
> > - When I downloaded the image from CI, updated, and ran the tests, I
> found
> > there were more tests failing than in another image that was simply
> updated
> > from 4.4.  Something seemed to be wrong with the image state.
> > - Since I was not really certain what all was done in that image, I could
> > not trust putting it on the squeak.org FTP site.  The only way I could
> be
> > SURE enough about the state of an image put there was to take the archive
> > release image (4.4) and simply update it myself and save it.
> >
> > So, the overarching requirements:
> >
> >   - Downloadable from squeak.org domains.
> >   - A way to know exactly how it was built:  This means knowing which
> prior
> > _full release image_ was started with, and what changes (both code and
> > objects) were made.
> >   - Reproducible build.  My idea since 4.2 was to have a utility method
> on
> > ReleaseBuilder do all of this so it would be visible straight in the
> trunk
> > repository.  I guess I always thought of the CI's responsibility as a
> > on-going "test-status reporting" mechanism more than a deployment tool.
>
> Yep, yep, yep. I agree with all the above.
>
> There is something wrong with the base image state at the moment,
> partly because I'm incapable of pulling out ToolBuilder-Tests in less
> than at least three attempts (sigh!). (*)
>
> So the idea I've always had with CI was this:
> * take a known-good base image (not happening right now :( )
> * update it
> * run a battery of tests on a copy of the image
> * run the release process on the image (ReleaseSqueakTrunk)


Perfect.  (I assume you meant ReleaseBuilder).


>
> Every now and then, someone can take the latest ReleaseSqueakTrunk
> artifact, takes a look at the test results on build.squeak.org, plays
> around with it. If it's fit for purpose, he or she pushes the artifact
> up to ftp.squeak.org as a release candidate. Everyone else bangs on
> it, and if the release manager's happy, it ships.
>
> I do think that manual verification is important, because we don't
> want random broken builds on ftp.squeak.org, even if they're declared
> as alpha quality.
>

Absolutely.


>
> Additionally, as you rightly point out we need someone to advertise
> build.squeak.org. Not just that it's there and we use it, but how to
> get a bleeding-edge image, for instance.
>

A link from the main web-site and also from an appropriate page(s) in the
wiki would be a start.  We should have a page on the wiki dedicated to
explaining the CI server overview anyway.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20131215/6cf55e0d/attachment.htm


More information about the Squeak-dev mailing list