Hi there, Hanno, can you please update the zopetoolkit and do tests there as well when you make releases of packages maintained by the Zope Toolkit project? Because otherwise you're just wasting my time trying to sync things up again, and that's annoying. Not annoying me is one good reason, but there are other good reasons why you should be updating the ZTK but I'm sure the people in charge of the ZTK can express those. They haven't done so probably because they figured you already knew the reasons. Regards, Martijn
Hi there, Of course what applies to Hanno should apply to others making releases of packages maintained by the Zope Toolkit project as well. I think the ZTK leadership should figure out some kind of guidelines for this that people can follow. Maybe someone can write a tool too to check up how far a toolkit is out of sync with the latest releases. Just some ideas. Regards, Martijn
Hi there, Martijn Faassen wrote:
Of course what applies to Hanno should apply to others making releases of packages maintained by the Zope Toolkit project as well. I think the ZTK leadership should figure out some kind of guidelines for this that people can follow. Maybe someone can write a tool too to check up how far a toolkit is out of sync with the latest releases. Just some ideas.
Don't think you're off the hook with me though, Hanno. :) Hanno is special as he's maintaining a fork of the ZTK and was maintaining the ZTK already in the past before he forked it. If I were the ZTK leadership such a thing would probably frustrate me a lot, so it's a good thing I'm not. Instead I can just express my displeasure out loud. Regards, Martijn
Good evening :) If you have a specific issue with me, you might contact me in private. But with your follow-ups this turned into a more general issue. On Sun, May 2, 2010 at 10:59 PM, Martijn Faassen <faassen@startifact.com> wrote:
Martijn Faassen wrote:
Of course what applies to Hanno should apply to others making releases of packages maintained by the Zope Toolkit project as well. I think the ZTK leadership should figure out some kind of guidelines for this that people can follow. Maybe someone can write a tool too to check up how far a toolkit is out of sync with the latest releases. Just some ideas.
Don't think you're off the hook with me though, Hanno. :)
Hanno is special as he's maintaining a fork of the ZTK and was maintaining the ZTK already in the past before he forked it. If I were the ZTK leadership such a thing would probably frustrate me a lot, so it's a good thing I'm not. Instead I can just express my displeasure out loud.
The "ZTK" is on my list of things to look into and I'm committed to the idea. Jan-Wijbrand, Christophe and me started an off-list discussion on the specifics of the "ZTK release team". I expect us to define the process around package releases and updating the ZTK. It's not entirely clear to me who should and who is allowed to update the ZTK definition. We'll figure things out and once we have I'll stick to the rules. Hanno
Hanno Schlichting wrote:
Good evening :)
If you have a specific issue with me, you might contact me in private. But with your follow-ups this turned into a more general issue.
No, I think this needs to be public as the ZTK is a public project that I care about. And you're not playing your proper part in it. You're not going to listen to me (otherwise the fork would never have happened; you had an issue with listening to me), so I'm informing the rest of the community. Maybe you'll listen to them. The fork is counterproductive. And it's just annoying me. It's time for this annoyance to disappear. Regards, Martijn
On 5/3/10 12:20 , Martijn Faassen wrote:
Hanno Schlichting wrote:
Good evening :)
If you have a specific issue with me, you might contact me in private. But with your follow-ups this turned into a more general issue.
No, I think this needs to be public as the ZTK is a public project that I care about. And you're not playing your proper part in it. You're not going to listen to me (otherwise the fork would never have happened; you had an issue with listening to me), so I'm informing the rest of the community. Maybe you'll listen to them. The fork is counterproductive. And it's just annoying me. It's time for this annoyance to disappear.
Can we please not rehash an old discussion or make this personal? This has all been discussed too often already. Wichert.
Wichert Akkerman wrote:
Can we please not rehash an old discussion or make this personal? This has all been discussed too often already.
As far as I know, I've *never* discussed this fork on this list, but I might be wrong; feel free to dig the archives. But that doesn't matter: the fork is still there. So: wtf, Wichert? There is a fork of the ZTK being maintained today, right now. I want it to stop. Hanno, please stop the fork. I don't know what Hanno is trying to pull by saying he's going to "look into" the ZTK. He helped build the ZTK, and then he forked it, which took all of 5 minutes, and now 4 months down the road he's looking into the ZTK? I think it shouldn't take more than 10 minutes to unfork it. And if someone else is maintaining a fork of the ZTK, I'll be happy to single out that individual too. Feel free to fork the ZTK, Wichert, and I'll be complaining about *you*. If I fork the ZTK you get to complain about me. But you didn't, I didn't, but Hanno did. Regards, Martijn
On 5/3/10 12:51 , Martijn Faassen wrote:
Wichert Akkerman wrote:
Can we please not rehash an old discussion or make this personal? This has all been discussed too often already.
As far as I know, I've *never* discussed this fork on this list, but I might be wrong; feel free to dig the archives. But that doesn't matter: the fork is still there. So: wtf, Wichert?
Perhaps you haven't, but others have discussed the reason the fork was cerated and why it still exists. Since then many things have happened including the creation of the ZTK steering group, of which Hanno is a member. Hanno already stated that he intends to drop the ZTK fork in Zope2 once the ZTK is in an acceptable state for Zope2, so I do not see why this needs to be rediscussed again. Please see the list archives for that discussion and the full rationale. Wichert.
Wichert Akkerman wrote:
On 5/3/10 12:51 , Martijn Faassen wrote:
Wichert Akkerman wrote:
Can we please not rehash an old discussion or make this personal? This has all been discussed too often already. As far as I know, I've *never* discussed this fork on this list, but I might be wrong; feel free to dig the archives. But that doesn't matter: the fork is still there. So: wtf, Wichert?
Perhaps you haven't, but others have discussed the reason the fork was cerated and why it still exists. Since then many things have happened including the creation of the ZTK steering group, of which Hanno is a member.
The ZTK steering group was created about a year ago, so I'm not sure what you're trying to suggest here. I just hope you're not suggesting I didn't do anything in 2009. By the way: at the time I invited Hanno into the group, but he declined then, and I respect that, but just so you know. I must say it totally baffles me that the ZTK was acceptable to Zope 2 until january, and became unacceptable at that point. All answers are probably in that mailing list thread, but I can't be bothered to look it up. Please just make the fork go away. Regards, Martijn
On 5/3/10 13:07 , Martijn Faassen wrote:
Wichert Akkerman wrote:
On 5/3/10 12:51 , Martijn Faassen wrote:
Wichert Akkerman wrote:
Can we please not rehash an old discussion or make this personal? This has all been discussed too often already. As far as I know, I've *never* discussed this fork on this list, but I might be wrong; feel free to dig the archives. But that doesn't matter: the fork is still there. So: wtf, Wichert?
Perhaps you haven't, but others have discussed the reason the fork was cerated and why it still exists. Since then many things have happened including the creation of the ZTK steering group, of which Hanno is a member.
The ZTK steering group was created about a year ago, so I'm not sure what you're trying to suggest here.
Sorry, my mistake. I meant the ZTK release manage group, not the now defunct ZTK steering group,
I must say it totally baffles me that the ZTK was acceptable to Zope 2 until january, and became unacceptable at that point. All answers are probably in that mailing list thread, but I can't be bothered to look it up. Please just make the fork go away.
The needed steps to do that can be found in the list archives. Wichert.
On Mon, May 3, 2010 at 13:22, Martijn Faassen <faassen@startifact.com> wrote:
Wichert Akkerman wrote:
Sorry, my mistake. I meant the ZTK release manage group, not the now defunct ZTK steering group,
Well, if it's defunct or not is up to the members of the steering group. The steering group created itself, and may disband itself if it so wishes. It has all the right in the world to continue existing, even if the idea is that the ZTK oversight will be done by the release manager team instead.
If it's defunct someone better update the documentation.
The creation of the release manager team was only recently concluded. To expect zope process documentation to update quickly is unrealistic. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro wrote:
On Mon, May 3, 2010 at 13:22, Martijn Faassen <faassen@startifact.com> wrote:
Wichert Akkerman wrote:
Sorry, my mistake. I meant the ZTK release manage group, not the now defunct ZTK steering group,
Well, if it's defunct or not is up to the members of the steering group. The steering group created itself, and may disband itself if it so wishes. It has all the right in the world to continue existing, even if the idea is that the ZTK oversight will be done by the release manager team instead.
If it's defunct someone better update the documentation.
The creation of the release manager team was only recently concluded.
Two weeks ago. Process started a month ago.
To expect zope process documentation to update quickly is unrealistic.
Well, I'm disappointed in the zope documentation process then. Work faster! If you don't inform people about this release manager team thingy, you can't rightly expect people like me to care about it. Regards, Martijn
On 5/3/10 15:41 , Martijn Faassen wrote:
Lennart Regebro wrote:
On Mon, May 3, 2010 at 13:22, Martijn Faassen<faassen@startifact.com> wrote:
Wichert Akkerman wrote:
Sorry, my mistake. I meant the ZTK release manage group, not the now defunct ZTK steering group,
Well, if it's defunct or not is up to the members of the steering group. The steering group created itself, and may disband itself if it so wishes. It has all the right in the world to continue existing, even if the idea is that the ZTK oversight will be done by the release manager team instead.
If it's defunct someone better update the documentation.
The creation of the release manager team was only recently concluded.
Two weeks ago. Process started a month ago.
If we're going to make cheap shots: that's still a lot faster than the grok release cycle. Wichert.
On 2010-05-03, Wichert Akkerman <wichert@wiggy.net> wrote:
On 5/3/10 15:41 , Martijn Faassen wrote:
Lennart Regebro wrote:
On Mon, May 3, 2010 at 13:22, Martijn Faassen<faassen@startifact.com> wrote:
Wichert Akkerman wrote: If we're going to make cheap shots: that's still a lot faster than the grok release cycle.
Guys, please, this is like watching your parents fight ;-) Can't we all just get along? :-) As someone looking in from the outside (Plone), and hoping to become more active in the Zope community in the future, I wonder what it's going to take to restore some harmony and direction in here? It seems like I've been reading various flames for months now. To put things in perspective, for folks in here who may be "too close to it", the Zope ecosystem is *really* starting to shape up IMO (i.e. leaving the Zope 3 confusion in the past, etc.). I think I understand it now (after years of study), and can actually explain it to others! So let's try to keep up the *great* work and let the "little things" slide… 2cents, Alex
Wichert. _______________________________________________ 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 )
-- Alex Clark · http://aclark.net Author of Plone 3.3 Site Administration · http://aclark.net/plone-site-admin
Alex Clark wrote:
On 2010-05-03, Wichert Akkerman <wichert@wiggy.net> wrote:
On 5/3/10 15:41 , Martijn Faassen wrote:
Lennart Regebro wrote:
On Mon, May 3, 2010 at 13:22, Martijn Faassen<faassen@startifact.com> wrote:
Wichert Akkerman wrote: If we're going to make cheap shots: that's still a lot faster than the grok release cycle.
Guys, please, this is like watching your parents fight ;-) Can't we all just get along? :-)
I can't. I think I've contributed a lot to this community, I've tried to be fair and work out differences and make compromises. It wasn't easy. You'd think it'd get you some respect and trust. Then, when it came down to it, instead of respect, trust and a willingness to cooperate (and yes, I think I've tried to do all of that myself; I don't think I'm a hypocrite on this), I got a fork. Thanks guys. So I stepped down, as obviously people weren't willing to work with me. I tried to stay out of zope-dev for the last 4 months, as it just gets on my nerves now. But the fork continues. I see it in the checkins messages. It's causing me extra things to worry about - the new releases don't get tested with all the libraries in the ZTK, and I use other libraries in the ZTK. It's just so stupid, too. So unnecessary and counterproductive. But like it or not (I don't really like it much right now, to be honest), I still a user of the ZTK. I contribute to it. So I think that means I get to make suggestions and complain when I want to. That's how it works in an open source project. The leadership, whoever they are, will just have to deal with it. But forgive me when I don't feel particularly inclined to spare anyone's feelings. Even when I was trying to do that, I think I stepped on enough toes anyway, so why bother?
As someone looking in from the outside (Plone), and hoping to become more active in the Zope community in the future, I wonder what it's going to take to restore some harmony and direction in here? It seems like I've been reading various flames for months now.
I don't know. It'd help if people tried to work with each other instead and give each other a bit of credit, instead of fork or do whatever Wichert did in this thread (yeah, I know I'm in this thread too and doing the wrong stuff too. But Wichert, you're just not being constructive at all here, sorry). But I tried that and it didn't really work, so I am trying something else. That is, I think it *did* work (the ZTK is there, it's made a lot of progress), but it didn't work for *me*.
To put things in perspective, for folks in here who may be "too close to it", the Zope ecosystem is *really* starting to shape up IMO (i.e. leaving the Zope 3 confusion in the past, etc.). I think I understand it now (after years of study), and can actually explain it to others! So let's try to keep up the *great* work and let the "little things" slide…
It's not been a little thing to me, sorry. It felt like a big thing that didn't slide off but steamrollered over me. I now have four months distance from it and I'm still wounded by it. Sure, there are a lot of good things going on. I think it's great what BlueBream is up to. And Hanno's doing all kinds of good work; I'm happy to acknowledge that. And last week we finally decoupled Grok from most of the zope.app.* packages. I'm pretty happy about that, too. But as a group we aren't very good at treating people who attempt to lead for the good of the group. And seriously, you can't replace leadership with bureaucracy and do as well. Regards, Martijn
On Mon, May 3, 2010 at 15:41, Martijn Faassen <faassen@startifact.com> wrote:
Well, I'm disappointed in the zope documentation process then. Work faster!
:)
If you don't inform people about this release manager team thingy, you can't rightly expect people like me to care about it.
Heh. Martijn, I understand you are just shaking off all the shit that you had to take, but I'm not sure everyone gets the joke. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Lennart Regebro wrote:
On Mon, May 3, 2010 at 15:41, Martijn Faassen <faassen@startifact.com> wrote:
Well, I'm disappointed in the zope documentation process then. Work faster!
:)
If you don't inform people about this release manager team thingy, you can't rightly expect people like me to care about it.
Heh. Martijn, I understand you are just shaking off all the shit that you had to take, but I'm not sure everyone gets the joke.
That's because it's not a joke. It's because I'm pissed off. Answers like "read the mailing list archives" and "we're working on it" are legitimate sometimes. But they're also all too easily the answers of a bureaucracy that's stalling things as bureaucracies do. They're not very useful in a constructive discussion. Regards, Martijn
On Mon, May 3, 2010 at 17:30, Martijn Faassen <faassen@startifact.com> wrote:
Answers like "read the mailing list archives" and "we're working on it" are legitimate sometimes. But they're also all too easily the answers of a bureaucracy that's stalling things as bureaucracies do. They're not very useful in a constructive discussion.
But in this case it's not bureaucracy that's stalling. It's the community readjusting to a large extent to fill the hole that appeared when you stepped aside. And that readjustment will NOT take a couple of days, it will take longer. We will need to keep the ZTK up to date, and I know people are committed to the ZTK so it will be. But we'll need to figure out the process, but that process isn't really done yet, and it's hard to document what doesn't exist. I don't know anything about the fork, but my view of the fork is that of Hanno wants a fork, Hanno can have a fork, as long as he doesn't try to poke anyones eye out with it. If it's a stupid waste of time, it's Hannos stupid waste of time. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Hi there, On Mon, May 3, 2010 at 6:06 PM, Lennart Regebro <regebro@gmail.com> wrote:
I don't know anything about the fork, but my view of the fork is that of Hanno wants a fork, Hanno can have a fork, as long as he doesn't try to poke anyones eye out with it. If it's a stupid waste of time, it's Hannos stupid waste of time.
Hanno is making releases of packages in the ZTK. So it's not just Hanno's waste of time; it's mine too. That's where I was coming from when this discussion started. It didn't help that the action of making the fork really hurt me at the time - I'm not inclined to be calm about it. Regards, Martijn
On 4 May 2010 00:09, Martijn Faassen <faassen@startifact.com> wrote:
Hanno is making releases of packages in the ZTK. So it's not just Hanno's waste of time; it's mine too. That's where I was coming from when this discussion started. It didn't help that the action of making the fork really hurt me at the time - I'm not inclined to be calm about it.
Unfortunately, that probably means you're going to be ignored. I'm not saying that to spite you. It's a dispassionate evaluation of what's going on right now. If I could, I'd try to get you, Hanno, Lennart, Chris McDonough and a large amount of beer in the same room. I don't think this is going to get anywhere by email. I don't think anyone even knows what "this" really is. Martin
On Mon, May 3, 2010 at 18:09, Martijn Faassen <faassen@startifact.com> wrote:
Hanno is making releases of packages in the ZTK. So it's not just Hanno's waste of time; it's mine too.
Obviously he shouldn't hurt the main ZTK in any way. That would be a problem (even if i missed this incident completely and hence dn't understand what or how things broke). But I think the fork in itself is a red herring. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
Hi there, On Mon, May 3, 2010 at 7:48 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Mon, May 3, 2010 at 18:09, Martijn Faassen <faassen@startifact.com> wrote:
Hanno is making releases of packages in the ZTK. So it's not just Hanno's waste of time; it's mine too.
Obviously he shouldn't hurt the main ZTK in any way. That would be a problem (even if i missed this incident completely and hence dn't understand what or how things broke). But I think the fork in itself is a red herring.
I spent months trying to get everybody together and there was a fork because we had a disagreement in december. Instead of working together and working with me, people just forked. That really hurt. With that lack of commitment to the ZTK, I didn't feel inclined to be committed to it either. I haven't seen a plausible reason why the fork should be necessary. It just uses some updated versions of packages (mostly bugfix releases) that would have been updated in the ZTK as well if people had bothered to update them. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Martijn Faassen wrote:
On Mon, May 3, 2010 at 7:48 PM, Lennart Regebro <regebro@gmail.com> wrote:
On Mon, May 3, 2010 at 18:09, Martijn Faassen <faassen@startifact.com> wrote:
Hanno is making releases of packages in the ZTK. So it's not just Hanno's waste of time; it's mine too. Obviously he shouldn't hurt the main ZTK in any way. That would be a problem (even if i missed this incident completely and hence dn't understand what or how things broke). But I think the fork in itself is a red herring.
I spent months trying to get everybody together and there was a fork because we had a disagreement in december. Instead of working together and working with me, people just forked. That really hurt. With that lack of commitment to the ZTK, I didn't feel inclined to be committed to it either.
I expect to see Zope2 trunk move to using the ZTK versions list quite soon: more than that, I'm willing to to the work to see that it happens (verifying that everything passes / works with the change), and give Hanno the patch to make it so, assuming he doesn't get around to it.
I haven't seen a plausible reason why the fork should be necessary. It just uses some updated versions of packages (mostly bugfix releases) that would have been updated in the ZTK as well if people had bothered to update them.
If the release manager group gets consensus quickly on how their projects' interests align in the ZTK, then the fork can go away. Until then, pushing changes into the ZTK without consulting those projects' needs is premature. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvfEdsACgkQ+gerLs4ltQ5lIACgwyWGEHhFRXfBVng1peqKGlVJ vbIAoLiuAo2sgmT7WxgjuEoNy9mbOBz2 =EMgZ -----END PGP SIGNATURE-----
Hey, Tres Seaver wrote: [snip]
I expect to see Zope2 trunk move to using the ZTK versions list quite soon: more than that, I'm willing to to the work to see that it happens (verifying that everything passes / works with the change), and give Hanno the patch to make it so, assuming he doesn't get around to it.
Cool. That's good to hear and something I really need to hear. :) I think you'll mostly be giving the ztk.cfg a patch to make it so, as Zope 2's list is ahead with a lot of mostly bugfix versions.
I haven't seen a plausible reason why the fork should be necessary. It just uses some updated versions of packages (mostly bugfix releases) that would have been updated in the ZTK as well if people had bothered to update them.
If the release manager group gets consensus quickly on how their projects' interests align in the ZTK, then the fork can go away. Until then, pushing changes into the ZTK without consulting those projects' needs is premature.
Yes, such a change without such consultation was what created the problem in december. But that was a structural change of definition -- what is *in* the ZTK, not one of which releases were in the ZTK. It had something to do with letting the last zope.app.* dependency go from the cluster of zope.* packages. I'll note a short version list is not needed in order to feel that you're shrinking dependencies. I've been using depgraph for that. I will admit though that the longer the version list that is tested, the slower the tests and buildout run, of course, so that may be a concern for some (but how heavy should it weigh?). Could be something for the release managers to flesh out the balance between things. We haven't had the opportunity to have conflicts about specific releases yet ("I want zope.interface 4.3!" "no! 4.5!"). I think it's not a very big issue until someone starts doing a big dependency refactoring again - but that again is a structural issue, not a version issue. Regards, Martijn
Am 03.05.2010, 19:59 Uhr, schrieb Martijn Faassen <faassen@startifact.com>:
I haven't seen a plausible reason why the fork should be necessary. It just uses some updated versions of packages (mostly bugfix releases) that would have been updated in the ZTK as well if people had bothered to update them.
Maartijn, I think that most people on this list are very aware of the work you have put into Zope and particularly your dedicated refactoring of the ZTK last year. It is, unfortunately, only too common on volunteer projects that people burn out or get frustrated when things do not go their way (for whatever reason). I do not recall all the discussions that led to your resignation in December and I'm not about to trawl through all the threads for it either. But I don't understand much of today's thread that seems technically vague but personally specific. FWIW this is a very poor strategy to win people over to your point of view. You have not succeeded in making me aware of: 1) the issue and 2) a possible solution. Additionally to suggest that there has been no progress in this area over the last couple of months seems contrary to the facts. You have obviously a big, and possibly very justified, itch to scratch. Is it possible to present it less acrimoniously? If you succeed in monopolising the conversation we will be back where started. Respectfully, Charlie -- Charlie Clark Managing Director Clark Consulting & Research German Office Helmholtzstr. 20 Düsseldorf D- 40215 Tel: +49-211-600-3657 Mobile: +49-178-782-6226
Charlie Clark wrote:
FWIW this is a very poor strategy to win people over to your point of view.
I'm not trying to win over people to my point of view. I tried that last year, but people just forked when they couldn't work it out with me. I've learned that rash actions without consideration is the favorite method to accomplish things, so I'm trying me some of that to see whether that works better.
You have not succeeded in making me aware of: 1) the issue and 2) a possible solution.
The ZTK consists of a list that says which packages work together. So it's a list like: zope.component = 3.4 zope.interface = 3.7 zope.container = 3.10 The ZTK also has test infrastructure. So when (or even before) you release zope.container 3.11, you can easily run all the tests of all the packages in the ZTK and see whether anything breaks with your changes. The list of ZTK packages is used (at least subsets of this list) by Grok, BlueBream and, until december, Zope 2. Last december Hanno made progress on the ZTK's dependency structure, removing a lot of dependencies on packages. In his enthusiasm, he unilaterally just removed all those suddenly-unneeded (by him!) packages from the ZTK, without discussion. The version information was just gone. I wasn't happy that, both in my capacity as a Grok developer and in my capacity of someone honestly trying to balance the interests of parties using the ZTK. I knew those packages needed to be tested at least for Grok for a while longer. (and BlueBream too, but that didn't exist yet. We had a Zope 3 in limbo then). So I objected to this sudden removal, and went and restored the information that Hanno removed until we could discuss the right course of action. This reversion greatly upset the Zope 2 developers and they decided, an hour later, to fork the ZTK and maintain their own list of versions. We were in the middle of a discussion that was about a lot of stuff, but also included constructive attempts by me to try to resolve the situation so we could continue to work together. There was no real reason to do so - Zope 2 could've continued to use the longer version list just fine without technical problems (Grok does the same right now). But as soon as the unneeded packages weren't needed anymore by Zope 2, they wanted to stop caring about them at that very moment. I drew the consequences and a while later stepped down as ZTK steering group member. We've been in this situation ever since. It wouldn't have bothered me so much, except that people make releases. So, Zope 2 people release packages that are also in the ZTK and update their own version list and not the ZTK. They don't run the ZTK tests against their new releases. They leave it up to the ZTK maintainers to do those updates and run the ZTK's tests. This is rather annoying. The lists are needlessly out of sync.
Additionally to suggest that there has been no progress in this area over the last couple of months seems contrary to the facts. You have obviously a big, and possibly very justified, itch to scratch. Is it possible to present it less acrimoniously? If you succeed in monopolising the conversation we will be back where started.
No, I cannot present it less acrimoniously. The lack of commitment and trust displayed back then still hurts me too much for that. Regards, Martijn
On Mon, May 3, 2010 at 9:56 PM, Martijn Faassen <faassen@startifact.com> wrote:
Last december Hanno made progress on the ZTK's dependency structure, removing a lot of dependencies on packages. In his enthusiasm, he unilaterally just removed all those suddenly-unneeded (by him!) packages from the ZTK, without discussion.
My actions last December had an unfortunate effect. I assumed a common understanding of what the ZTK should be and tried to work towards that, but it turned out that understanding wasn't shared after all. I should have known better and discussed things before taking any actions. For not discussing things properly I apologize. In didn't see any chance of making any progress during the heated debate following those events, so I decided to let things cool off and let everyone work on their own for a while.
No, I cannot present it less acrimoniously. The lack of commitment and trust displayed back then still hurts me too much for that.
Martijn and me tried to discuss this off-list. I think at this stage there's no way to solve our disagreement. I'd rather not continue any of this in public, as I don't see how this would have any constructive effect. The Zope community asked Christophe, Jan-Wijbrand and me to act as a release team for the ZTK and we started working on this task. I intend to continue to work in this group. If the Zope community feels I'm not qualified for the job or the other two team members don't want to work with me, I'll happily step down. Hanno
Hi there, On Mon, May 3, 2010 at 10:26 PM, Hanno Schlichting <hanno@hannosch.eu> wrote:
On Mon, May 3, 2010 at 9:56 PM, Martijn Faassen <faassen@startifact.com> wrote:
Last december Hanno made progress on the ZTK's dependency structure, removing a lot of dependencies on packages. In his enthusiasm, he unilaterally just removed all those suddenly-unneeded (by him!) packages from the ZTK, without discussion.
My actions last December had an unfortunate effect. I assumed a common understanding of what the ZTK should be and tried to work towards that, but it turned out that understanding wasn't shared after all. I should have known better and discussed things before taking any actions. For not discussing things properly I apologize.
Okay, apology accepted, but we already discussed this anyway privately back in december. I apologized for the revert instead of working out the better plan that I came up with a few hours later. In my defense, I was thinking on my feet and we were still touching zope app packages that needed to be testable, so I didn't want the situation where testing this was not possible with the ZTK to linger. I also thought that I was supposed to maintain the process we had in place for removing packages and this was a bold violation of it, compounded by people arguing *I* had the burden of proof after this fait accomplit. I wish there were more steering group members involved at the time, but I couldn't really help that.
In didn't see any chance of making any progress during the heated debate following those events, so I decided to let things cool off and let everyone work on their own for a while.
We were making progress in that debate, and actually pretty rapidly, though it was hard to do amongst all the heat. To me, your walking out raised the immediate heat level (though I tried to ignore it), and made it completely impossible for me to cool off, as this signaled an end to collaboration and a lack of trust in me. I tried to cool off for 4 months, but today I still found myself upset about it, so that obviously wasn't working very well.
No, I cannot present it less acrimoniously. The lack of commitment and trust displayed back then still hurts me too much for that.
Martijn and me tried to discuss this off-list. I think at this stage there's no way to solve our disagreement. I'd rather not continue any of this in public, as I don't see how this would have any constructive effect.
I don't know, perhaps you'll get me more engaged again. I'm in the situation that I have to work with people here, I want to work with people here, but my trust in my ability to work with people here was seriously damaged. Maybe that gets me out of my dilemma.
The Zope community asked Christophe, Jan-Wijbrand and me to act as a release team for the ZTK and we started working on this task. I intend to continue to work in this group. If the Zope community feels I'm not qualified for the job or the other two team members don't want to work with me, I'll happily step down.
I think you're qualified for the job and I trust you'll do a good one. I just hope you'll get more trust and credit than I got in december. Regards, Martijn
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hanno Schlichting wrote:
On Mon, May 3, 2010 at 9:56 PM, Martijn Faassen <faassen@startifact.com> wrote:
Last december Hanno made progress on the ZTK's dependency structure, removing a lot of dependencies on packages. In his enthusiasm, he unilaterally just removed all those suddenly-unneeded (by him!) packages from the ZTK, without discussion.
My actions last December had an unfortunate effect. I assumed a common understanding of what the ZTK should be and tried to work towards that, but it turned out that understanding wasn't shared after all. I should have known better and discussed things before taking any actions. For not discussing things properly I apologize. In didn't see any chance of making any progress during the heated debate following those events, so I decided to let things cool off and let everyone work on their own for a while.
Could we go ahead and move the Zope2 trunk back to 'extends ztk.cfg w/ the minimal possible deltas", instead of the current "keep ourselves to ourselves" state? It would be even better if that meant that Grok and BlueBream would walk the tightrope with Zope2, and give up the relative safety of a pinned revision of ztk.cfg on their own trunks, sharing instead with the Zope2 trunk a "white knuckle grip" on the contents of zopetoolkit/trunk/ztk.cfg until we can get ZTK to a release.
The Zope community asked Christophe, Jan-Wijbrand and me to act as a release team for the ZTK and we started working on this task. I intend to continue to work in this group. If the Zope community feels I'm not qualified for the job or the other two team members don't want to work with me, I'll happily step down.
I believe that the three of you are ideal as representatives of the major downstream consumers of the ZTK. I hope that your triumvirate can converge quickly on a process of achieving consensus on the maximal set of shared package versions between the projects. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkvfZKQACgkQ+gerLs4ltQ40BACdEXBzDtEKkg+GSv8mSmyybjCH N8oAnRnWnpsbUaM6Qwo5Jv3yKmSg1oi+ =P0Vc -----END PGP SIGNATURE-----
Hi there, Hanno Schlichting wrote:
I expect us to define the process around package releases and updating the ZTK. It's not entirely clear to me who should and who is allowed to update the ZTK definition. We'll figure things out and once we have I'll stick to the rules.
My few cents: I think everybody should be allowed to update the ZTK definition. They should follow certain guidelines (run tests, and such. Maybe updating a changelog is a good idea too). Stability can be taken care of by branching and tagging. I.e. the same guidelines as we have for other pieces of code can be a good starting point. To get back to the discussion that caused the fork. We have implicit, but I think widely understood and accepted, rules about backwards compatibility. So we don't expect someone to rip out half the code of a Python package just like that. Generally we expect the tests to continue to run. Similarly we shouldn't just drop things from the ZTK without special action (this involves removing tests too!). We started to try to spell some of that out here long ago: http://docs.zope.org/zopetoolkit/about/coreextra.html But I'd hate it if the ZTK trunk became some kind of bureaucratic maze, as it'd stop me from getting work done. Regards, Martijn
On 5/3/10 12:34 , Martijn Faassen wrote:
Hi there,
Hanno Schlichting wrote:
I expect us to define the process around package releases and updating the ZTK. It's not entirely clear to me who should and who is allowed to update the ZTK definition. We'll figure things out and once we have I'll stick to the rules.
My few cents:
I think everybody should be allowed to update the ZTK definition. They should follow certain guidelines (run tests, and such. Maybe updating a changelog is a good idea too). Stability can be taken care of by branching and tagging. I.e. the same guidelines as we have for other pieces of code can be a good starting point.
To get back to the discussion that caused the fork. We have implicit, but I think widely understood and accepted, rules about backwards compatibility. So we don't expect someone to rip out half the code of a Python package just like that. Generally we expect the tests to continue to run. Similarly we shouldn't just drop things from the ZTK without special action (this involves removing tests too!). We started to try to spell some of that out here long ago:
http://docs.zope.org/zopetoolkit/about/coreextra.html
But I'd hate it if the ZTK trunk became some kind of bureaucratic maze, as it'd stop me from getting work done.
I suggest that we wait impatiently for the ZTK steering committee to come up with a useful policy instead of trying to do their work when none of us volunteered for the task. Wichert.
Wichert Akkerman wrote:
I suggest that we wait impatiently for the ZTK steering committee to come up with a useful policy instead of trying to do their work when none of us volunteered for the task.
I don't understand your suggestion. Could you rephrase it? I'm a ZTK user, and I'm dissatisfied. I'm complaining. What's more, I'm actually offering constructive suggestions. Are you? Regards, Martijn
On 5/3/10 12:52 , Martijn Faassen wrote:
Wichert Akkerman wrote:
I suggest that we wait impatiently for the ZTK steering committee to come up with a useful policy instead of trying to do their work when none of us volunteered for the task.
I don't understand your suggestion. Could you rephrase it?
I'm a ZTK user, and I'm dissatisfied. I'm complaining. What's more, I'm actually offering constructive suggestions. Are you?
A ZTK steering group was created to help define and manage the ZTK. You did not volunteer for that, and neither did I. Hanno did, so why not let him do his job instead of distracting him by rehashing a discussion that already happened on this list. Wichert.
Wichert Akkerman wrote:
On 5/3/10 12:52 , Martijn Faassen wrote:
Wichert Akkerman wrote:
I suggest that we wait impatiently for the ZTK steering committee to come up with a useful policy instead of trying to do their work when none of us volunteered for the task. I don't understand your suggestion. Could you rephrase it?
I'm a ZTK user, and I'm dissatisfied. I'm complaining. What's more, I'm actually offering constructive suggestions. Are you?
A ZTK steering group was created to help define and manage the ZTK. You did not volunteer for that, and neither did I. Hanno did, so why not let him do his job instead of distracting him by rehashing a discussion that already happened on this list.
I'm a ZTK user. I thought this was the mailing list for ZTK users to bring up issues they have? Am I to understand that this open source project works in such a way that we can't even say anything until the steering group is done coming up with guidelines? How *do* I ask the steering group for things? Are suggestions really off the table? I think you should explain things better to newcomers such as me. :) Last year you weren't so overly protective of the ZTK steering group. What's more, you sound like you think the ZTK steering group formed this year! Wow. You seem to have forgotten 2009 already? I'd be mightily pissed off that you're ignoring my hard work last year if it weren't so hilariously silly. :) Maybe you're worried I'm trying to take over. I'm not, I'm just a user and contributor to this project. Anyway, I didn't realize the steering group got disbanded and reformed; the Zope Toolkit documentation still seems to refer to the old steering group: http://docs.zope.org/zopetoolkit/steeringgroup/members.html Someone should update it. That way people don't have to go through the mailing list archives to find decisions. This was something that the 2009 incarnation of the steering group was trying to do and I think the 2010 version would do well to emulate that, while of course trying to improve on the things that didn't work so well last year. Regards, Martijn
On Sun, May 2, 2010 at 22:52, Martijn Faassen <faassen@startifact.com> wrote:
Of course what applies to Hanno should apply to others making releases of packages maintained by the Zope Toolkit project as well. I think the ZTK leadership should figure out some kind of guidelines for this that people can follow.
That would be great. This sounds like something to discuss on Tuesday. -- Lennart Regebro: Python, Zope, Plone, Grok http://regebro.wordpress.com/ +33 661 58 14 64
On Sun, May 2, 2010 at 10:52 PM, Martijn Faassen <faassen@startifact.com> wrote:
Hi there,
Of course what applies to Hanno should apply to others making releases of packages maintained by the Zope Toolkit project as well. I think the ZTK leadership should figure out some kind of guidelines for this that people can follow. Maybe someone can write a tool too to check up how far a toolkit is out of sync with the latest releases. Just some ideas.
For the tool, I think I did it already. I modified one of Hanno's script some times ago: cd zopetoolkit/trunk bin/buildout -c checknew.cfg bin/python checknew.py Vincent
Vincent Fretin wrote:
For the tool, I think I did it already. I modified one of Hanno's script some times ago: cd zopetoolkit/trunk bin/buildout -c checknew.cfg bin/python checknew.py
Cool! This tool should be documented if it isn't already. Why is this in a separate .cfg unlike the other tools that come with the ZTK? Unless creating this extra script is very expensive, I think it makes sense to generate it in 'bin' along with the rest of the scripts. Regards, Martijn
Martijn Faassen wrote: [snip]
Why is this in a separate .cfg unlike the other tools that come with the ZTK? Unless creating this extra script is very expensive, I think it makes sense to generate it in 'bin' along with the rest of the scripts.
To expand on that, it'd be nice if it were also easy to integrate in other toolkits such as the Grok toolkit. I imagine the BlueBream people would also like to have such a thing. The other scripts (such as the cool depgraph stuff that Hanno created) are reusable in that way, and it's been very nice. Regards, Martijn
Vincent Fretin a écrit :
On Sun, May 2, 2010 at 10:52 PM, Martijn Faassen <faassen@startifact.com> wrote:
Hi there,
Of course what applies to Hanno should apply to others making releases of packages maintained by the Zope Toolkit project as well. I think the ZTK leadership should figure out some kind of guidelines for this that people can follow. Maybe someone can write a tool too to check up how far a toolkit is out of sync with the latest releases. Just some ideas.
For the tool, I think I did it already. I modified one of Hanno's script some times ago: cd zopetoolkit/trunk bin/buildout -c checknew.cfg bin/python checknew.py
I have already started to turn this script into a buildout recipe (probably z3c.recipe.checknew). I will make sure it can discover either minor bugfix versions or major versions, and be able to create a versions.cfg. Christophe
Vincent _______________________________________________ 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 )
Le 04/05/2010 00:04, Christophe Combelles a écrit :
Vincent Fretin a écrit :
On Sun, May 2, 2010 at 10:52 PM, Martijn Faassen<faassen@startifact.com> wrote:
Hi there,
Of course what applies to Hanno should apply to others making releases of packages maintained by the Zope Toolkit project as well. I think the ZTK leadership should figure out some kind of guidelines for this that people can follow. Maybe someone can write a tool too to check up how far a toolkit is out of sync with the latest releases. Just some ideas.
For the tool, I think I did it already. I modified one of Hanno's script some times ago: cd zopetoolkit/trunk bin/buildout -c checknew.cfg bin/python checknew.py
I have already started to turn this script into a buildout recipe (probably z3c.recipe.checknew). I will make sure it can discover either minor bugfix versions or major versions, and be able to create a versions.cfg.
It's now released as z3c.checkversions http://pypi.python.org/pypi/z3c.checkversions It's not a recipe but a console_script. So that it can be used in a virtualenv as well, without buildout. For a buildout, you just have to add it in the buildout eggs: it creates a checkversions script that can detect new versions (minor or major, depending on the -l option). Christophe
Christophe
Vincent _______________________________________________ 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 )
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. * 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. * (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. Regards, Martijn
Hi Martijn, On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen <faassen@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
Hanno Schlichting wrote:
Hi Martijn,
On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen <faassen@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
-----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 <faassen@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 tseaver@palladion.com Palladion Software "Excellence by Design" http://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-----
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
On Mon, May 3, 2010 at 20:13, Martijn Faassen <faassen@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
Lennart Regebro wrote:
On Mon, May 3, 2010 at 20:13, Martijn Faassen <faassen@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
On Mon, May 3, 2010 at 21:57, Martijn Faassen <faassen@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
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 )
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
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
participants (10)
-
Alex Clark -
Charlie Clark -
Christophe Combelles -
Hanno Schlichting -
Lennart Regebro -
Martijn Faassen -
Martin Aspeli -
Tres Seaver -
Vincent Fretin -
Wichert Akkerman