Re: [Checkins] SVN: zope.release/branches/3.4/ * Added latest version of zope.app.security to avoid deprecation
Stephan Richter a écrit :
Log message for revision 89104: * Added latest version of zope.app.security to avoid deprecation warnings.
* Added history file for the KGS to hopefully create better release notes.
Did you miss the CHANGES.txt in zope.release ? We have two histories now. How did you choose the 3.4.0c5 version? I mean, where does the "5" come from? Christophe
On Friday 01 August 2008, Christophe Combelles wrote:
Did you miss the CHANGES.txt in zope.release ? We have two histories now.
Nope, but that file tracks the package -- source code -- changes of zope.release. I wanted a separate file that tracks the changes to the controlled-packages.cfg file.
How did you choose the 3.4.0c5 version? I mean, where does the "5" come from?
We have been doing c* KGS releases all along. See http://download.zope.org/zope3.4/intro.html I just have not bothered updating the Zope3 tree, making packages and announcements. It just costs too much time. Unless Marius or someone else signs up for producing TAR ball releases and announces them, I will only create a TAR ball and announcement for Zope 3.4.0 final. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Hey Stephan, Thanks for doing all the work on KGS and the Zope 3.4.0 release. There are unfortunately a few things in this process that have me somewhat confused. I hope we can work out a way to clarify the process for 3.4.x and helping to clarify the process for 3.5.x. Firstly, could you add release dates to this page please? http://download.zope.org/zope3.4/intro.html I know that 3.4.0c1 was the latest release from january 31st until at least may, when we moved Grok over to that list. Then rather silently and somewhat suddenly I find out there have been 4 more release candidate releases. What is driving these changes? There's a changelog now I saw you mention, where should I look? Here I was thinking Grok was synched up to the latest and greatest 3.4.x since its latest 0.13 release, but this is now not the case anymore. We had c1 which lasted so long that I had started to treat it as the final. 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? What's the current plan for the final? What are the conditions that need to be reached to make a final release? Regards, Martijn
On Friday 01 August 2008, Martijn Faassen wrote:
Thanks for doing all the work on KGS and the Zope 3.4.0 release.
Thank Marius for getting into it and giving me some incentive to work on it again too. :-)
There are unfortunately a few things in this process that have me somewhat confused. I hope we can work out a way to clarify the process for 3.4.x and helping to clarify the process for 3.5.x.
I am confused too. :-) I am struggling between too-little time and formalizing the process. ;-)
Firstly, could you add release dates to this page please?
I thought the same thing last night too when looking at the now rather lengthy list of releases on the intro page. Since the page is auto-generated, the generating script has to be updated. We have two options: 1. Add a release-date field to the [KGS] section in controlled-packages.cfg. 2. Parse KGS-HISTORY.txt. This would also allow us to generate change logs for each release. Thoughts?
http://download.zope.org/zope3.4/intro.html
I know that 3.4.0c1 was the latest release from january 31st until at least may, when we moved Grok over to that list. Then rather silently and somewhat suddenly I find out there have been 4 more release candidate releases. What is driving these changes?
Marius started working on the KGS in the last week, since he is porting one of his apps from Zope 3.2 to 3.4. He needed to do a bunch of fixes to make it work. Also, he has set the goal for himself to fix the remaining failing tests. I also had some motivation to remove some deprecation warnings. So the last 4 candidates all happened in the last 2 weeks.
There's a changelog now I saw you mention, where should I look?
zope.release has now a `KGS-HISTORY.txt` file.
Here I was thinking Grok was synched up to the latest and greatest 3.4.x since its latest 0.13 release, but this is now not the case anymore. We had c1 which lasted so long that I had started to treat it as the final.
You pretty much are at the latest. :-)
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.
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. 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. - 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. - 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. - 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? -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
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
On Fri, Aug 1, 2008 at 2:06 PM, Marius Gedminas <marius@gedmin.as> wrote:
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.
+1
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.
3.4.0 is already at rc5, right? If so, I'd be disinclined to do pure refactor-y type things to it. -- Benji York Senior Software Engineer Zope Corporation
Stephan Richter a écrit :
On Friday 01 August 2008, Christophe Combelles wrote:
Did you miss the CHANGES.txt in zope.release ? We have two histories now.
Nope, but that file tracks the package -- source code -- changes of zope.release.
I wanted a separate file that tracks the changes to the controlled-packages.cfg file.
In my understanding, there is almost no source code in 'zope.release', since it has been moved into 'zope.kgs'. So there should be very few entries in CHANGES.txt, and I'm not sure there is a real interest in having two separate files. In my opinion, it adds confusion, people are more used to maintain CHANGES.txt. The other problem is there is no tag for c1, c2, c3 and c4. I thought zope.release was meant to represent the release number of zope. I would tend to: - create a tag for all missing candidates - merge KGS-HISTORY.txt into CHANGES.txt and recover missing information from published control-packages.cfg Christophe
How did you choose the 3.4.0c5 version? I mean, where does the "5" come from?
We have been doing c* KGS releases all along. See
http://download.zope.org/zope3.4/intro.html
I just have not bothered updating the Zope3 tree, making packages and announcements. It just costs too much time. Unless Marius or someone else signs up for producing TAR ball releases and announces them, I will only create a TAR ball and announcement for Zope 3.4.0 final.
Regards, Stephan
On Friday 01 August 2008, Christophe Combelles wrote:
I wanted a separate file that tracks the changes to the controlled-packages.cfg file.
In my understanding, there is almost no source code in 'zope.release', since it has been moved into 'zope.kgs'. So there should be very few entries in CHANGES.txt, and I'm not sure there is a real interest in having two separate files. In my opinion, it adds confusion, people are more used to maintain CHANGES.txt.
Okay, I am open to suggestions and want to hear others give an opinion too.
The other problem is there is no tag for c1, c2, c3 and c4. I thought zope.release was meant to represent the release number of zope.
It is. I and Marius simply did not create those tags.
I would tend to: - create a tag for all missing candidates
Cool, I take you up on that.
- merge KGS-HISTORY.txt into CHANGES.txt and recover missing information from published control-packages.cfg
These are two tasks: - Update KGS-HISTORY.txt to contain the changes of the previous releases. (Luckily you can just look at the SVN changelog for controlled-packages.cfg.) I take you up on that one as well! :-) - Merge KGS-HISTORY.txt into CHANGES.txt. I want to hear a couple more opinions on that. Regards, Stephan -- Stephan Richter Web Software Design, Development and Training Google me. "Zope Stephan Richter"
Stephan Richter a écrit :
On Friday 01 August 2008, Christophe Combelles wrote:
I wanted a separate file that tracks the changes to the controlled-packages.cfg file. In my understanding, there is almost no source code in 'zope.release', since it has been moved into 'zope.kgs'. So there should be very few entries in CHANGES.txt, and I'm not sure there is a real interest in having two separate files. In my opinion, it adds confusion, people are more used to maintain CHANGES.txt.
Okay, I am open to suggestions and want to hear others give an opinion too.
The other problem is there is no tag for c1, c2, c3 and c4. I thought zope.release was meant to represent the release number of zope.
It is. I and Marius simply did not create those tags.
I would tend to: - create a tag for all missing candidates
Cool, I take you up on that.
Done.
- merge KGS-HISTORY.txt into CHANGES.txt and recover missing information from published control-packages.cfg
These are two tasks:
- Update KGS-HISTORY.txt to contain the changes of the previous releases. (Luckily you can just look at the SVN changelog for controlled-packages.cfg.) I take you up on that one as well! :-)
I've updated KGS-HISTORY.txt and CHANGES.txt. Actually KGS-HISTORY.txt is just a reformatted svn diff between successive versions. I'm not sure it has a real added value, excepted when there are explanations about the version upgrades. Christophe
- Merge KGS-HISTORY.txt into CHANGES.txt. I want to hear a couple more opinions on that.
Regards, Stephan
Christophe Combelles wrote:
Stephan Richter a écrit :
On Friday 01 August 2008, Christophe Combelles wrote:
Did you miss the CHANGES.txt in zope.release ? We have two histories now.
Nope, but that file tracks the package -- source code -- changes of zope.release.
I wanted a separate file that tracks the changes to the controlled-packages.cfg file.
In my understanding, there is almost no source code in 'zope.release', since it has been moved into 'zope.kgs'. So there should be very few entries in CHANGES.txt, and I'm not sure there is a real interest in having two separate files. In my opinion, it adds confusion, people are more used to maintain CHANGES.txt.
Exactly.
The other problem is there is no tag for c1, c2, c3 and c4. I thought zope.release was meant to represent the release number of zope.
I would tend to: - create a tag for all missing candidates - merge KGS-HISTORY.txt into CHANGES.txt and recover missing information from published control-packages.cfg
+1
participants (6)
-
Benji York -
Christophe Combelles -
Marius Gedminas -
Martijn Faassen -
Philipp von Weitershausen -
Stephan Richter