Agenda for today's IRC meeting (3pm UTC on #zope)
Hi everyone, today's the fifth weekly meeting and I hope to see you around 3pm UTC at #zope at freenode. (Still a few hours to go.) Please plan 45 minutes for today instead of the usual 30 minutes: the designated time frame of the meeting as an experiment is ending and thus I'd like to spend some time for reflection in addition to the regular meeting. If you can, please prepare your thoughts about the meeting: what you like or didn't like, what works for you, and what doesn't work, suggestions or questiosn you have. Last week's summary is here: https://mail.zope.org/pipermail/zope-dev/attachments/20100327/e26f6a8c/attac... Agenda ------ - Bug tracking - working on bugs regularly - keeping an eye on the situation - How do we deal with proposed API changes and Python 3 compatibility? (Lennart Regebro) - Review off weekly meeting experiment Ongoing issues -------------- Those issues are currently ongoing. We don't have to discuss them. We just need to follow up on them eventually. - Test runners / nightly buids - Bootstrapping the coordinator volunteer. Clarify responsibilities and current tasks. - Towards a list of projects/platforms/etc. we want guaranteed builds for. - Automatic binary egg builds for Windows - Access to Windows build machine for developers (AMI) - Access to Visual Studio license for the build machine - Bug tracking - Temporary restructuring of ZTK packages into single project (ctheune) - Long-term restructuring of LP packages into individual projects and project group - Triaging Z3 bugs into ZTK, closing Z3 tracker then. - Towards a ZTK release - Establishing ZTK release engineering team (Z2, grok, BB) - Documentation - Release scope Horizon ------- These items are currently tracked on the horizon. We won't discuss them at this meeting, but we'll get to them at some point: - Pondering *some* (re-)structuring of the ZTK to allow for better maintenance/release management/communication/marketing. (Chris McDonough) -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi, On 03/30/2010 11:09 AM, Christian Theune wrote:
Hi everyone,
today's the fifth weekly meeting and I hope to see you around 3pm UTC at #zope at freenode. (Still a few hours to go.)
aaaaand ... I screwed up the DST switch and started the meeting an hour early. I didn't notice, though, because quite a few people joined in, still. We're currently in meta mode discussing the meetings itself, just in case you wanna jump in. Sorry, Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hello Christian, One point for the next agenda: As Marius also had the issue to do a KGS 3.4.1. Do we want to do that? Tuesday, March 30, 2010, 11:09:05 AM, you wrote: ... -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: To ease another's heartache is to forget one's own. - Abraham Lincoln
On 03/31/2010 12:35 PM, Adam GROSZER wrote:
Hello Christian,
One point for the next agenda: As Marius also had the issue to do a KGS 3.4.1. Do we want to do that?
I can put it on the agenda, but it sounds like that could also be discussed on the mailinglist. I don't want to get rid of the mailinglist - I'd just like to provide an additional channel of communication. So there's no need to wait. Just ask on the list and if that doesn't work out, we'll discuss it in the weekly meeting. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
On Wed, Mar 31, 2010 at 01:37:47PM +0200, Christian Theune wrote:
On 03/31/2010 12:35 PM, Adam GROSZER wrote:
One point for the next agenda: As Marius also had the issue to do a KGS 3.4.1.
Mostly I wanted to know if anybody was using the KGS in production and interested in a point release. IRC seemed the right place for a straw poll before an email to zope-dev@, except that I had to run sooner than I thought so I didn't see how people reacted. I recently looked at the zope.release 3.4 branch and saw that it has a bunch of updated package versions since the 3.4.0 release (which was in January 2009). I'm especially interested in setuptools 0.6c11, since the KGS currently pins to 0.6c9, which doesn't support Subversion 1.6 checkouts. We use the 3.4 KGS in production with a few extra pins. Some fix important bugs: zope.app.component = 3.4.2 # very important bugfix for BBB ZODB3 = 3.8.4 # security fixes zope.sendmail = 3.5.1 # This version handles the 5xx errors zope.security = 3.4.2 # bugfixes for Python 2.5 setuptools = 0.6c11 then there are the "we just want the latest tools" pins for zc.buildout and zope.testing, which I'm not proposing to push into a KGS point update (especially with the zope.testing.doctest deprecation which pushes people into using buggy stdlib's doctest). I'm also interested in a bugfix for zope.sendmail that's not done yet: currently it starts the background mail processing thread even if do things like bin/development-instance debug. This can result in emails sent out twice. It also doesn't let the process quit, due to changes in Python's 2.5 threading semantics (atexit handlers that are trying to stop the background thread now are postponed until after all threads terminate). The latest zope.sendmail can avoid this mess by disabling the delivery thread and using a standalone thread-watching script, but it depends on newer core packages and is incompatible with the 3.4 KGS. The 3.4 buildbot tracks the tip of the zope.release's 3.4 branch. All tests pass there. I see that zope.app.component 3.4.2 and setuptools 0.6c11 are already in the (unreleased) 3.4 KGS; ZODB3 3.8.4, zope.sendmail 3.5.1 and zope.security 3.4.2 aren't. So, my plan of action is: * fix zope.sendmail using the approach discussed on this list a few weeks ago * look at other possible bugfix upgrades, see if there are any important bugs fixed (zope.release's bin/list-latest is useful here) * bump ZODB3, zope.sendmail, zope.security versions in the 3.4 KGS, see what buildbot things of this * try to get a 3.4.1 release out of the door <-- this is where I'm fuzzy. I think I used to have ssh access to download.zope.org, but I don't even remember how you're supposed to use zope.release's bin/upload, and I never knew how the releases were made. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
Hi, Marius Gedminas a écrit :
On Wed, Mar 31, 2010 at 01:37:47PM +0200, Christian Theune wrote:
On 03/31/2010 12:35 PM, Adam GROSZER wrote:
One point for the next agenda: As Marius also had the issue to do a KGS 3.4.1.
Mostly I wanted to know if anybody was using the KGS in production and interested in a point release.
I do I'm already using all the minor versions upgrades, this is also some kind of unreleased 3.4.1.
So, my plan of action is:
* fix zope.sendmail using the approach discussed on this list a few weeks ago
* look at other possible bugfix upgrades, see if there are any important bugs fixed (zope.release's bin/list-latest is useful here)
It would be good to have a tool (bin/upgrade-minor or something) to upgrade package versions of a buildout to the highest minor release available. I remember that bin/list-latest only works for the Maybe it already exists?
* bump ZODB3, zope.sendmail, zope.security versions in the 3.4 KGS, see what buildbot things of this
* try to get a 3.4.1 release out of the door <-- this is where I'm fuzzy. I think I used to have ssh access to download.zope.org, but I don't even remember how you're supposed to use zope.release's bin/upload, and I never knew how the releases were made.
I had helped a bit for the 3.4.0 release, I still remember a few things, particularly about zope.release or zope.kgs. However I did'nt have any ssh access. But I can probably help. Christophe
Marius Gedminas
On Wed, Mar 31, 2010 at 14:50, Marius Gedminas <marius@gedmin.as> wrote:
Mostly I wanted to know if anybody was using the KGS in production and interested in a point release.
Yes! :)
I'm especially interested in setuptools 0.6c11, since the KGS currently pins to 0.6c9, which doesn't support Subversion 1.6 checkouts.
we use distribute w/o issue.
We use the 3.4 KGS in production with a few extra pins. Some fix important bugs:
zope.app.component = 3.4.2 # very important bugfix for BBB ZODB3 = 3.8.4 # security fixes zope.sendmail = 3.5.1 # This version handles the 5xx errors zope.security = 3.4.2 # bugfixes for Python 2.5 setuptools = 0.6c11
our vendor KGS: lxml = 2.2.2 tl.eggdeps = 0.4 transaction = 1.0a1 z3c.batching = 1.1.0 z3c.contents = 0.5.0 z3c.coverage = 1.1.3 z3c.etestbrowser = 1.3.0 z3c.evalexception = 2.0 z3c.i18n = 0.1.1 z3c.layer.minimal = 1.2.0 z3c.layer.pagelet = 1.0.1 z3c.profiler = 0.7.1 z3c.recipe.compattest = 0.11 z3c.recipe.depgraph = 0.4.0sa1 z3c.recipe.i18n = 0.5.4 z3c.recipe.paster = 0.5.0 z3c.table = 0.6.0 z3c.testsetup = 0.5.1 zc.recipe.egg = 1.2.2 zope.sqlalchemy = 0.4 zope.testing = 3.8.3sa1 lxml, zope.testing & zope.etestbrowser are the most important update I guess.
* try to get a 3.4.1 release out of the door <-- this is where I'm fuzzy. I think I used to have ssh access to download.zope.org, but I don't even remember how you're supposed to use zope.release's bin/upload, and I never knew how the releases were made.
it's simple: - upload all eggs on the cheeseshop - create the controled-packages.cfg. Example: http://download.zope.org/zope3.4/3.4.0/controlled-packages.cfg - generate the site with zope.kgs -- Sebastien Douche <sdouche@gmail.com> Twitter: http://bit.ly/afkrK (agile, python, open source)
Sebastien Douche a écrit :
On Wed, Mar 31, 2010 at 14:50, Marius Gedminas <marius@gedmin.as> wrote:
Mostly I wanted to know if anybody was using the KGS in production and interested in a point release.
Yes! :)
I'm especially interested in setuptools 0.6c11, since the KGS currently pins to 0.6c9, which doesn't support Subversion 1.6 checkouts.
we use distribute w/o issue.
We use the 3.4 KGS in production with a few extra pins. Some fix important bugs:
zope.app.component = 3.4.2 # very important bugfix for BBB ZODB3 = 3.8.4 # security fixes zope.sendmail = 3.5.1 # This version handles the 5xx errors zope.security = 3.4.2 # bugfixes for Python 2.5 setuptools = 0.6c11
our vendor KGS:
lxml = 2.2.2 tl.eggdeps = 0.4 transaction = 1.0a1 z3c.batching = 1.1.0 z3c.contents = 0.5.0 z3c.coverage = 1.1.3 z3c.etestbrowser = 1.3.0 z3c.evalexception = 2.0 z3c.i18n = 0.1.1 z3c.layer.minimal = 1.2.0 z3c.layer.pagelet = 1.0.1
There is a big security issue on this package. You should update to 1.0.2 as soon as possible 1.0.2 (2009-04-03) --------------------- http://pypi.python.org/pypi/z3c.layer.pagelet/1.0.2 - **Security issue:** The traverser defined for ``IPageletBrowserLayer`` was a trusted adapter, so the security proxy got removed from each traversed object. Thus all sub-objects were publically accessable, too. Then have fun fixing all the security declaration. Everything seems easy with z3c.layer.pagelet 1.0.1
z3c.profiler = 0.7.1 z3c.recipe.compattest = 0.11 z3c.recipe.depgraph = 0.4.0sa1 z3c.recipe.i18n = 0.5.4 z3c.recipe.paster = 0.5.0 z3c.table = 0.6.0 z3c.testsetup = 0.5.1 zc.recipe.egg = 1.2.2 zope.sqlalchemy = 0.4 zope.testing = 3.8.3sa1
lxml, zope.testing & zope.etestbrowser are the most important update I guess.
* try to get a 3.4.1 release out of the door <-- this is where I'm fuzzy. I think I used to have ssh access to download.zope.org, but I don't even remember how you're supposed to use zope.release's bin/upload, and I never knew how the releases were made.
it's simple: - upload all eggs on the cheeseshop - create the controled-packages.cfg. Example: http://download.zope.org/zope3.4/3.4.0/controlled-packages.cfg - generate the site with zope.kgs
Hello Marius, +1 on a KGS 3.4.1 Local overrides here: zope.component = 3.5.1 zope.contenttype = 3.4.2 zope.i18n = 3.5.0 zope.sendmail = 3.5.0 zope.server = 3.5.0 zope.session = 3.5.2 zope.tal = 3.5.0 zope.testing = 3.7.5 #was 3.7.0 but let's try this zope.traversing = 3.5.0a4 zope.testbrowser = 3.5 #mechanize changed the HTTPError class zope.app.appsetup = 3.6.0 zope.app.container = 3.6.0 zope.app.form = 3.5.0 zope.app.intid = 3.5.0 zope.app.publisher = 3.5.0a4 zope.app.wsgi = 3.4.2 #fixes product config zope.app.http = 3.4.5 #fixes IDefaultView vs. PROPFIND lxml = 2.2.4 #or something that works on win32 I might backport a bugfix in zope.publisher r101467 zc.buildout is a tough decision, because it's "not upgrading" issue. See http://mail.python.org/pipermail/distutils-sig/2010-March/015794.html What's the schedule? Wednesday, March 31, 2010, 2:50:33 PM, you wrote: MG> On Wed, Mar 31, 2010 at 01:37:47PM +0200, Christian Theune wrote:
On 03/31/2010 12:35 PM, Adam GROSZER wrote:
One point for the next agenda: As Marius also had the issue to do a KGS 3.4.1.
MG> Mostly I wanted to know if anybody was using the KGS in production and MG> interested in a point release. IRC seemed the right place for a straw MG> poll before an email to zope-dev@, except that I had to run sooner than MG> I thought so I didn't see how people reacted. MG> I recently looked at the zope.release 3.4 branch and saw that it has a MG> bunch of updated package versions since the 3.4.0 release (which was in MG> January 2009). I'm especially interested in setuptools 0.6c11, since MG> the KGS currently pins to 0.6c9, which doesn't support Subversion 1.6 MG> checkouts. MG> We use the 3.4 KGS in production with a few extra pins. Some fix MG> important bugs: MG> zope.app.component = 3.4.2 # very important bugfix for BBB MG> ZODB3 = 3.8.4 # security fixes MG> zope.sendmail = 3.5.1 # This version handles the 5xx errors MG> zope.security = 3.4.2 # bugfixes for Python 2.5 MG> setuptools = 0.6c11 MG> then there are the "we just want the latest tools" pins for zc.buildout MG> and zope.testing, which I'm not proposing to push into a KGS point MG> update (especially with the zope.testing.doctest deprecation which MG> pushes people into using buggy stdlib's doctest). MG> I'm also interested in a bugfix for zope.sendmail that's not done yet: MG> currently it starts the background mail processing thread even if do MG> things like bin/development-instance debug. This can result in emails MG> sent out twice. It also doesn't let the process quit, due to changes in MG> Python's 2.5 threading semantics (atexit handlers that are trying to MG> stop the background thread now are postponed until after all threads MG> terminate). The latest zope.sendmail can avoid this mess by disabling MG> the delivery thread and using a standalone thread-watching script, but MG> it depends on newer core packages and is incompatible with the 3.4 KGS. MG> The 3.4 buildbot tracks the tip of the zope.release's 3.4 branch. All MG> tests pass there. I see that zope.app.component 3.4.2 and setuptools MG> 0.6c11 are already in the (unreleased) 3.4 KGS; ZODB3 3.8.4, MG> zope.sendmail 3.5.1 and zope.security 3.4.2 aren't. MG> So, my plan of action is: MG> * fix zope.sendmail using the approach discussed on this list a few MG> weeks ago MG> * look at other possible bugfix upgrades, see if there are any MG> important bugs fixed (zope.release's bin/list-latest is useful here) MG> * bump ZODB3, zope.sendmail, zope.security versions in the 3.4 KGS, see MG> what buildbot things of this MG> * try to get a 3.4.1 release out of the door <-- this is where I'm MG> fuzzy. I think I used to have ssh access to download.zope.org, but I MG> don't even remember how you're supposed to use zope.release's bin/upload, MG> and I never knew how the releases were made. MG> Marius Gedminas -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: Top ten things you'll never hear in an internet chat room: 6. You know, to get a really fast connection, you've gotta go through America Online.
On 4/2/10 10:36 , Adam GROSZER wrote:
zc.buildout is a tough decision, because it's "not upgrading" issue. See http://mail.python.org/pipermail/distutils-sig/2010-March/015794.html
Why would you ever install zc.buildout systemwide? Just as with setuptools I consider that to be a recipe for problems. Wichert.
Hello Wichert, Because of our toolchain to release and deploy apps: mypypi and keas.build. In fact, because of keas.build depends on zc.buildout. Friday, April 2, 2010, 10:53:26 AM, you wrote: WA> On 4/2/10 10:36 , Adam GROSZER wrote:
zc.buildout is a tough decision, because it's "not upgrading" issue. See http://mail.python.org/pipermail/distutils-sig/2010-March/015794.html
WA> Why would you ever install zc.buildout systemwide? Just as with WA> setuptools I consider that to be a recipe for problems. WA> Wichert. WA> _______________________________________________ WA> Zope-Dev maillist - Zope-Dev@zope.org WA> https://mail.zope.org/mailman/listinfo/zope-dev WA> ** No cross posts or HTML encoding! ** WA> (Related lists - WA> https://mail.zope.org/mailman/listinfo/zope-announce WA> https://mail.zope.org/mailman/listinfo/zope ) -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: One man tells a falsehood, a hundred repeat it as true.
A: Because it makes the logic of the discussion difficult to follow. Q: Why shouldn't I top post? A: No. Q: Should I top post? On Fri, Apr 02, 2010 at 12:29:48PM +0200, Adam GROSZER wrote:
Hello Wichert,
Because of our toolchain to release and deploy apps: mypypi and keas.build. In fact, because of keas.build depends on zc.buildout.
Friday, April 2, 2010, 10:53:26 AM, you wrote:
WA> On 4/2/10 10:36 , Adam GROSZER wrote:
zc.buildout is a tough decision, because it's "not upgrading" issue. See http://mail.python.org/pipermail/distutils-sig/2010-March/015794.html
WA> Why would you ever install zc.buildout systemwide? Just as with WA> setuptools I consider that to be a recipe for problems.
Why not do python2.x bootstrap.py and then use bin/buildout instead of the globally-installed buildout? Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
Hello Marius, Friday, April 2, 2010, 3:02:53 PM, you wrote: MG> On Fri, Apr 02, 2010 at 12:29:48PM +0200, Adam GROSZER wrote:
Hello Wichert,
Because of our toolchain to release and deploy apps: mypypi and keas.build. In fact, because of keas.build depends on zc.buildout.
Friday, April 2, 2010, 10:53:26 AM, you wrote:
WA> On 4/2/10 10:36 , Adam GROSZER wrote:
zc.buildout is a tough decision, because it's "not upgrading" issue. See http://mail.python.org/pipermail/distutils-sig/2010-March/015794.html
WA> Why would you ever install zc.buildout systemwide? Just as with WA> setuptools I consider that to be a recipe for problems.
MG> Why not do MG> python2.x bootstrap.py MG> and then use MG> bin/buildout MG> instead of the globally-installed buildout? MG> Marius Gedminas The way you install your app with is: $ install -u https://build.twollo.com/buildouts/ -p Twollo -V QA --latest Where the install script comes with keas.build. At this point nothing exists from your app on the server, not even a .cfg or svn checkout. This invokes "buildout -c https://build.twollo.com/buildouts/Twollo-QA-2.3.4.cfg -t 2...." or something like this. (See http://pypi.python.org/pypi/keas.build/0.1.6 for details) That will gather all necessary packages from (your private) pypi server. And that's why I would need zc.buildout installed globally. It seems to be rather easier to do on a new server: <install setuptools> $ easy_install zc.buildout==<whatever version> $ easy_install keas.build $ install <my favourite app's install parameters> and done I know, doing a checkout and bin/buildout sounds easier, but there's a lot more behind keas.build than just ``install``. The actual problem is that zc.buildout launched by keas.build must be the same version as pinned in the .cfg. A long story... Maybe I just should kick zc.buildout to upgrade itself in the above situation. That would be the best on the long run. -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: Keep your fears for yourself, but share your courage with others. - Robert Louis Stevenson
On 4/2/10 16:23 , Adam GROSZER wrote:
The way you install your app with is:
$ install -u https://build.twollo.com/buildouts/ -p Twollo -V QA --latest
Where the install script comes with keas.build. At this point nothing exists from your app on the server, not even a .cfg or svn checkout. This invokes "buildout -c https://build.twollo.com/buildouts/Twollo-QA-2.3.4.cfg -t 2...." or something like this.
Perhaps keas.build could be modified to create a virtualenv and install buildout in there? That shouldn't be too hard to do. Wichert.
On Fri, Apr 02, 2010 at 04:23:25PM +0200, Adam GROSZER wrote:
MG> On Fri, Apr 02, 2010 at 12:29:48PM +0200, Adam GROSZER wrote:
Hello Wichert,
Because of our toolchain to release and deploy apps: mypypi and keas.build. In fact, because of keas.build depends on zc.buildout.
Friday, April 2, 2010, 10:53:26 AM, you wrote:
WA> On 4/2/10 10:36 , Adam GROSZER wrote:
zc.buildout is a tough decision, because it's "not upgrading" issue. See http://mail.python.org/pipermail/distutils-sig/2010-March/015794.html
WA> Why would you ever install zc.buildout systemwide? Just as with WA> setuptools I consider that to be a recipe for problems.
MG> Why not do
MG> python2.x bootstrap.py
MG> and then use
MG> bin/buildout
MG> instead of the globally-installed buildout?
MG> Marius Gedminas
The way you install your app with is:
$ install -u https://build.twollo.com/buildouts/ -p Twollo -V QA --latest
Where the install script comes with keas.build.
Overriding the standard Unix 'install' command is not a good idea IMHO. In fact it's a Bad Idea.
At this point nothing exists from your app on the server, not even a .cfg or svn checkout. This invokes "buildout -c https://build.twollo.com/buildouts/Twollo-QA-2.3.4.cfg -t 2...." or something like this. (See http://pypi.python.org/pypi/keas.build/0.1.6 for details) That will gather all necessary packages from (your private) pypi server.
An interesting approach. Looks quite reasonable from first sight.
And that's why I would need zc.buildout installed globally. It seems to be rather easier to do on a new server: <install setuptools> $ easy_install zc.buildout==<whatever version> $ easy_install keas.build $ install <my favourite app's install parameters> and done
I know, doing a checkout and bin/buildout sounds easier, but there's a lot more behind keas.build than just ``install``.
The actual problem is that zc.buildout launched by keas.build must be the same version as pinned in the .cfg.
Maybe it would make sense to add a command-line option for buildout to override version pins? bin/buildout -t 2 -c configfile --pin zc.buildout=1.4.3 \ --pin setuptools=0.9c11 with "--pin zc.buildout=" meaning "use latest version, disregarding the pin in the config file."
A long story... Maybe I just should kick zc.buildout to upgrade itself in the above situation. That would be the best on the long run.
Or that. Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
On Fri, Apr 2, 2010 at 10:51 AM, Marius Gedminas <marius@gedmin.as> wrote:
Maybe it would make sense to add a command-line option for buildout to override version pins?
bin/buildout -t 2 -c configfile --pin zc.buildout=1.4.3 \ --pin setuptools=0.9c11
with "--pin zc.buildout=" meaning "use latest version, disregarding the pin in the config file."
Already implemented: bin/buildout -t 2 -c configfile \ versions:zc.buildout=1.4.3 \ versions:setuptools=0.9c11 -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
On Friday 02 April 2010, Marius Gedminas wrote:
Why not do
python2.x bootstrap.py
and then use
bin/buildout
instead of the globally-installed buildout?
I definitely hear you. On the other hand, I think of buildout as a replacement for make. And I would not want to install a special make either on a machine. They key here is that the deployment and staging servers have very minimal setups. And there you just want to install a package that gets you going. Regards, Stephan -- Entrepreneur and Software Geek Google me. "Zope Stephan Richter"
Hello Marius, Just released zope.publisher 3.4.10. Seems to have a LOT of fixes vs. 3.4.6 Wednesday, March 31, 2010, 2:50:33 PM, you wrote: ... -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: Civilization is a movement, not a condition; it is a voyage, not a harbor. - Toynbee
Hello Marius, Wednesday, March 31, 2010, 2:50:33 PM, you wrote: ... MG> * look at other possible bugfix upgrades, see if there are any MG> important bugs fixed (zope.release's bin/list-latest is useful here) ... I created a sheet with versions http://spreadsheets.google.com/pub?key=tUE5Q72d4Kg1FXaacCA3EKQ&output=html Right now it's a sort of highest version affordable after a quick scan through the version. I'm thinking about doing one more round to take a closer look and probably screw some versions back. -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: We die only once, and for such a long time. - Moliere
AG> I created a sheet with versions AG> http://spreadsheets.google.com/pub?key=tUE5Q72d4Kg1FXaacCA3EKQ&output=html AG> Right now it's a sort of highest version affordable after a quick scan AG> through the version. I'm thinking about doing one more round to take a AG> closer look and probably screw some versions back. I did one more round on it. The open questions that remain: * What about pytz 2010g? * Which lxml version to take? 1.3.6? * What about zope.app.container 3.6.2? * Would be nice to have zope.testbrowser 3.5.1 Anyone for/against those versions? -- Best regards, Adam GROSZER mailto:agroszer@gmail.com -- Quote of the day: There is nothing except what you sense
participants (8)
-
Adam GROSZER -
Christian Theune -
Christophe Combelles -
Fred Drake -
Marius Gedminas -
Sebastien Douche -
Stephan Richter -
Wichert Akkerman