Re: [Zope3-dev] Re: Release management refinements
On Wednesday 13 September 2006 13:28, Philipp von Weitershausen wrote: 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. A couple of comments: First, if several -- as in a majority of -- people say I work this way W., then our process should be adapted to those people. Having those people contribute less, because of an unnecessary barrier. Second, Zope 2 and 3 are *very* different in this respect. Zope 2 does not have the same testing story. In Zope 2 it was risky, if not impossible, to use the trunk, because those large frameworks (CMF, Plone, ...) that had very tight couplings with Zope 2 had to be adjusted in many cases. Zope 3 is different, since the trunk is effectively as stable as any release at any time, especially now with the even stricter trunk policies and the desire to move packages out of the core. This allows developers to develop against the trunk. And even if the trunk is shaken by deprecation warnings like your refactorings, most packages based on Zope 3 were updated within a week, even large projects like SchoolTool and Tiks. This is a very strong statement and warrants a different check-in policy. To get into an even more fundamental discussion, I claim that the culture of test-driven development weakens some common software-engineering practices, such as release cycles. I think, and seeing our discussions it seems I am right, that releases are marketing tools, not important software engineering artifacts. Releases allow us to say, Here are those great new features., write a magazine article, be slashdotted, and tell the client we are already in version 3.X where X 100. Don't get me wrong, I understand the motivations behind releases, besides those points. It allows other developers to have a set target and something to rely on, etc. Thus I said, it weakens the release artifact, not obsolete it. 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
Stephan Richter wrote: On Wednesday 13 September 2006 13:28, Philipp von Weitershausen wrote: 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. A couple of comments: First, if several -- as in a majority of -- people say I work this way W., then our process should be adapted to those people. Having those people contribute less, because of an unnecessary barrier. Agreed. But we'll have to make compromises between the comfort for the developers and the necessary house keeping that we inevitably have to commit ourselves to as a serious software project. The latter invariably includes maintaining old releases. Frankly, I personally don't feel very strongly where you commit a fix first, as long as the fix gets into all the necessary places. All I know is that the described way of working a) ensures that you don't forget to backport the fix b) works for many people I'm also strongly wondering whether the majority of the people actually do develop against the trunk. Second, Zope 2 and 3 are *very* different in this respect. Zope 2 does not have the same testing story. In Zope 2 it was risky, if not impossible, to use the trunk, because those large frameworks (CMF, Plone, ...) that had very tight couplings with Zope 2 had to be adjusted in many cases. Sorry, but when was the last time you contributed to Zope 2? You're using the past tense which is applicable to most of this. Zope 2 *does* have a testing story now. We can't make the past go away, but we have the same standard in terms of testing as Zope 3 does now. (And as far as the cutting-edge Plonistas are concerned, for example, they often do develop against the trunk or at least the latest development release branch). Plus, I don't see the point in the testing argument. Just because the Zope 3 trunk can be considered more stable (for some definition of stable) doesn't mean we can neglect stable releases branches. Zope 3 is different, since the trunk is effectively as stable as any release at any time, especially now with the even stricter trunk policies and the desire to move packages out of the core. This allows developers to develop against the trunk. I never said that that was a bad idea. And even if the trunk is shaken by deprecation warnings like your refactorings, most packages based on Zope 3 were updated within a week, even large projects like SchoolTool and Tiks. This is a very strong statement and warrants a different check-in policy. I disagree. I think the majority of those who do web development with Zope3 nowadays use releases. Gocept seems to do it, I do it, and most zope3-users@zope.org people seem to do it as well. Zope 3 isn't all about the trunk is our playground anymore. Again, I have nothing against development against the trunk, but thinking that this is the standard development model is mistaken. To get into an even more fundamental discussion, I claim that the culture of test-driven development weakens some common software-engineering practices, such as release cycles. I think, and seeing our discussions it seems I am right, that releases are marketing tools, not important software engineering artifacts. Releases allow us to say, Here are those great new features., write a magazine article, be slashdotted, and tell the client we are already in version 3.X where X 100. Don't get me wrong, I understand the motivations behind releases, besides those points. It allows other developers to have a set target and something to rely on, etc. Thus I said, it weakens the release artifact, not obsolete it. I think the most important fact about releases, strictly speaking from a software development view, is that they're milestones in terms of feature stability. We promise not to introduce new features and not to shake up things within a stable release branch. People want this sort of stability insurance (with the additional bugfix promise). Philipp ___ 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
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
[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
