[Zope-dev] Zope 3.4 release policy

[Marius Gedminas]

On Fri, Aug 01, 2008 at 08:26:02AM -0700, Stephan Richter wrote:
> > We have been in release candidate space for Zope 3.4 for a very long
> > time; since january 31th. Do we really need 5 release candidates over a
> > period of half a year? Would we really have been harmed if we'd released
> > 3.4.0 final in, say, february, and were now doing 3.4.x releases?
> 
> The only reason I did not release in February was time. I signed up
> with Keas early in February and have been incredibly busy since then.
> Now that Marius is working on the release too, I want to honor his
> work and let him fix tests and make sure his app runs on Zope 3.4.

My app already runs (well, all the tests do; it'd be nice to do some
manual user testing, and especially test data migration from existing
instances).

What I feel uneasy about is declaring a 3.4.0 final when there are still
broken tests.

I also want to investigate the weird TALES iterator change where 'odd'
and 'even' swapped meanings between 3.2 and 3.4.  If that swap happened
before 3.3, it's too late, but if it happened after 3.3, then I'm
tempted to call it a regression and fix it.

I also have inclinations to clean up the tests that don't fail, but have
other downsides (random confusing output to stderr, not supporting
layer teardown).  I don't consider them to be release blockers, but I
think these would be nice to have in a 3.4.0 final.

> > What's the current plan for the final? What are the conditions that need to 
> > be reached to make a final release? 
> 
> From my point of view, my conditions would be:
> 
> - Let Marius ensure his app works with Zope 3.4.
> 
> - Let Marius finish fix the final test failures. He invested already a lot of 
> time. (I know, because I gave up on the final failing ones.)
> 
> - Nice to have: Update all packages in the KGS to their latest bug fix 
> release.
> 
> My larger concern is to make the release process much smoother and automated, 
> so that the burden of making a release becomes much smaller. I think the 
> following scripts could be written without too much effort:
> 
> - Setup a buildbot for KGS releases. I think Marius set one up already.

http://zope3.pov.lt/buildbot/

It assumes that the canonical way to run all the tests for the KGS
packages is to use zope.release's bin/generate-buildout.

You'll notice I'm only running tests on Linux (four varieties of).  If
anyone wants to offer a Win32/MacOS buildbot slave, email me.

What you probably won't immediatelly notice on that page is that I'm
running the tests with system python, with an undetermined set of
packages installed in site-packages.  I may change it to use a clean
python some day, but that's unlikely (lack of time and interest), unless
some of the test failures will be traced to problems with the system
python.

> The 
> test output could become part of some page linked from "intro.html". I am 
> thinking in particular of the total number of tests (marketing) and the 
> failures. 

Buildbot is a flexible thing; what it lacks is a cookbook. :-/

> - Upload the KGS-HISTORY.txt and parse it for the release date and changelog. 
> (Note that this parser could be written to understand our CHANGES.txt format 
> and we could even pull in Changelogs from all the updated packages!)
> 
> - Add the date and changelog info to intro.html.
> 
> - When uploading a new version of the KGS, automatically update the Zope 3 
> tree branch as well and create a release tag. Uses also the changelog 
> information for the tree CHANGES.txt file.

+1 for automatically updating the tree.

I don't see the need for automatically creating release tags.  We don't
do that for smaller projects (not every bugfix made to zope.foo release
branch immediately causes a new zope.foo release), so why do it for the
KGS?

An explicit "tag and release the current tip of the KGS branch" action
would be sufficient, IMO.

Besides, delaying a release will give people (and buildbots) a chance to
test in on various platforms.

> - Automatically create a Zope 3 tree TAR ball and upload it to zope.org. 
> Generate a link for it in the intro page as well.

This should be automated together with the tagging.

> - Automatically create a release E-mail and send it to zope-dev and 
> zope-users.
> 
> This should not be more than a days work for one of the core developers.
> 
> With this in place, cutting a release would become a matter of 
> calling "/bin/upload" from the "zope.release" package.
> 
> What do you guys think?

Sounds reasonable.

I personally have little interest in tarball releases.

Things that I care about:

  - 3.4 branch in Subversion
  - 3.4 versions.cfg
  - having all the tests pass on Python 2.4 on several versions of
    Ubuntu Linux (32- and 64-bit)
  - having all the tests pass on Python 2.5 on several versions of
    Ubuntu Linux (32- and 64-bit)
  - having *automated* regression notifications for changes to the KGS
    that break one or more tests
  - having the tests pass cleanly with no extra output

By "care about" I mean "am willing to do work to achieve/maintain this".

Marius Gedminas
-- 
Some people have told me they don't think a fat penguin really embodies the
grace of Linux, which just tells me they have never seen a angry penguin
charging at them in excess of 100mph. They'd be a lot more careful about what
they say if they had.
                -- Linus Torvalds, announcing Linux v2.0
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 191 bytes
Desc: Digital signature
Url : http://mail.zope.org/pipermail/zope-dev/attachments/20080801/4ee54938/attachment.bin