[Zope3-dev] i18n message factory in zope domain
Hi, Should we create separate message factory in 'zope' domain for each packages ? If so, can anyone explain why it should be like that. Few weeks back a new message factory is created in zope.i18nmessageid [1] . And now some packages use this directly. I am bit confused now ... [1] http://svn.zope.org/?rev=80022view=rev Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Release process closure
I'd really like to get to closure on the current approved release process. Philipp, would you mind separating the release process into a separate file? Or do you mind if I do it? Some comments on the current draft at: http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/ maintaining-software.txt WRT version numbers in setup.py. I'm inclined to endorse Philipp's recommendation for now. If there was a way to specify a version number on the command line (or in a buildout.cfg) when creating develop eggs, then I'd have a different position, but given current technology, I think Philipp's recommendation, as I understand it, is best. I think there are some details missing. I think the intend is that the version number in the setup.py on the trunk and on release branches should have the dev suffix. I think this is good as a reminder and a flag that accidentilly released dev eggs are suspect. I think the dance should be that, to make a release, you make a tag and then edit the version number on the tag. I think this sort of editing on a tag is reasonable and it is fortuitous that svn allows it. Also, by default, the next version on the trunk should be a release with the second number incremented. The next version on a release branch should have the 3rd number incremented. This is a minor detail, especially since I think we can avoid release branches for most projects and I think that release branches shouldn't be created until they are needed. Of course, tags should always be created. There are other improvements that might be made, but let's not let the perfect be the enemy of the good. Jim -- Jim Fulton Zope Corporation ___ 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 process closure
Jim Fulton wrote: I'd really like to get to closure on the current approved release process. +1 There are other improvements that might be made, but let's not let the perfect be the enemy of the good. This isn't perfect, so I get to suggest it. wink I propose that we codify the practice of release tags having their x.y.z version number as their name, and in the setup.py. -- Benji York Senior Software Engineer Zope Corporation ___ 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 process closure
On Oct 3, 2007, at 11:12 AM, Benji York wrote: Jim Fulton wrote: I'd really like to get to closure on the current approved release process. +1 There are other improvements that might be made, but let's not let the perfect be the enemy of the good. This isn't perfect, so I get to suggest it. wink I propose that we codify the practice of release tags having their x.y.z version number as their name, and in the setup.py. Which implies that we codify 3-number version numbers, that is: major.minor.bugfix with optional modifiers of the form dev, aN, bN, or cN. I also suggest a special version numbering scheme when we package something else. For example, if we package Twisted ro package some external js library in a Python package. In this case, I suggest we use the version number of the thing being packages with the addition of a post-release addition. For example, a packaging of MochiKit 1.3.1 might have a version # like 1.3.1-1, or, if it is exciting enough: 1.3.1-1.1 Jim -- Jim Fulton Zope Corporation ___ 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 process closure
Jim Fulton wrote: For example, a packaging of MochiKit 1.3.1 might have a version # like 1.3.1-1, or, if it is exciting enough: 1.3.1-1.1 I assume setuptools interprets version numbers like this in a reasonable way. -- Benji York Senior Software Engineer Zope Corporation ___ 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 process closure
On Oct 3, 2007, at 11:46 AM, Benji York wrote: Jim Fulton wrote: For example, a packaging of MochiKit 1.3.1 might have a version # like 1.3.1-1, or, if it is exciting enough: 1.3.1-1.1 I assume setuptools interprets version numbers like this in a reasonable way. AFAIK. :) Jim -- Jim Fulton Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Re: zope.dottedname doesn't have a CHANGES.txt (again?)
Stephan Richter wrote: On Tuesday 02 October 2007 17:14, Jim Fulton wrote: One hole I see is giving people guidance on what needs to be tested (and how) before a release is made. My preference would be to rely heavily on judgement with a few checks so as not to make things too heavy. This might rule out some releasers. I want tools! Actually, I just want one tool. 70% of the release process is repetition and that needs to be factored into a tool. This tool should have been written before the Zope trunk was blown into pieces, but it wasn't. :-( Before this tool is written, can you please do the release from a tag? I wasn't convinced of the necessity at the time. Philipp gave me examples that convinced me. I think after the mistake with zope.dottedname you should be convinced of the value of doing this right now. Feel free to work on tools, but please follow the pattern where you check out from the release tag until you have such a tool. I think it's a bad idea for you to wait until a tool is finished and not follow the guidelines until then. We just had a clear demonstration of what can happen if you don't follow the guidelines. While I understand everybody has been put on the defensive here, and mistakes are human, I would've liked to have heard you say that if indeed you'd have followed this particular guideline, which you were aware of, you wouldn't have botched this release. There is no way that we will be able to support this many packages in the future, if we keep doing this manually. I have already spent days on doing eggs, when I really just wanted to code. :-( We simply didn't anticipate many of the problems we are having now. We probably could've anticipated a few more than we did but we wouldn't have anticipated all. To fix all the problems one has to try it. If I'd seen the current trouble coming, I would have been against switching Grok 0.10 to eggs, considering the way the installation pain increased. All that said, the egg story, once fixed, is a quite powerful and flexible installation story. 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] Re: zope.dottedname doesn't have a CHANGES.txt (again?)
On 10/3/07, Stephan Richter [EMAIL PROTECTED] wrote: I want tools! Actually, I just want one tool. 70% of the release process is repetition and that needs to be factored into a tool. This tool should have been written before the Zope trunk was blown into pieces, but it wasn't. :-( I'd recommend fixing bundleman to be able to support making eggs. Bundleman will look at the changes, suggest versions out of that, refuse to release if there are no changes set, create the tag and make the release from the tag. It's written in Python, in clear and understandable code by eminent programmer Benoit Delbosc (of funkload fame). http://tinyurl.com/ye8dsk It currently only makes releases as tgz, but adding eggs should be so hard (it's done by calling setup.py anyway if I remember correctly). -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ 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: zope.dottedname doesn't have a CHANGES.txt (again?)
Tres Seaver wrote: I would prefer that we quit releasing non-source distributions at all; the exceptions would be Windows eggs for packages containing extensions. +1 -- Benji York Senior Software Engineer Zope Corporation ___ 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: zope.dottedname doesn't have a CHANGES.txt (again?)
On Oct 2, 2007, at 6:52 PM, Stephan Richter wrote: On Tuesday 02 October 2007 17:14, Jim Fulton wrote: One hole I see is giving people guidance on what needs to be tested (and how) before a release is made. My preference would be to rely heavily on judgement with a few checks so as not to make things too heavy. This might rule out some releasers. This is odd text to quote, considering what follows. Do you really think that an automated tool is going to be able to determine on a case by case basis what needs to be tested? Heck, I find it hard to judge what is best to test. I think we need to think about what the process needs to be. It's not at all clear to me and yet you are ready to automate it. I can only hope that this wasn't the text you intended to quote. I want tools! Actually, I just want one tool. You want a silver bullet. 70% of the release process is repetition and that needs to be factored into a tool. I think that is overly optimistic, but I have an open mind. Frankly though, your desire for an automated tool frightens me. This tool should have been written before the Zope trunk was blown into pieces, but it wasn't. :-( I'm skeptical that such a tool can do that much. Certainly, when we broke the trunk up, we didn't know what all the issues would be. We couldn't automate a process we didn't yet fully understand. My only real regret is that we broke things too far too fast, but that is water under the bridge. Some of the fouls this week had nothing to do with the release process. The breakage you (I assume) and Roger caused by removing needed files would have caused just as much havoc in the old days. You seem to think that the trunk is everything, so making changes there and adjusting all of the effected software *on the trunk* is enough. This kind of breakage used to occur before and caused much pain for 3rd-party consumers of the Zope 3 tree. Other breakage occurred after people tried to give you advice on how to do things more reliably. Saying you need a tool is not an excuse for ignoring advice. There is no way that we will be able to support this many packages in the future, if we keep doing this manually. You should know that we already *are* maintaining this many packages. People have been able to figure out how to release packages in a fairly stable way. We're learning from our mistakes and creating processes to make things better. I have already spent days on doing eggs, when I really just wanted to code. :-( Then stop. The current process is too manual and requires too much judgement for you. OK, then stop updating core packages. We all make mistakes. Even with the best tools, processes and intentions, bad things will happen. No one will hold a grudge as long as people are being responsible and trying to do the right thing. OTOH, while wishing for a tool and or for better processes is fine, blaming the current processes for your mistakes is getting tiresome. jim -- Jim Fulton Zope Corporation ___ 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: zope.dottedname doesn't have a CHANGES.txt (again?)
On 10/3/07, Fred Drake [EMAIL PROTECTED] wrote: On 10/3/07, Lennart Regebro [EMAIL PROTECTED] wrote: It currently only makes releases as tgz, but adding eggs should be so hard (it's done by calling setup.py anyway if I remember correctly). tgz files are all that's needed (or wanted); there's no reason to use a .egg file. For packages that include extension modules, there are well-understood reasons to stick with a source distribution. Oh, well then maybe we don't need egg support. That's good. However, I also just realizd that bundleman currently uses the pattern of having a CHANGES file, and a HISTORY file and a VERSION file, and then massaging them and renaming them to CHANGES.txt HISTORY.txt and version.txt when used, and I think we still would need some change to support calling the files CHANGES.txt directly, or updating all the eggs might be a bit much work. (Unless we make a script for that). But it is a very good tool for making releases. It also has this nice support for releasing all the products in a whole svn-bundle, if they need releasing, which is very nice. -- Lennart Regebro: Zope and Plone consulting. http://www.colliberty.com/ +33 661 58 14 64 ___ 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: zope.dottedname doesn't have a CHANGES.txt (again?)
On 10/3/07, Lennart Regebro [EMAIL PROTECTED] wrote: It currently only makes releases as tgz, but adding eggs should be so hard (it's done by calling setup.py anyway if I remember correctly). tgz files are all that's needed (or wanted); there's no reason to use a .egg file. For packages that include extension modules, there are well-understood reasons to stick with a source distribution. -Fred -- Fred L. Drake, Jr.fdrake at gmail.com Chaos is the score upon which reality is written. --Henry Miller ___ 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 process closure
Jim Fulton wrote: I'd really like to get to closure on the current approved release process. Philipp, would you mind separating the release process into a separate file? Or do you mind if I do it? Done: http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/releasing-software.txt WRT version numbers in setup.py. I'm inclined to endorse Philipp's recommendation for now. If there was a way to specify a version number on the command line (or in a buildout.cfg) when creating develop eggs, then I'd have a different position, but given current technology, I think Philipp's recommendation, as I understand it, is best. Ok. (I should note that I think Tres originally suggested it, but I've been using this practice on a couple of projects, both Zope and private, ever since and it's worked well for me). I think there are some details missing. I think the intend is that the version number in the setup.py on the trunk and on release branches should have the dev suffix. I think this is good as a reminder and a flag that accidentilly released dev eggs are suspect. I think the dance should be that, to make a release, you make a tag and then edit the version number on the tag. I think this sort of editing on a tag is reasonable and it is fortuitous that svn allows it. I've spelt this out now. Let me know if you think it's still missing something. Also, by default, the next version on the trunk should be a release with the second number incremented. The next version on a release branch should have the 3rd number incremented. This is a minor detail, especially since I think we can avoid release branches for most projects and I think that release branches shouldn't be created until they are needed. Of course, tags should always be created. There are other improvements that might be made, but let's not let the perfect be the enemy of the good. Agreed :). -- http://worldcookery.com -- Professional Zope documentation 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 process closure
On Oct 3, 2007, at 3:44 PM, Philipp von Weitershausen wrote: Jim Fulton wrote: I'd really like to get to closure on the current approved release process. Philipp, would you mind separating the release process into a separate file? Or do you mind if I do it? Done: http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/ releasing-software.txt Cool. I think you can delete 5b. You already update the date, as you should, on the trunk or branch. You want the actual release date to be part of the change log, so it has to be entered before making the tag. I think we need to split d into: d) Create a source release e) Test the source release. At a minimum, rerun the package tests using the source release. (I really need to add a buildout option to help with this.) f) If the package has extensions, make and test a windows egg. (You may need to get someone with the needed Windows tools to help you with this. :) f) Upload the release(s) to PyPI Jim -- Jim Fulton Zope Corporation ___ 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 process closure
Jim Fulton wrote: I'd really like to get to closure on the current approved release process. Philipp, would you mind separating the release process into a separate file? Or do you mind if I do it? Some comments on the current draft at: http://svn.zope.org/*checkout*/Sandbox/philikon/foundation/maintaining-software.txt WRT version numbers in setup.py. I'm inclined to endorse Philipp's recommendation for now. If there was a way to specify a version number on the command line (or in a buildout.cfg) when creating develop eggs, then I'd have a different position, but given current technology, I think Philipp's recommendation, as I understand it, is best. +1 Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
