Re: [Zope-dev] summary of suggestions
Hi Martijn, On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen faas...@startifact.com wrote: Because my suggestions (besides the fork issue) as a ZTK user/contributor were scattered through the thread, here's a handy summary: Thank you very much for your suggestions. I'm sure the release team will pick these up, once we get to start actual discussions. We have only started talking to each other last week and are slowly bootstrapping. Please don't expect us to solve everything in a matter of days. Hanno ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] summary of suggestions
Hanno Schlichting wrote: Hi Martijn, On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen faas...@startifact.com wrote: Because my suggestions (besides the fork issue) as a ZTK user/contributor were scattered through the thread, here's a handy summary: Thank you very much for your suggestions. I'm sure the release team will pick these up, once we get to start actual discussions. We have only started talking to each other last week and are slowly bootstrapping. Please don't expect us to solve everything in a matter of days. Why not? Why can't you solve things in a matter of days? The fork took 5 minutes. Does it really take more than saying, okay, we're going to unfork, a few modifications to a buildout.cfg and figuring out a couple of test failures? I know it's hard to admit a mistake, but heck, it shouldn't have to take 4 months. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] summary of suggestions
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Martijn Faassen wrote: Hanno Schlichting wrote: Hi Martijn, On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen faas...@startifact.com wrote: Because my suggestions (besides the fork issue) as a ZTK user/contributor were scattered through the thread, here's a handy summary: Thank you very much for your suggestions. I'm sure the release team will pick these up, once we get to start actual discussions. We have only started talking to each other last week and are slowly bootstrapping. Please don't expect us to solve everything in a matter of days. Why not? Why can't you solve things in a matter of days? The fork took 5 minutes. Does it really take more than saying, okay, we're going to unfork, a few modifications to a buildout.cfg and figuring out a couple of test failures? I know it's hard to admit a mistake, but heck, it shouldn't have to take 4 months. One issue with insta-updates to ztk.cfg is that ongoing development of a package can be in real tension with the needs of ZTK consumers for stability in the package set. E.g., I have updated zope.testbrowser/trunk to use the new version of mechanize, but don't know whether pulling that version into the ZTK proper is reasonable (in fact, I decided to have the ZTK development buildout use a stable branch for the meanwhile). If you are a ZTK consumer, and would like to see the ZTK include a newer version of one of its packages, then that need has to be balanced with the needs of the downstream projects. In effect, the new release manager group is supposed to represent the interests of Grok, Zope2, and BlueBream in a shared definition of the ZTK known good set. Getting that nailed down into a version which works for all three is *way* more important than picking up individual package changes. Once a ZTK 1.0 release is out and frozen, then we can look at opening up the trunk to more rapid breakage^Wimprovements. Tres. - -- === Tres Seaver +1 540-429-0999 tsea...@palladion.com Palladion Software Excellence by Designhttp://palladion.com -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvfCngACgkQ+gerLs4ltQ6cJACgvfiYwQMFmjqiDT94uBgiWGqM 2zwAn36lr737tui7YtiYCWDQowKpsqoB =MZu1 -END PGP SIGNATURE- ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] summary of suggestions
Hi there, Tres Seaver wrote: One issue with insta-updates to ztk.cfg is that ongoing development of a package can be in real tension with the needs of ZTK consumers for stability in the package set. Since there are no ZTK releases Grok and BlueBream gain stability by pinning to a particular revision of ztk.cfg (and moving it forward when needed). Zope 2 could easily do the same. If more is needed, then a branch or tag can easily be made. Besides the perennial documentation issues, I also don't see why we couldn't just start releasing the ZTK; instead of pinning to an SVN revision we'd start pinning to an SVN tag (or a release URL with version number in it). What's the holdup, really? One objection I can see is that we might end up with quite a few releases in a short period, and it might be nicer to have a more stable base that people can build on. But they could simply pin to one release and stick with it for a while, right? E.g., I have updated zope.testbrowser/trunk to use the new version of mechanize, but don't know whether pulling that version into the ZTK proper is reasonable (in fact, I decided to have the ZTK development buildout use a stable branch for the meanwhile). Why wouldn't it be reasonable to try at least? If you tested it with the ZTK, you might find issues with your integration of a new version of mechanize. But anyway, you didn't release zope.testbrowser either yet, so this isn't a very good example of what I'm complaining about. I understand that you sometimes want to be careful about what to include, but this kind of ZTK-breaking release is very rare and I haven't seen a good example of it in Zope 2's list. Is there? If you are a ZTK consumer, and would like to see the ZTK include a newer version of one of its packages, then that need has to be balanced with the needs of the downstream projects. In effect, the new release manager group is supposed to represent the interests of Grok, Zope2, and BlueBream in a shared definition of the ZTK known good set. Getting that nailed down into a version which works for all three is *way* more important than picking up individual package changes. I'll note that Zope 2's fork is moving *faster* than the ZTK itself right now; a whole slew of mostly bugfix versions are used by Zope 2's list that aren't in the ZTK. I don't see a reason why instead the ZTK couldn't have been updated with those bugfix releases and Zope 2 could've used that. That way Grok and BlueBream would have benefited from the same fixes. And if Zope 2 needs to do a bigger change of a package that's in the ZTK, that might break other users of the ZTK, and do a release without discussing it here, then there is something wrong already. Anyway, this all has nothing to do with why the fork happened in december. The fork happened in december because of a very specific debate that has nothing to do with this. Such lack of commitment made me less interested in committing my own time and energy as well. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] summary of suggestions
On Mon, May 3, 2010 at 20:13, Martijn Faassen faas...@startifact.com wrote: Since there are no ZTK releases Grok and BlueBream gain stability by pinning to a particular revision of ztk.cfg (and moving it forward when needed). Zope 2 could easily do the same. If more is needed, then a branch or tag can easily be made. Besides the perennial documentation issues, I also don't see why we couldn't just start releasing the ZTK; instead of pinning to an SVN revision we'd start pinning to an SVN tag (or a release URL with version number in it). What's the holdup, really? Making a ZTK 1.0a seems to be a good idea to me, and should help here. And we don't have to commit to anything, since it's an alpha. We could even call it 0.1, if so desired. :) One objection I can see is that we might end up with quite a few releases in a short period, and it might be nicer to have a more stable base that people can build on. But they could simply pin to one release and stick with it for a while, right? Right. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] summary of suggestions
Lennart Regebro wrote: On Mon, May 3, 2010 at 20:13, Martijn Faassen faas...@startifact.com wrote: Since there are no ZTK releases Grok and BlueBream gain stability by pinning to a particular revision of ztk.cfg (and moving it forward when needed). Zope 2 could easily do the same. If more is needed, then a branch or tag can easily be made. Besides the perennial documentation issues, I also don't see why we couldn't just start releasing the ZTK; instead of pinning to an SVN revision we'd start pinning to an SVN tag (or a release URL with version number in it). What's the holdup, really? Making a ZTK 1.0a seems to be a good idea to me, and should help here. And we don't have to commit to anything, since it's an alpha. I think the list needs to commit to something, because we do have people coming from older versions of Grok, BlueBream (in the form of Zope 3) and Zope 2 (though apparently Zope 2 has the least issues). While the ZTK might be new the underlying codebase isn't new at all. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] summary of suggestions
On Mon, May 3, 2010 at 21:57, Martijn Faassen faas...@startifact.com wrote: I think the list needs to commit to something If it needs to commit to what packages are included, then there is no reason to call it an alpha, and also, we can't do it now. So then the status persists with the users of ZTK having to use trunk, which means we can't just change versions all the time. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64 ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] summary of suggestions
Thanks for these suggestions. This is *exactly* what we (the ztk release team) need. Are there other recommendations from other people? Martijn Faassen a écrit : Hi there, Because my suggestions (besides the fork issue) as a ZTK user/contributor were scattered through the thread, here's a handy summary: * please construct guidelines for updating the ZTK when making a release of a package that's managed by the ZTK project. It's useful people test their changes within the ZTK. * please let these guidelines not block most updates by most people most of the time; it should be easy to update the ZTK. Gatekeepers tend to slow things down a lot, and we don't have them for most Python code. We have already started discussing about this. One idea is to let the ZTK update or even release by itself, with the help of the buildbot infrastructure. I would like to replace the expected ztk bureaucracy with automated scripts that enforce some rules and *help* people. Particularly the implicit rules that make people upset when they are not respected. One example is the first message of the previous thread ;) The Zope ecosystem and its processes has become quite complex, and we cannot expect people to never do errors or to know or read everything. * there's a 'checknew.py' script to see whether there are releases newer than the ZTK. I'd be useful if this were integrated in the standard ZTK buildout.cfg so you just get a 'bin/checknew'. It'd also be nice if that were reusable by other toolkit projects. It's on the way. It will probably take the buildout.cfg as an argument, to allow checking different buildout files with possibly different versions. * (new idea) similarly it'd be nice if there were a script integrated that could check which binary egg releases exist for Windows (32 bit, 64 bit, Python version). Right now BlueBream is maintaining a list here: http://wiki.zope.org/bluebream/StatusOfWindowsBinaryPackages * Please update the ZTK documentation about the status of the ZTK steering group and the ZTK release team. It's unclear to newcomers such as myself. * In general it'd be useful if the release team recorded decisions in the ZTK documentation. It's confusing to have to go look for them in mailing list archives and people tend to forget or reinterpret decisions as time goes by. Ok, we will write down decisions or status somewhere. We are just starting organizing ourselves. Christophe Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope ) ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] summary of suggestions
Hey, Christophe Combelles wrote: Thanks for these suggestions. This is *exactly* what we (the ztk release team) need. How wonderfully diplomatic and constructive, my compliments! The release team (you, Hanno and JW) look good to me. * please let these guidelines not block most updates by most people most of the time; it should be easy to update the ZTK. Gatekeepers tend to slow things down a lot, and we don't have them for most Python code. We have already started discussing about this. One idea is to let the ZTK update or even release by itself, with the help of the buildbot infrastructure. I would like to replace the expected ztk bureaucracy with automated scripts that enforce some rules and *help* people. Particularly the implicit rules that make people upset when they are not respected. One example is the first message of the previous thread ;) The Zope ecosystem and its processes has become quite complex, and we cannot expect people to never do errors or to know or read everything. Yes. But I don't think you can replace people's judgment with processes completely. Differences of judgment will continue to exist too, and they shouldn't lead to deadlocks. In that case it becomes useful to have leadership with vision with the authority to break deadlocks. Vision is also useful to go beyond processes. I think one interesting distinction has to do with structure versus versions. I think we should be quite open in allowing people to release new versions of packages and update the ZTK. Especially bugfix releases, of course, but I think many feature releases can also be safely integrated. Structural changes, where packages are dropped or added, need more discussion. I think the cost for having a package in the ZTK is fairly low as long as it doesn't have a lot of things depending on it, but I realize that the cost is non-zero so shrinking the ZTK sounds like a good plan. Dropping is dangerous for other reasons than adding. Adding a package is dangerous as you give a certain commitment to maintain this package for a long time. Dropping a package is dangerous as you break this commitment. We have the complexity here that we have a *new* project that is actually the underpinning of several projects (Grok, BlueBream, Zope 2) with a long history. I therefore think the issue of dropping is immediately relevant, not only after the 1.0 release. Why is dropping a package an issue? It's an issue because you break backward compatibility promises. Another way to look at it is that you're removing features from the ZTK. Another way to look at it is that you're removing *tests* from the ZTK. We don't expect people to just remove a bunch of tests from zope.component without a very good reason and probably some discussion. I think this is why version updates are generally okay, even drastic version updates, and structural updates are more risky. Of course there are some cases where a version update can break a lot of other packages. I.e. the package is depended on a lot by other packages and you're changing a contract. This is a situation that should be as carefully considered as removing a package. I think the structural organization should follow the lines of interest of project groups more than it should follow lines of content. But I'm wary about trying to organize too much, as separating bits *does* make maintenance harder. * there's a 'checknew.py' script to see whether there are releases newer than the ZTK. I'd be useful if this were integrated in the standard ZTK buildout.cfg so you just get a 'bin/checknew'. It'd also be nice if that were reusable by other toolkit projects. It's on the way. It will probably take the buildout.cfg as an argument, to allow checking different buildout files with possibly different versions. Cool. Also reasonable to make 'buildout.cfg' the default, I think? * In general it'd be useful if the release team recorded decisions in the ZTK documentation. It's confusing to have to go look for them in mailing list archives and people tend to forget or reinterpret decisions as time goes by. Ok, we will write down decisions or status somewhere. We are just starting organizing ourselves. I think you can just use this: http://docs.zope.org/zopetoolkit/ That's what it is for. It's a Sphinx site. Just a few updates that Wichert can point me to when I get confused would probably help both me and Wichert tremendously. :) I kept decisions here, though they should be reorganized: http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html You could probably start a new page like that. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] summary of suggestions
Hi again, One more suggestion I can make is a way to get an integrated changelog for lists of packages such as the ZTK. Right now it's hard to track what kind of changes there have been in the ZTK as a whole; you have to go through all packages. If there were a way to generate a unified changelog between two versions of a ztk.cfg (or other such files), that would be useful in doing releases. A long time ago I experimented with a way to turn a CHANGES.txt into an atom feed and then to aggregate those feeds into a Planet in order to get some idea of what's going on. Maybe that'd be an interesting approach to this. Regards, Martijn ___ Zope-Dev maillist - Zope-Dev@zope.org https://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - https://mail.zope.org/mailman/listinfo/zope-announce https://mail.zope.org/mailman/listinfo/zope )
