Reminder: feature freeze November 1.
This is a reminder that there will be a feature freeze for the December Zope releases on November 1. No new features for the November releases should be added after October 31. The Zope trunks should be stable and ready for a beta release on November 1. We are committed to time-based releases. This means we need to be very disciplined about deadlines. If a cool new feature isn't quite ready before November 1, then it could be be included in the June release, for which the feature freeze will be May 1. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
This is a reminder that there will be a feature freeze for the December Zope releases on November 1. No new features for the November releases should be added after October 31. The Zope trunks should be stable and ready for a beta release on November 1.
We are committed to time-based releases. This means we need to be very disciplined about deadlines. If a cool new feature isn't quite ready before November 1, then it could be be included in the June release, for which the feature freeze will be May 1.
Cool. I like the way the Ubuntu guys describe their freeze / process: http://lists.ubuntu.com/archives/ubuntu-devel/2005-February/004077.html I don't know what would qualify for "release goals" versus "targets of opportunity" for this cycle, though. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDVN/m+gerLs4ltQ4RAnc2AJ9zcULEgze+3to3Iqmy5xU2QAisfwCfSzy3 4r40IYdK4ytScTAXObp3cgk= =hzGm -----END PGP SIGNATURE-----
Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
This is a reminder that there will be a feature freeze for the December Zope releases on November 1. No new features for the November releases should be added after October 31. The Zope trunks should be stable and ready for a beta release on November 1.
We are committed to time-based releases. This means we need to be very disciplined about deadlines. If a cool new feature isn't quite ready before November 1, then it could be be included in the June release, for which the feature freeze will be May 1.
Cool. I like the way the Ubuntu guys describe their freeze / process:
http://lists.ubuntu.com/archives/ubuntu-devel/2005-February/004077.html
I don't know what would qualify for "release goals" versus "targets of opportunity" for this cycle, though.
Me neither. I have a sense that they are being a lot more formal about their process than we are though. Perhaps we should be more formal, but I kind of doubt it. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Tue, Oct 18, 2005 at 07:21:08AM -0400, Jim Fulton wrote:
This is a reminder that there will be a feature freeze for the December Zope releases on November 1.
OK. I thought there was going to be a 2.9 branch by now, but I don't see one. Is the trunk totally frozen now or what? Is it too late to land my long-forgotten configure changes as discussed at http://mail.zope.org/pipermail/zope/2004-July/151839.html ? This would allow multiple "preferred" versions of Python when a bugfix release of python comes out - so we don't do something silly like advise people to downgrade from a perfectly good 2.4.x to 2.4.(x-1). I negligently never merged my branch, forgot about it, and only remembered it when Florent nudged us to clean up old branches. I have a local zope 2 trunk sandbox with my changes hand-merged into configure, but my branch is so ancient that I think I should delete it and start over. -- Paul Winkler http://www.slinkp.com
I suspect there's just some miscommunication about who is actually supposed to make the branch. I have just gone ahead and made it. But yes, now that there is one, the 2.9 branch is frozen for features. - C On Sat, 2005-11-12 at 14:56 -0500, Paul Winkler wrote:
On Tue, Oct 18, 2005 at 07:21:08AM -0400, Jim Fulton wrote:
This is a reminder that there will be a feature freeze for the December Zope releases on November 1.
OK. I thought there was going to be a 2.9 branch by now, but I don't see one. Is the trunk totally frozen now or what?
Is it too late to land my long-forgotten configure changes as discussed at http://mail.zope.org/pipermail/zope/2004-July/151839.html ?
This would allow multiple "preferred" versions of Python when a bugfix release of python comes out - so we don't do something silly like advise people to downgrade from a perfectly good 2.4.x to 2.4.(x-1).
I negligently never merged my branch, forgot about it, and only remembered it when Florent nudged us to clean up old branches. I have a local zope 2 trunk sandbox with my changes hand-merged into configure, but my branch is so ancient that I think I should delete it and start over.
On Sat, Nov 12, 2005 at 09:59:45PM -0500, Chris McDonough wrote:
I suspect there's just some miscommunication about who is actually supposed to make the branch. I have just gone ahead and made it.
But yes, now that there is one, the 2.9 branch is frozen for features.
Which means I can now land stuff on the trunk again? :-) -PW -- Paul Winkler http://www.slinkp.com
Yep, it's a free-for-all again. ;-) Although probably it's better to create a branch and get some consensus before merging it as opposed to landing stuff directly on the trunk. On Sat, 2005-11-12 at 22:14 -0500, Paul Winkler wrote:
On Sat, Nov 12, 2005 at 09:59:45PM -0500, Chris McDonough wrote:
I suspect there's just some miscommunication about who is actually supposed to make the branch. I have just gone ahead and made it.
But yes, now that there is one, the 2.9 branch is frozen for features.
Which means I can now land stuff on the trunk again?
:-)
-PW
Chris McDonough wrote:
I suspect there's just some miscommunication about who is actually supposed to make the branch. I have just gone ahead and made it.
But yes, now that there is one, the 2.9 branch is frozen for features.
I wish you hadn't done that. We shouldn't be making the branch until we get to beta. We can't get to beta until a lot more bugs are fixed. Everyone likes to work on new features, but we need to get bug fixed to actually make releases. I'm worried that we aren't going to make the time-based release schedule. The only leverage I can see is feature freezes. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Sunday 13 November 2005 10:48, Jim Fulton wrote:
Chris McDonough wrote:
I suspect there's just some miscommunication about who is actually supposed to make the branch. I have just gone ahead and made it.
But yes, now that there is one, the 2.9 branch is frozen for features.
I wish you hadn't done that. We shouldn't be making the branch until we get to beta. We can't get to beta until a lot more bugs are fixed. Everyone likes to work on new features, but we need to get bug fixed to actually make releases. I'm worried that we aren't going to make the time-based release schedule. The only leverage I can see is feature freezes.
Jim, I am really glad you wrote this comment. I was going to write a similar E-mail, but thought it would be out of line for me, since I am not involved in the Zope 2 development. If someone would have done that with Zope 3, I would have been pretty annoyed. Thus for Zope 3, if someone creates a release branch without discussing it with me first, then that person automatically becomes the release manager for that release. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training
Stephan Richter wrote:
On Sunday 13 November 2005 10:48, Jim Fulton wrote:
Chris McDonough wrote:
I suspect there's just some miscommunication about who is actually supposed to make the branch. I have just gone ahead and made it.
But yes, now that there is one, the 2.9 branch is frozen for features.
I wish you hadn't done that. We shouldn't be making the branch until we get to beta. We can't get to beta until a lot more bugs are fixed. Everyone likes to work on new features, but we need to get bug fixed to actually make releases. I'm worried that we aren't going to make the time-based release schedule. The only leverage I can see is feature freezes.
Jim, I am really glad you wrote this comment. I was going to write a similar E-mail, but thought it would be out of line for me, since I am not involved in the Zope 2 development.
If someone would have done that with Zope 3, I would have been pretty annoyed. Thus for Zope 3, if someone creates a release branch without discussing it with me first, then that person automatically becomes the release manager for that release.
Yup. BTW, I'm sure Chris meant well. Chris, I appreciate that you were trying to help. I still wish you hadn't made the branch. :) Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
On Sun, 2005-11-13 at 17:32 +0100, Andreas Jung wrote:
--On 13. November 2005 11:26:44 -0500 Jim Fulton <jim@zope.com> wrote:
Chris,
I appreciate that you were trying to help. I still wish you hadn't made the branch. :)
svn delete should solve that problem :-)
Of course the release manager should have the last say and as the release manager it's totally valid for Andreas to delete the branch. Apologies for taking initiative. I was really just trying to unstick Paul and get things rolling again. But I'd like to understand the rationale for not branching at the time if the feature freeze (Nov 1). Is it just to avoid the work of merging changes from the branch back the HEAD during the period between the freeze and the beta? Doesn't svn make this pretty easy? And what is the maximum amount of time between freeze and beta that we'd consider reasonable? Also, it sounds as if there's an argument being made that *everyone* should pitch in to get 2.9 beta out the door *instead* of committing Zope 2 feature work and the delayed branching is the manifestation of "legislation" that aims to make this happen. I'm not sure it's healthy to legislate this. There are people who have no burning desire to see a 2.9 go out the door within the next few weeks, but OTOH they are very willing to commit some valuable feature work right now for an eventual 2.10 release and due to the freeze, they haven't done so (and may never do so if not now, given the volunteer-ness of their efforts). How can we accomodate those people in the future? IMO, we should try not to discourage contribution and so we should branch regardless of the state of the trunk within, say, two weeks of freeze. Does that sound reasonable for future releases? - C
--On 13. November 2005 14:55:22 -0500 Chris McDonough <chrism@plope.com> wrote:
But I'd like to understand the rationale for not branching at the time if the feature freeze (Nov 1). Is it just to avoid the work of merging changes from the branch back the HEAD during the period between the freeze and the beta? Doesn't svn make this pretty easy? And what is the maximum amount of time between freeze and beta that we'd consider reasonable?
I think all people involved in 2.9 should get their contributions right on the trunk. Then we can branch. Fixing stuff on multiple branches is a pain. You could create a temporary branch for your stuff and merge it back into the HEAD when the 2.9 branch. I think Jim came up with idea to develop new features on a branch. Branches aka new features should be merged into the HEAD if they are considered to be stable. The reason for this approach but be to have the HEAD in a reasonable stable state and to be able to cut a release branch at any time. Andreas
On Sun, 2005-11-13 at 21:07 +0100, Andreas Jung wrote:
Branches aka new features should be merged into the HEAD if they are considered to be stable. The reason for this approach but be to have the HEAD in a reasonable stable state and to be able to cut a release branch at any time.
Yup. That's exactly what appears to not be happening at the moment, so I'm confused. The critical issues that are listed in the collector are bugs and not problems created by feature creep. Do those sorts of issues prevent a branch from being made? Or are there other issues that aren't in the collector that are preventing a branch from being made? - C
On Sun, 2005-11-13 at 15:20 -0500, Chris McDonough wrote:
On Sun, 2005-11-13 at 21:07 +0100, Andreas Jung wrote:
Branches aka new features should be merged into the HEAD if they are considered to be stable. The reason for this approach but be to have the HEAD in a reasonable stable state and to be able to cut a release branch at any time.
Yup. That's exactly what appears to not be happening at the moment, so I'm confused. The critical issues that are listed in the collector are bugs and not problems created by feature creep. Do those sorts of issues prevent a branch from being made? Or are there other issues that aren't in the collector that are preventing a branch from being made?
I don't know if those bugs should prevent a beta or not. But there needs to be some criteria other than feature completeness. Is Zope 2 really in good shape? Or do people just not care? Jim
On Sun, 2005-11-13 at 16:42 -0500, Jim Fulton wrote:
I don't know if those bugs should prevent a beta or not. But there needs to be some criteria other than feature completeness.
To create the branch or a beta release? I realize there's a desire to tie these acts together but still don't fully understand the rationale for that after rereading your posts as you suggested. I don't want to belabor the point, though, so just call "pope" at any time and I'll stop, at least for today. ;-)
Is Zope 2 really in good shape? Or do people just not care?
Maybe both? ;-) I'm currently investigating #1685, so that should be resolved one way or another today. There is one other public bug that doesn't appear to be a showstopper. There are some private bugs too that I haven't looked at. I just noticed Phil's post on the zope3 list where he enumerates what needs to be done for Five/zpkg. None of that is in the collector. There is a Wiki at http://www.zope.org/Wikis/DevSite/Projects/Zope2.9/FrontPage . It doesn't have much info in it. I've made it accessible via http://www.zope.org/DevHome/Projects/ now so maybe those who have things to finish up can enumerate what needs to be done there before a beta can be released. - C
On Sun, 2005-11-13 at 17:07 -0500, Chris McDonough wrote:
On Sun, 2005-11-13 at 16:42 -0500, Jim Fulton wrote:
I don't know if those bugs should prevent a beta or not. But there needs to be some criteria other than feature completeness.
To create the branch or a beta release? I realize there's a desire to tie these acts together but still don't fully understand the rationale for that after rereading your posts as you suggested. I don't want to belabor the point, though, so just call "pope" at any time and I'll stop, at least for today. ;-)
Ignore this. You called pope in another message. - C
On Sun, 2005-11-13 at 14:55 -0500, Chris McDonough wrote:
On Sun, 2005-11-13 at 17:32 +0100, Andreas Jung wrote:
...
Also, it sounds as if there's an argument being made that *everyone* should pitch in to get 2.9 beta out the door *instead* of committing Zope 2 feature work and the delayed branching is the manifestation of "legislation" that aims to make this happen.
Yup. You figured it out.
I'm not sure it's healthy to legislate this.
I'm not sure either, but we have to try something.
There are people who have no burning desire to see a 2.9 go out the door within the next few weeks, but OTOH they are very willing to commit some valuable feature work right now for an eventual 2.10 release and due to the freeze, they haven't done so (and may never do so if not now, given the volunteer-ness of their efforts).
OK, then there will be less for the people who are willing to fix bugs to work on later.
How can we accomodate those people in the future?
They can always work on a development branch.
IMO, we should try not to discourage contribution and so we should branch regardless of the state of the trunk within, say, two weeks of freeze. Does that sound reasonable for future releases?
Not to me. Jim
On Sun, Nov 13, 2005 at 02:55:22PM -0500, Chris McDonough wrote:
Of course the release manager should have the last say and as the release manager it's totally valid for Andreas to delete the branch. Apologies for taking initiative. I was really just trying to unstick Paul and get things rolling again.
Thanks Chris, I didn't mean for you to get you in hot water. And thanks Jim for directly answering my question, which is really all I needed :) -- Paul Winkler http://www.slinkp.com
On Sun, 2005-11-13 at 11:26 -0500, Jim Fulton wrote:
Stephan Richter wrote:
On Sunday 13 November 2005 10:48, Jim Fulton wrote:
Chris McDonough wrote:
I suspect there's just some miscommunication about who is actually supposed to make the branch. I have just gone ahead and made it.
But yes, now that there is one, the 2.9 branch is frozen for features.
I wish you hadn't done that. We shouldn't be making the branch until we get to beta. We can't get to beta until a lot more bugs are fixed. Everyone likes to work on new features, but we need to get bug fixed to actually make releases. I'm worried that we aren't going to make the time-based release schedule. The only leverage I can see is feature freezes.
Jim, I am really glad you wrote this comment. I was going to write a similar E-mail, but thought it would be out of line for me, since I am not involved in the Zope 2 development.
If someone would have done that with Zope 3, I would have been pretty annoyed. Thus for Zope 3, if someone creates a release branch without discussing it with me first, then that person automatically becomes the release manager for that release.
Yup.
BTW, I'm sure Chris meant well.
Chris,
I appreciate that you were trying to help. I still wish you hadn't made the branch. :)
Yes, I predicted I'd be punished. ;-) I don't understand why you would want to wait to make a release branch until a beta. What is the rationale? - C
On Sun, 2005-11-13 at 12:38 -0500, Chris McDonough wrote:
On Sun, 2005-11-13 at 11:26 -0500, Jim Fulton wrote:
Stephan Richter wrote:
On Sunday 13 November 2005 10:48, Jim Fulton wrote:
Chris McDonough wrote:
I suspect there's just some miscommunication about who is actually supposed to make the branch. I have just gone ahead and made it.
But yes, now that there is one, the 2.9 branch is frozen for features.
I wish you hadn't done that. We shouldn't be making the branch until we get to beta. We can't get to beta until a lot more bugs are fixed. Everyone likes to work on new features, but we need to get bug fixed to actually make releases. I'm worried that we aren't going to make the time-based release schedule. The only leverage I can see is feature freezes.
Jim, I am really glad you wrote this comment. I was going to write a similar E-mail, but thought it would be out of line for me, since I am not involved in the Zope 2 development.
If someone would have done that with Zope 3, I would have been pretty annoyed. Thus for Zope 3, if someone creates a release branch without discussing it with me first, then that person automatically becomes the release manager for that release.
Yup.
BTW, I'm sure Chris meant well.
Chris,
I appreciate that you were trying to help. I still wish you hadn't made the branch. :)
Yes, I predicted I'd be punished. ;-) I don't understand why you would want to wait to make a release branch until a beta. What is the rationale?
Reread my posts. Jim
--On 12. November 2005 14:56:45 -0500 Paul Winkler <pw_lists@slinkp.com> wrote:
On Tue, Oct 18, 2005 at 07:21:08AM -0400, Jim Fulton wrote:
This is a reminder that there will be a feature freeze for the December Zope releases on November 1.
OK. I thought there was going to be a 2.9 branch by now, but I don't see one. Is the trunk totally frozen now or what?
The reason why there is no 2.9 branch available is just because Jim, Stephan and I agreed to create branches at the time of the 2.9 and 3.2 b1 releases. However there is/was some more work to do so the branch did not exist yet. Andreas
Paul Winkler wrote:
On Tue, Oct 18, 2005 at 07:21:08AM -0400, Jim Fulton wrote:
This is a reminder that there will be a feature freeze for the December Zope releases on November 1.
OK. I thought there was going to be a 2.9 branch by now, but I don't see one. Is the trunk totally frozen now or what?
Yes, no new features.
Is it too late to land my long-forgotten configure changes as discussed at http://mail.zope.org/pipermail/zope/2004-July/151839.html ?
Yes The sooner we're ready for the first beta, the sooner we can make the beta and the branch. We need more volunteers to help with fixing bugs. Jim -- Jim Fulton mailto:jim@zope.com Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jim Fulton wrote:
Paul Winkler wrote:
On Tue, Oct 18, 2005 at 07:21:08AM -0400, Jim Fulton wrote:
This is a reminder that there will be a feature freeze for the December Zope releases on November 1.
OK. I thought there was going to be a 2.9 branch by now, but I don't see one. Is the trunk totally frozen now or what?
Yes, no new features.
Is it too late to land my long-forgotten configure changes as discussed at http://mail.zope.org/pipermail/zope/2004-July/151839.html ?
Yes
The sooner we're ready for the first beta, the sooner we can make the beta and the branch. We need more volunteers to help with fixing bugs.
Which bugs? Sombebody needs to define this, or else risk having the "outsiders" just walk away. *I* know of no showstoppers: all unit tests are passing, CMF-trunk runs fine on the Zope trunk, etc. Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDd9TX+gerLs4ltQ4RAjXcAKDFrEscRwaX2k/o5ggzFnRg8ZzjtgCgmwLO 4rd4lBBcwUKTalOOjJ7k+HA= =xcdb -----END PGP SIGNATURE-----
[Tres Seaver] ...
Which bugs? Sombebody needs to define this, or else risk having the "outsiders" just walk away.
Insiders too ;-)
*I* know of no showstoppers: all unit tests are passing,
Not on Windows: Windows test failures on Zope trunk http://www.zope.org/Collectors/Zope/1931
CMF-trunk runs fine on the Zope trunk, etc.
Certainly agree it would help to have a specific list of what (if anything) still needs to fixed. FWIW, I don't expect Windows test failures to hold up a beta release (note that I didn't say that's a policy I agree with ;-)).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tim Peters wrote:
[Tres Seaver] ...
Which bugs? Sombebody needs to define this, or else risk having the "outsiders" just walk away.
Insiders too ;-)
*I* know of no showstoppers: all unit tests are passing,
Not on Windows:
Windows test failures on Zope trunk http://www.zope.org/Collectors/Zope/1931
CMF-trunk runs fine on the Zope trunk, etc.
Certainly agree it would help to have a specific list of what (if anything) still needs to fixed. FWIW, I don't expect Windows test failures to hold up a beta release (note that I didn't say that's a policy I agree with ;-)).
Without Windows-centric developers who are motivated to investigate and fix those bugs, I don't know what else we can do. Note that of all the recent changes, I would jettison zpkg-based builds *first* if our timebox is at risk; I certainly wouldn't agree with leaving the trunk frozen due to issues with a *very* recently-proposed change which provides no measureable benefit to the users (as opposed to maintainers). Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDd9hZ+gerLs4ltQ4RArdzAKDYpo0rFsX6ZOcDbwDBlN0THVm1HgCfVgN4 LY3dLr1YAW8Ycvu7EXiiH5M= =pjmb -----END PGP SIGNATURE-----
On Sun, 2005-11-13 at 19:20 -0500, Tres Seaver wrote: ...
Note that of all the recent changes, I would jettison zpkg-based builds *first* if our timebox is at risk; I certainly wouldn't agree with leaving the trunk frozen due to issues with a *very* recently-proposed change which provides no measureable benefit to the users (as opposed to maintainers).
Fair enough, but without zpkg there will be a lot more stitching work to do. Way too much of zope.app is stitched in at this point. That's not a problem if we use zpkg to make the distribution. Jim
FWIW, a patched setup.py that appears to compile all known Z2 and Z3 extensions successfully (at least it completes and Zope starts) which doesn't use any zpkg extensions is available at http://www.plope.com/static/misc/setup.py . I took this from the old "setup.py" before Phil checked in his zpkg fixes, and added an Extension directive for the i18nmessageid C extension. It also requires a change to two files in Zope 3: Index: security/_proxy.c =================================================================== --- security/_proxy.c (revision 40034) +++ security/_proxy.c (working copy) @@ -17,7 +17,7 @@ */ #include <Python.h> -#include "zope.proxy/proxy.h" +#include "zope/proxy/proxy.h" static PyObject *__class__str = 0, *__name__str = 0, *__module__str = 0; and Index: app/container/_zope_proxy_proxy.c =================================================================== --- app/container/_zope_proxy_proxy.c (revision 40034) +++ app/container/_zope_proxy_proxy.c (working copy) @@ -28,7 +28,7 @@ #include "modsupport.h" #define PROXY_MODULE -#include "zope.proxy/proxy.h" +#include "zope/proxy/proxy.h" static PyTypeObject ProxyType; - C On Sun, 2005-11-13 at 19:36 -0500, Jim Fulton wrote:
On Sun, 2005-11-13 at 19:20 -0500, Tres Seaver wrote: ...
Note that of all the recent changes, I would jettison zpkg-based builds *first* if our timebox is at risk; I certainly wouldn't agree with leaving the trunk frozen due to issues with a *very* recently-proposed change which provides no measureable benefit to the users (as opposed to maintainers).
Fair enough, but without zpkg there will be a lot more stitching work to do. Way too much of zope.app is stitched in at this point. That's not a problem if we use zpkg to make the distribution.
Jim
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Not on Windows:
Windows test failures on Zope trunk http://www.zope.org/Collectors/Zope/1931
CMF-trunk runs fine on the Zope trunk, etc.
Certainly agree it would help to have a specific list of what (if anything) still needs to fixed. FWIW, I don't expect Windows test failures to hold up a beta release (note that I didn't say that's a policy I agree with ;-)).
Without Windows-centric developers who are motivated to investigate and fix those bugs, I don't know what else we can do.
That bugs points at http://mail.zope.org/pipermail/zope-dev/2005-October/025512.html, which quotes Tim as saying: : No idea where this slash-vs-backslash confusion ultimately comes from, : though. Who recently checked code in hard-coding "/" as a path : separator? So in this specific example, the problem seems less a lack of Windows centric developers, but more an abundance of non-Windows-centric developers :) These test failures appear at first glance to not be windows specific at all - just possibly pointing at non-portable code written by others. As a Windows developer, I'm afraid I have no idea where I would start looking for this bug. Mark
[Tim]
Windows test failures on Zope trunk http://www.zope.org/Collectors/Zope/1931
[Tres]
Without Windows-centric developers who are motivated to investigate and fix those bugs, I don't know what else we can do.
[Mark Hammond]
That bugs points at http://mail.zope.org/pipermail/zope-dev/2005-October/025512.html, which quotes Tim as saying:
: No idea where this slash-vs-backslash confusion ultimately comes from, : though. Who recently checked code in hard-coding "/" as a path : separator?
So in this specific example, the problem seems less a lack of Windows centric developers, but more an abundance of non-Windows-centric developers :)
These test failures appear at first glance to not be windows specific at all - just possibly pointing at non-portable code written by others. As a Windows developer, I'm afraid I have no idea where I would start looking for this bug.
Alas, I was directed not to work on this bug report "on the clock", and I haven't had spare time to donate to it (of course there's the usually irony with that: by now I've probably spent 3x as long typing about these bugs as it would have taken to fix them :-( ...). Because I'm sure I noticed the bug within a day or two of its first appearance, the obvious approach is to revert back to earlier revisions of the trunk until finding the checkin that caused it. I thought I wrote up enough clues on zope-dev at the time that whoever checked in the responsible change would think "ah, that's related to what I did!" at once. Alas again, nobody noticed. So that's a clear path to fixing this one: pinning the blame should be sufficient ;-) In the absence of the guilty party noticing they were to blame, it takes someone on Windows to do the binary search required (because someone on Linux won't see the failure). BTW, notice that the Python tracebacks had exactly the same \ vs / mixup in the same place (between "lib" and "python") as the two originally failing tests. That suggests (but doesn't prove) that a change to sys.path is the ultimate cause. BTW2, I have no idea why the later-failing Five test started failing on Windows, and didn't spend any time investigating that one.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Mark Hammond wrote:
Not on Windows:
Windows test failures on Zope trunk http://www.zope.org/Collectors/Zope/1931
CMF-trunk runs fine on the Zope trunk, etc.
Certainly agree it would help to have a specific list of what (if anything) still needs to fixed. FWIW, I don't expect Windows test failures to hold up a beta release (note that I didn't say that's a policy I agree with ;-)).
Without Windows-centric developers who are motivated to investigate and fix those bugs, I don't know what else we can do.
That bugs points at http://mail.zope.org/pipermail/zope-dev/2005-October/025512.html, which quotes Tim as saying:
: No idea where this slash-vs-backslash confusion ultimately comes from, : though. Who recently checked code in hard-coding "/" as a path : separator?
So in this specific example, the problem seems less a lack of Windows centric developers, but more an abundance of non-Windows-centric developers :)
These test failures appear at first glance to not be windows specific at all - just possibly pointing at non-portable code written by others. As a Windows developer, I'm afraid I have no idea where I would start looking for this bug.
test.py in the root is the likely culprit, as it is mucking with sys.path. Does this patch make the Windows tests pass? - --- test.py (revision 40087) +++ test.py (working copy) @@ -30,7 +30,7 @@ if shome: shome = os.path.abspath(shome) else: - - shome = os.path.join(zhome, 'lib/python') + shome = os.path.join(zhome, 'lib', 'python') elif shome: shome = os.path.abspath(shome) zhome = os.path.dirname(os.path.dirname(shome)) Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDeBX3+gerLs4ltQ4RAiMdAKC7L8kACTUcTON76ch5bLNEkzO60gCgmAWw tEeI08XK7m7PP3wD3Kwt9xE= =0aEf -----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tres Seaver wrote:
Mark Hammond wrote:
Not on Windows:
Windows test failures on Zope trunk http://www.zope.org/Collectors/Zope/1931
CMF-trunk runs fine on the Zope trunk, etc.
Certainly agree it would help to have a specific list of what (if anything) still needs to fixed. FWIW, I don't expect Windows test failures to hold up a beta release (note that I didn't say that's a policy I agree with ;-)).
Without Windows-centric developers who are motivated to investigate and fix those bugs, I don't know what else we can do.
That bugs points at http://mail.zope.org/pipermail/zope-dev/2005-October/025512.html, which quotes Tim as saying:
: No idea where this slash-vs-backslash confusion ultimately comes from, : though. Who recently checked code in hard-coding "/" as a path : separator?
So in this specific example, the problem seems less a lack of Windows centric developers, but more an abundance of non-Windows-centric developers :)
These test failures appear at first glance to not be windows specific at all - just possibly pointing at non-portable code written by others. As a Windows developer, I'm afraid I have no idea where I would start looking for this bug.
test.py in the root is the likely culprit, as it is mucking with sys.path. Does this patch make the Windows tests pass?
--- test.py (revision 40087) +++ test.py (working copy) @@ -30,7 +30,7 @@ if shome: shome = os.path.abspath(shome) else: - shome = os.path.join(zhome, 'lib/python') + shome = os.path.join(zhome, 'lib', 'python') elif shome: shome = os.path.abspath(shome) zhome = os.path.dirname(os.path.dirname(shome))
Whoops, needs another one, too: - --- test.py (revision 40091) +++ test.py (working copy) @@ -42,7 +42,7 @@ else: # No zope home, assume that it is the script directory zhome = os.path.abspath(os.path.dirname(sys.argv[0])) - - shome = os.path.join(zhome, 'lib/python') + shome = os.path.join(zhome, 'lib', 'python') sys.path.insert(0, shome) Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDeBkn+gerLs4ltQ4RAuyiAKCI5i2L4PvNnuw6lRq873VpBgw1YACdHPlO V6YGX2AQcAvoHcyHSnTbWgI= =BfFn -----END PGP SIGNATURE-----
Dang, that's embarassing. Thanks Tres! On Sun, 2005-11-13 at 23:43 -0500, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Mark Hammond wrote:
Not on Windows:
Windows test failures on Zope trunk http://www.zope.org/Collectors/Zope/1931
CMF-trunk runs fine on the Zope trunk, etc.
Certainly agree it would help to have a specific list of what (if anything) still needs to fixed. FWIW, I don't expect Windows test failures to hold up a beta release (note that I didn't say that's a policy I agree with ;-)).
Without Windows-centric developers who are motivated to investigate and fix those bugs, I don't know what else we can do.
That bugs points at http://mail.zope.org/pipermail/zope-dev/2005-October/025512.html, which quotes Tim as saying:
: No idea where this slash-vs-backslash confusion ultimately comes from, : though. Who recently checked code in hard-coding "/" as a path : separator?
So in this specific example, the problem seems less a lack of Windows centric developers, but more an abundance of non-Windows-centric developers :)
These test failures appear at first glance to not be windows specific at all - just possibly pointing at non-portable code written by others. As a Windows developer, I'm afraid I have no idea where I would start looking for this bug.
test.py in the root is the likely culprit, as it is mucking with sys.path. Does this patch make the Windows tests pass?
- --- test.py (revision 40087) +++ test.py (working copy) @@ -30,7 +30,7 @@ if shome: shome = os.path.abspath(shome) else: - - shome = os.path.join(zhome, 'lib/python') + shome = os.path.join(zhome, 'lib', 'python') elif shome: shome = os.path.abspath(shome) zhome = os.path.dirname(os.path.dirname(shome))
Tres. - -- =================================================================== Tres Seaver +1 202-558-7113 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDeBX3+gerLs4ltQ4RAiMdAKC7L8kACTUcTON76ch5bLNEkzO60gCgmAWw tEeI08XK7m7PP3wD3Kwt9xE= =0aEf -----END PGP SIGNATURE-----
_______________________________________________ Zope-Dev maillist - Zope-Dev@zope.org http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Tres Seaver]
test.py in the root is the likely culprit, as it is mucking with sys.path. Does this patch make the Windows tests pass?
- --- test.py (revision 40087) +++ test.py (working copy) @@ -30,7 +30,7 @@ if shome: shome = os.path.abspath(shome) else: - - shome = os.path.join(zhome, 'lib/python') + shome = os.path.join(zhome, 'lib', 'python') elif shome: shome = os.path.abspath(shome) zhome = os.path.dirname(os.path.dirname(shome))
Well spotted! It (plus the later patch) does fix the checkDuplicate test failure on Windows, and I closed issue 1931. Turns out the Five tests that were failing on Windows also fail on Linux, but the failing tests don't run unless you pass ``--all`` to test.py (which I normally do, but I guess most people don't, in which case "most people" wouldn't see these failures). I opened a new issue about that: http://www.zope.org/Collectors/Zope/1947
On Mon, 2005-11-14 at 10:22 -0500, Tim Peters wrote: ...
Turns out the Five tests that were failing on Windows also fail on Linux, but the failing tests don't run unless you pass ``--all`` to test.py (which I normally do, but I guess most people don't, in which case "most people" wouldn't see these failures). I opened a new issue about that:
Ah. I'll add --all to the buildbot configs. JIm
On Sun, 2005-11-13 at 19:05 -0500, Tres Seaver wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Jim Fulton wrote:
Paul Winkler wrote:
On Tue, Oct 18, 2005 at 07:21:08AM -0400, Jim Fulton wrote:
This is a reminder that there will be a feature freeze for the December Zope releases on November 1.
OK. I thought there was going to be a 2.9 branch by now, but I don't see one. Is the trunk totally frozen now or what?
Yes, no new features.
Is it too late to land my long-forgotten configure changes as discussed at http://mail.zope.org/pipermail/zope/2004-July/151839.html ?
Yes
The sooner we're ready for the first beta, the sooner we can make the beta and the branch. We need more volunteers to help with fixing bugs.
Which bugs? Sombebody needs to define this, or else risk having the "outsiders" just walk away.
I'm not sure what you mean by outsiders. You're right, someone needs to define this. For Zope 3, the release manager goes through the collector and marks bugs that have to be fixed before the release as critical. I really don't know what the process is for Zope 2, but I did not that there were 9 bugs in the collector marked critical. In any case, the release manager should make the call. Jim
--On 13. November 2005 19:05:44 -0500 Tres Seaver <tseaver@palladion.com> wrote:
Which bugs? Sombebody needs to define this, or else risk having the "outsiders" just walk away.
*I* know of no showstoppers: all unit tests are passing, CMF-trunk runs fine on the Zope trunk, etc.
About one week ago I tried to build a test release using the HEAD. At that time there were open issues concerning zpgk (as Philikon also wrote in another posting). E.g. making the source tarball did not work properly. So being unable to build a source tarball is definitely a blocker for me. Andreas
participants (8)
-
Andreas Jung -
Chris McDonough -
Jim Fulton -
Mark Hammond -
Paul Winkler -
Stephan Richter -
Tim Peters -
Tres Seaver