Re[2]: [Zope3-dev] how to provide z.a.s.LogoutSupported for different applications in one instance
Hello Stephan, Simple, effective, great. Thanks. Monday, September 11, 2006, 7:45:42 PM, you wrote: On Monday 11 September 2006 13:23, Adam Groszer wrote: The solution might be simple, but at this late time I don't see it. Any help is welcome. No, the solution was not even possible (easily) till recently. For exactly this use case I developed z3c.baseregistry, which allows you to make registrations selectively. Basically, create a components registry for each application and only register applicable pieces in each. Then use those registries as base registries in your local site. Regards, Stephan -- Best regards, Adammailto:[EMAIL PROTECTED] -- Quote of the day: Absence sharpens love, presence strengthens it. - Anonymous ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Release management refinements
Over the last couple of days we've been discussing Zope's new release cycle and the release management. I would like to sum up what seems to be the gist of those discussions: 9 month release period? --- Several consumers of Zope releases have talked about their experience following the Zope release cycle. They apparently have a hard time following the six month cycle and seem to have adopted a 9 month cycle themselves. Not to mention that we just had a hard time producing something worthy of a final release. I couldn't collect a negative vote for a 9 months release cycle, only that several people definitely don't want it to be longer than 9 months. So, the obvious question is: Shall we release once every 9 months from now on? In that case Zope 3.3/2.10 would be on time and Zope 3.4/2.11 would be scheduled for May, as Jim already suggested already. Note that we do have the goal to explode Zope 3 into more independent pieces. It is conceivable that these pieces might gain their own release cycles in the future. Things like zope.interface may not change at all over periods of years whereas other packages might see much more active development. Of course, we're not there yet, so a 9 month cycle would apply to all of Zope 3 for now, and perhaps even after the explosion we might keep a 9 month cycle for most packages because of Zope 2. Zope 3 bugfixes --- Up until now, the last stable release (currently Zope 3.2) was not maintained properly in terms of bugfixes. This is an unacceptable situation. I know a fair number of people who are doing Zope 3.2 deployments now, not to mention Zope 2.9 which includes Zope 3.2 and enables a lot of functionality already. In the Zope 2 world, the following rule has proven to work quite well: 1. Fix the bug in the *oldest* maintained branch (e.g. Zope 2.8 still) 2. Merge the bugfix to newer release branches (e.g. Zope 2.9 and 2.10) 3. Merge the bugfix to the trunk It seems to be the common consensus that this practice should now also be applied to Zope 3. That means, bugs are to be fixed in Zope 3.2 first, then in Zope 3.3, and then the trunk. Unless there are any objections, we should now be enforcing this rule! Furthermore, if you've fixed a bug in Zope 3.3 over the last months and haven't backported the fix to Zope 3.2 yet, please do so soon. Release management -- We'll need people who will manage releases. The problem isn't as much in physically making the releases (tarball, etc.) but to bug people to fix release critical bugs. I'm thinking collector maintenance, bug days, and lots of nagging here. If I had organized the two Zope 3.3 bugdays a bit earlier, perhaps the release could've been out earlier... Andreas Jung is heroically managing all Zope 2 releases, though he does have lots of help from others. For a long time, Chris Withers has organized bug days, for example. As for Zope 3, Martijn has stepped up to take over the Zope 3.3 line, I'll be maintaining the Zope 3.2 branch in terms of releases. Of course, most bugfixes apply to both branches, so bug days will benefit both of them. The important thing is that we do get the bugs fixed and maintenance releases for stable branches out there! We'll also need a release manager for the next release line (Zope 3.4). As far as I see the RM's job it mainly involves nagging people so that a) feature freezes can be made in time (and thus beta releases), b) release critical bugs are fixed soon after they're discovered (and thus won't hinder subsequent beta or final releases) c) non-release critical bugfixes won't find their way into the release branch during the release-candidate period. Whether or not Theuni has signed up for this job I can't really say. It'd be great, though ;). Thoughts? ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Release management refinements
Hey, Philipp von Weitershausen wrote: [snip] Thoughts? I don't have time for a discussion right now as I'm off to Germany soon. The one thought that strikes me is that these release management notes, when finalized, should be in some clear, findable, well-known and maintained location. Otherwise we'll forget again. I know, the obvious, but perhaps worth a mention anyway. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Release management refinements
Martijn Faassen wrote: I don't have time for a discussion right now as I'm off to Germany soon. The one thought that strikes me is that these release management notes, when finalized, should be in some clear, findable, well-known and maintained location. Otherwise we'll forget again. I know, the obvious, but perhaps worth a mention anyway. :) Yes, I had that in mind when I was writing this down, but somehow forgot to include it in the email. This process must be documented. See you tomorrow :) ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Release management refinements
Philipp von Weitershausen wrote: Shall we release once every 9 months from now on? 9 months pregnancy -- that's almost poetic. /Anton ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Release management refinements
Previously Anton Stonor wrote: Philipp von Weitershausen wrote: Shall we release once every 9 months from now on? 9 months pregnancy -- that's almost poetic. And painful to deliver? Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Default zope.conf DB setup
Hi everyone, I just noticed that zope.conf.in has now the following entry: zodb demostorage zeoclient server localhost:8100 storage 1 cache-size 20MB /zeoclient /demostorage /zodb This means that ZEO has to start up to run Zope after a default check out/download. When I had no network connection in a hotel last week, I could not start up Zope because ZEO would not get some network thing going. I think this is really unfortunate and I propose to change this back to the old version: zodb filestorage path Data.fs /filestorage /zodb Comments? Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Default zope.conf DB setup
Stephan Richter wrote: Hi everyone, I just noticed that zope.conf.in has now the following entry: zodb demostorage zeoclient server localhost:8100 storage 1 cache-size 20MB /zeoclient /demostorage /zodb This means that ZEO has to start up to run Zope after a default check out/download. When I had no network connection in a hotel last week, I could not start up Zope because ZEO would not get some network thing going. I think this is really unfortunate and I propose to change this back to the old version: zodb filestorage path Data.fs /filestorage /zodb Comments? Yes, of course. It looks like Theuni accidentally committed his zope.conf.in in these revisions: http://svn.zope.org/?rev=69553view=rev (3.3 branch) http://svn.zope.org/?rev=69554view=rev (trunk) http://svn.zope.org/?rev=69599view=rev (trunk) These need to be reverted for zope.conf.in. Christian, if you want to customize zope.conf.in, just copy it to zope.conf. That's why the file is suffixed with '.in' in the first place (fallback for when you don't have your own zope.conf). Philipp ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Release management refinements
On Wednesday 13 September 2006 11:02, Florent Xicluna wrote: Currently, I work with 3.3 branch for my company. I checked out the trunk too, in order to collaborate to Zope development. So I have both '/trunk' and '/branches/3.3/' on my computer. When I prepare a fix I do it on the 3.3 branch, I make unit/functional tests. Then I do manual tests on my sandbox, and I commit to the branch. Later I merge to the trunk, do unit/functional tests again and commit to the trunk. This is acceptable workload for me. I work this way too. We develop against the trunk. And I always make a writable checkout. When I fix a bug, I will always do this on the trunk first, because I need to make sure that my customer code really works after the fix. It is not sensible for me to fix other branches first. I could live with the policy of also supporting two release branches, but I would prefer only having to worry about one. BTW, a pain-easing script for merging would come a long way, in my opinion. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Re: Release management refinements
On Sep 13, 2006, at 11:23 AM, Stephan Richter wrote: On Wednesday 13 September 2006 11:02, Florent Xicluna wrote: Currently, I work with 3.3 branch for my company. I checked out the trunk too, in order to collaborate to Zope development. So I have both '/trunk' and '/branches/3.3/' on my computer. When I prepare a fix I do it on the 3.3 branch, I make unit/functional tests. Then I do manual tests on my sandbox, and I commit to the branch. Later I merge to the trunk, do unit/functional tests again and commit to the trunk. This is acceptable workload for me. I work this way too. We develop against the trunk. And I always make a writable checkout. When I fix a bug, I will always do this on the trunk first, because I need to make sure that my customer code really works after the fix. It is not sensible for me to fix other branches first. I could live with the policy of also supporting two release branches, but I would prefer only having to worry about one. BTW, a pain-easing script for merging would come a long way, in my opinion. We should be using svnmerge. I looked at it and even contributed to it a year or two ago. It wasn't mature enough for our needs at the time, but I suspect it probably is now and would probably help a lot. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Roadmap for Zope 3.4
On 9/12/06, Jim Fulton [EMAIL PROTECTED] wrote: FWIW, I use the following approach: - Early in the process, I mark every real reproducable bug as blocking. In this last go around, this included a number of bugs that had been around for months or years. - Later in the process I downgraded lots of bugs because I didn't want toblock the release. Ah. Well, that procedure definitely can get improved on. :) I think it is imperative that we mark bugs according to the seriousness so that you know which bug should be worked on first. I note that the Zope3 collector has the categories medium, low, critical, 3.3 release and 3.4 alpha 1. I don't think that's a good idea, but I understand that the Zope collector has no field for planned release, and those options make sense for features. :-) Anyway, for me it's like this: A blocking/critical bug is a bug that means the system or part of the system gets unusable. It has no workarounds, and affects most users of the system. Say, PUT_factory suddenly stops working, meaning that FTP and WebDAV no longer works. A serious/medium bug is a bug that is a big problem for many users and has no workaround, or affects everybody, but has a workaround. For example, that XML import/export didn't work: Workaround, use the non XML-import/export. A minor bug is a bug that affects few users and has a workaround, or has no workaround but only is a problem in very extreme edge usercases. For example...euhm, ehhh, I can't think of one right now. (and a trivial bug is not an actual problem for anybody. Could be spelling errors or ugly design.) A bug should be assigned a category and stay there. It should not get it's category changed so not block a release, because if you can do that, well, then it wasn't blocking in the first case. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Release management refinements
Florent Xicluna wrote: However i have a worry on the Fix oldest branch, merge to newer branches. I guess this is due to my young experience with SVN development. Currently, I work with 3.3 branch for my company. I checked out the trunk too, in order to collaborate to Zope development. So I have both '/trunk' and '/branches/3.3/' on my computer. When I prepare a fix I do it on the 3.3 branch, I make unit/functional tests. Then I do manual tests on my sandbox, and I commit to the branch. Later I merge to the trunk, do unit/functional tests again and commit to the trunk. This is acceptable workload for me. But if I need to checkout/update all previous maintenance releases, all refers to one more. There are at most only two maintenance releases. and if i need to perform merge+tests+commit three times for every single bug, this seems a big work load to fix a bug. If you can merge and run tests once, you can merge and run tests twice. It's mostly mechanical. Heck, I can do it on my slw PowerBook. Most of you guys have fast Intel machines :). And if i have not enough knowledge of old release 3.X, this is a pain to do the merge. That's why it's best to fix the bug on the oldest still maintained release. IMHO, i would prefer to keep the current bugfix policy (i.e. commit to working release+trunk) and to have for each release someone that will do merging. Who's that someone? Are you volunteering to do it? In order to facilitate this process, we can enforce a workflow where committer will warn the person in charge for release 3.X, to ask him to merge rev. 700xx to release 3.X. That requiers we that person in charge for release 3.X. We currently don't have that someone. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: Release management refinements
Stephan Richter wrote: On Wednesday 13 September 2006 11:02, Florent Xicluna wrote: Currently, I work with 3.3 branch for my company. I checked out the trunk too, in order to collaborate to Zope development. So I have both '/trunk' and '/branches/3.3/' on my computer. When I prepare a fix I do it on the 3.3 branch, I make unit/functional tests. Then I do manual tests on my sandbox, and I commit to the branch. Later I merge to the trunk, do unit/functional tests again and commit to the trunk. This is acceptable workload for me. I work this way too. Contributing to a community also means adapting to its processes and way of working. The process has been working well for Zope 2 developers, so I don't see why it can't work for Zope 3. We develop against the trunk. That shouldn't be an obstacle (see below). And I always make a writable checkout. When I fix a bug, I will always do this on the trunk first, because I need to make sure that my customer code really works after the fix. It is not sensible for me to fix other branches first. This process isn't only about what's sensible to you or your customer. It's also about those people who use stable releases and would like them to be maintained. Heck, Zope 3.3 isn't even final yet (so Zope 3.2 is still stable!) and nobody is fixing things in Zope 3.2. That's simply unacceptable. Plus, I need to make sure that my customer code really works after the fix makes it sound like we have no tests. The usual drill is to produce a minimal test failure (and that usually means outside customer code) and then fix the bug until the test passes. So, even if you develop against the trunk and notice a bug there, you can switch to the oldest maintained branch, whip up a test case there (which is needed anyways because we'd need to know whether the problem applies to that branch as well) and fix the bug. THen you can merge onward till the fix is on the trunk. I could live with the policy of also supporting two release branches, but I would prefer only having to worry about one. Sure, we'd all prefer that, wouldn't we. ;) BTW, a pain-easing script for merging would come a long way, in my opinion. Generally I like svk's and svnmerge's approach with sticking properties with merging information on the files and dirs that have been worked on. But their approach requires that this practice is generally adopted. I wrote a braindead simple merging tool called ezmerge that serves me well 90% of the time: http://www.z3lab.org/sections/blogs/philipp-weitershausen/2006_08_23_how-python-solves-my ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Release management refinements
Philipp von Weitershausen wrote at 2006-9-13 11:05 +0200: Over the last couple of days we've been discussing Zope's new release cycle and the release management. I would like to sum up what seems to be the gist of those discussions: 9 month release period? --- I am almost convinced that we will make the same experience as the Plone people: when we strive for a 9 month release cycle, we will get a 12 month cycle... I think this is almost a law for software development: completing in time is the exception not the rule. -- Dieter ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
