Summary of today's developer meeting
Hi, here's my first shot at a summary of today's meeting. I found the meeting itself very positive and energetic - thanks again to everyone who joined. If anyone knows another good place to announce this summary (we should be more visible to the outside world!), please feel free to post them (or link to them) somewhere and maybe tell me for the future. Cheers, Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
On Tue, Mar 2, 2010 at 11:32 AM, Christian Theune <ct@gocept.com> wrote:
here's my first shot at a summary of today's meeting.
Thanks, Christian! I definitely appreciate this summary, since I was visually impaired at the time of the meeting (and still am, but it's returning...). -Fred -- Fred L. Drake, Jr. <fdrake at gmail.com> "Chaos is the score upon which reality is written." --Henry Miller
Hi there,
Chris McDonough suggests to ponder further structuring of the ZTK into separate sub-sets which might allow us to get better mileage regarding maintenance and release management. He gave the example of the "Bicycle Toolkit" (zope.component, zope.configuration, zope.interface).
-1 We already have had issues with people changing things in ztk.cfg that broke things in zopeapp.cfg, because they don't want to test it. If we were to split things further, we'll see more breakage and more integration issues as people won't bother to test even less. For now, just see the extra packages as the ultimate in compatibility tests and run them please. Furthermore, the bicycle toolkit is the only candidate for such splitting up right now; other groupings don't seem to be well defined. Finally, people who want fine grained already have the ultimate in fine-grained in the form of individual releases. Maybe next year. Regards, Martijn
On 3/2/10 1:09 PM, Martijn Faassen wrote:
Hi there,
Chris McDonough suggests to ponder further structuring of the ZTK into separate sub-sets which might allow us to get better mileage regarding maintenance and release management. He gave the example of the "Bicycle Toolkit" (zope.component, zope.configuration, zope.interface).
-1
We already have had issues with people changing things in ztk.cfg that broke things in zopeapp.cfg, because they don't want to test it. If we were to split things further, we'll see more breakage and more integration issues as people won't bother to test even less.
I don't know who "people" are, and I don't know who "they" are, and I don't know who broke what. The reward is increased potential for reuse outside the various Zope framework stacks. It'd be a lot more palatable for people to see docs and a website for a notional "Zope Form Generation" package that it would be for them to need to extract such a thing from "the ZTK" wholesale. Splitting things across functional boundaries like this would put a more reasonable end-user face on zopey things I think. And maybe I wouldn't have to rewrite everything all the time due to people freaking out about things named "zope.*" if they were better organized into functional categories. - C
On Tue, Mar 2, 2010 at 2:18 PM, Chris McDonough <chrism@plope.com> wrote:
On 3/2/10 1:09 PM, Martijn Faassen wrote:
Hi there,
Chris McDonough suggests to ponder further structuring of the ZTK into separate sub-sets which might allow us to get better mileage regarding maintenance and release management. He gave the example of the "Bicycle Toolkit" (zope.component, zope.configuration, zope.interface).
-1
We already have had issues with people changing things in ztk.cfg that broke things in zopeapp.cfg, because they don't want to test it. If we were to split things further, we'll see more breakage and more integration issues as people won't bother to test even less.
I don't know who "people" are, and I don't know who "they" are, and I don't know who broke what.
The reward is increased potential for reuse outside the various Zope framework stacks. It'd be a lot more palatable for people to see docs and a website for a notional "Zope Form Generation" package that it would be for them to need to extract such a thing from "the ZTK" wholesale. Splitting things across functional boundaries like this would put a more reasonable end-user face on zopey things I think. And maybe I wouldn't have to rewrite everything all the time due to people freaking out about things named "zope.*" if they were better organized into functional categories.
I think you're confusing management and reuse (packaging including dependencies). We all want people to be able to reuse parts of the ZTK. There's broad agreement that we want to clean up dependencies. What's being advocated by many of us is that the ZTK be managed as a whole (for some definition of the whole that shrinks somewhat over time) to allow us to clean things up without causing breakage for people using the ZTK. No one should have to extract anything from the ZTK, because, AFAIK, the ZTK isn't a distribution. Jim -- Jim Fulton
On 3/2/10 2:50 PM, Jim Fulton wrote:
On Tue, Mar 2, 2010 at 2:18 PM, Chris McDonough<chrism@plope.com> wrote:
On 3/2/10 1:09 PM, Martijn Faassen wrote:
Hi there,
Chris McDonough suggests to ponder further structuring of the ZTK into separate sub-sets which might allow us to get better mileage regarding maintenance and release management. He gave the example of the "Bicycle Toolkit" (zope.component, zope.configuration, zope.interface).
-1
We already have had issues with people changing things in ztk.cfg that broke things in zopeapp.cfg, because they don't want to test it. If we were to split things further, we'll see more breakage and more integration issues as people won't bother to test even less.
I don't know who "people" are, and I don't know who "they" are, and I don't know who broke what.
The reward is increased potential for reuse outside the various Zope framework stacks. It'd be a lot more palatable for people to see docs and a website for a notional "Zope Form Generation" package that it would be for them to need to extract such a thing from "the ZTK" wholesale. Splitting things across functional boundaries like this would put a more reasonable end-user face on zopey things I think. And maybe I wouldn't have to rewrite everything all the time due to people freaking out about things named "zope.*" if they were better organized into functional categories.
I think you're confusing management and reuse (packaging including dependencies). We all want people to be able to reuse parts of the ZTK. There's broad agreement that we want to clean up dependencies.
What's being advocated by many of us is that the ZTK be managed as a whole (for some definition of the whole that shrinks somewhat over time) to allow us to clean things up without causing breakage for people using the ZTK.
No one should have to extract anything from the ZTK, because, AFAIK, the ZTK isn't a distribution.
You've both successfully beaten any initiative out of me again. Well done. Full speed ahead. - C
Am Mittwoch 03 März 2010 01:28:21 schrieb Chris McDonough:
On 3/2/10 2:50 PM, Jim Fulton wrote:
On Tue, Mar 2, 2010 at 2:18 PM, Chris McDonough<chrism@plope.com> wrote:
On 3/2/10 1:09 PM, Martijn Faassen wrote:
Hi there,
Chris McDonough suggests to ponder further structuring of the ZTK into separate sub-sets which might allow us to get better mileage regarding maintenance and release management. He gave the example of the "Bicycle Toolkit" (zope.component, zope.configuration, zope.interface).
-1
I don't know who "people" are, and I don't know who "they" are, and I don't know who broke what.
No one should have to extract anything from the ZTK, because, AFAIK, the ZTK isn't a distribution.
You've both successfully beaten any initiative out of me again. Well done. Full speed ahead.
Hmmm, interesting: --------------- snip ------------------- def hickhack(*kd): probabitlity = [0]*99 + [1] return random.choice(probability) def zope_community_work(): while 1: someone = random.choice(community) give_input(someone) disagree_members = ['cmember1', 'cmember2', 'cmember3'] disagree(someone, disagree_members) for i in range(20): agree = hickhack( random.choice([someone]*10+disagree_members*2+community))) if agree: break if agree: worker_thread.start() else: for i in range 4: feel_pissed_off(random.choice([someone]*10+disagree_members)) for i in range 10: sleep 100 print "Stalemate!" ---------------- snip ----------------- As anyone can see, "worker_thread" is not started often, which is not optimal. How could this be improved? Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
On Wed, Mar 03, 2010 at 10:06:18AM +0100, Hermann Himmelbauer wrote:
Am Mittwoch 03 März 2010 01:28:21 schrieb Chris McDonough:
On 3/2/10 2:50 PM, Jim Fulton wrote:
On Tue, Mar 2, 2010 at 2:18 PM, Chris McDonough<chrism@plope.com> wrote:
On 3/2/10 1:09 PM, Martijn Faassen wrote:
Hi there,
Chris McDonough suggests to ponder further structuring of the ZTK into separate sub-sets which might allow us to get better mileage regarding maintenance and release management. He gave the example of the "Bicycle Toolkit" (zope.component, zope.configuration, zope.interface).
-1
I don't know who "people" are, and I don't know who "they" are, and I don't know who broke what.
No one should have to extract anything from the ZTK, because, AFAIK, the ZTK isn't a distribution.
You've both successfully beaten any initiative out of me again. Well done. Full speed ahead.
Hmmm, interesting:
--------------- snip -------------------
def hickhack(*kd): probabitlity = [0]*99 + [1] ^
Typo ;) Using 3 spaces for indentation is an... interesting... choice.
return random.choice(probability)
def zope_community_work(): while 1:
'while True' looks better.
someone = random.choice(community) give_input(someone)
disagree_members = ['cmember1', 'cmember2', 'cmember3'] disagree(someone, disagree_members)
for i in range(20): agree = hickhack( random.choice([someone]*10+disagree_members*2+community)))
hickhack ignores its argument. I'm not sure what you're trying to express here.
if agree: break
if agree: worker_thread.start() else: for i in range 4:
You started omitting parentheses from function calls.
feel_pissed_off(random.choice([someone]*10+disagree_members)) for i in range 10: sleep 100 print "Stalemate!"
---------------- snip -----------------
As anyone can see, "worker_thread" is not started often, which is not optimal. How could this be improved?
More positive feedback, less negative feedback. Marius Gedminas now wondering if his humorous deadpan PEP-8 review of pseudocode will be considered positive or negative... -- http://pov.lt/ -- Zope 3 consulting and development
Am Mittwoch 03 März 2010 11:06:22 schrieb Marius Gedminas:
def zope_community_work(): while 1:
'while True' looks better.
someone = random.choice(community) give_input(someone)
disagree_members = ['cmember1', 'cmember2', 'cmember3'] disagree(someone, disagree_members)
for i in range(20): agree = hickhack( random.choice([someone]*10+disagree_members*2+community)))
hickhack ignores its argument. I'm not sure what you're trying to express here.
Well, I'll definitely use pyflakes and extensive unit testing next time. ;-) Best Regards, Hermann -- hermann@qwer.tk GPG key ID: 299893C7 (on keyservers) FP: 0124 2584 8809 EF2A DBF9 4902 64B4 D16B 2998 93C7
On Wed, Mar 03, 2010 at 12:06:22PM +0200, Marius Gedminas wrote:
Marius Gedminas now wondering if his humorous deadpan PEP-8 review of pseudocode will be considered positive or negative...
I, for one, have always thought them positive and read them eagerly. But, then you've never reviewed one of my, admittedly few, commits;) -- Brian Sutherland
Hi there, I've said my piece. I'm not going to argue about it. Regards, Martijn
Morning, On 03/02/2010 07:09 PM, Martijn Faassen wrote:
Hi there,
Chris McDonough suggests to ponder further structuring of the ZTK into separate sub-sets which might allow us to get better mileage regarding maintenance and release management. He gave the example of the "Bicycle Toolkit" (zope.component, zope.configuration, zope.interface).
-1
Uhh. -1 for what? -1 for pondering *something*? The note I took was a request for thinking about something. No *I'm* confused about stop energy. Also: we probably should move actual discussions out of the summary thread. ;) Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Excellent, I hope it's a regular feature. The summary should probably go on some blog that will be picked up by planetzope.org/planet.zope.org, too.
On Tue, Mar 02, 2010 at 10:15:07AM -0800, Simon Michael wrote:
Excellent, I hope it's a regular feature. The summary should probably go on some blog that will be picked up by planetzope.org/planet.zope.org, too.
+1 Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
On 03/03/2010 09:01 AM, Marius Gedminas wrote:
On Tue, Mar 02, 2010 at 10:15:07AM -0800, Simon Michael wrote:
Excellent, I hope it's a regular feature. The summary should probably go on some blog that will be picked up by planetzope.org/planet.zope.org, too.
Good idea - so: where's some blog? :) -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
On Wed, Mar 03, 2010 at 09:11:41AM +0100, Christian Theune wrote:
On 03/03/2010 09:01 AM, Marius Gedminas wrote:
On Tue, Mar 02, 2010 at 10:15:07AM -0800, Simon Michael wrote:
Excellent, I hope it's a regular feature. The summary should probably go on some blog that will be picked up by planetzope.org/planet.zope.org, too.
Good idea - so: where's some blog? :)
I can try. Watch this space: http://mg.pov.lt/blog Marius Gedminas -- http://pov.lt/ -- Zope 3 consulting and development
I forgot about this meeting, of course. Will try to do the next one again. Something I want to discuss is what we do with the proposed API changes (unless something was done, and I missed it) and Python 3 compatibility. -- Lennart Regebro: http://regebro.wordpress.com/ Python 3 Porting: http://python-incompatibility.googlecode.com/ +33 661 58 14 64
Thanks for the summary!
The current state of nightly builds is a bit untidy. According to http://docs.zope.org/zopetoolkit/process/buildbots.html there's four buildbot installations with various scopes. The last two in this listing are currently non-functional.
The third one is online again http://zope3.afpy.org/buildbot/ Christophe Christian Theune a écrit :
Hi,
here's my first shot at a summary of today's meeting. I found the meeting itself very positive and energetic - thanks again to everyone who joined.
If anyone knows another good place to announce this summary (we should be more visible to the outside world!), please feel free to post them (or link to them) somewhere and maybe tell me for the future.
Cheers, Christian
------------------------------------------------------------------------
_______________________________________________ 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 )
On Tue, Mar 2, 2010 at 17:32, Christian Theune <ct@gocept.com> wrote:
here's my first shot at a summary of today's meeting. I found the meeting itself very positive and energetic - thanks again to everyone who joined.
The current state of nightly builds is a bit untidy. According to http://docs.zope.org/zopetoolkit/process/buildbots.html there's four buildbot installations with various scopes. The last two in this listing are currently non-functional.
The new URL is : http://bluebream.buildbot.securactive.org/ Other buildbots : http://grok.buildbot.securactive.org/ http://bfg.buildbot.securactive.org/ http://misc.buildbot.securactive.org/
Get a volunteer who will oversee our buildbot installations. The job description would mainly include coordination efforts: ensuring consistent configuration, visibility, reporting and helping people to get nightly builds or contribute builders. mgedmin is pondering until next week whether he volunteers.
Funny, it's the same thing each year (read the Message-ID: <20090616060020.GC9437@elzar.ws.whq.gocept.com> for a example), developers are not affected by the buildbot state and when I (or other) send a mail about failures, the response is : don't spam the mailing list. BTW I'm a volunteer.
We need to put down a list of projects (Zope 2, grok, BB, ZTK, ...), branches and platforms (64-bit!) which we want the nightly builds to be executed on/for. Alan Runyan offered supporting Windows builds. No action/responsibility was agreed upon for this.
I have Linux (32 & 64 bits) Buildbots for all Zope3 projects (grok, bfg, ztk, bb)
Christian Theune volunteered to consisely document instructions for how to run the ZTK tests.
Cool :) Baiju : Do you want another Buildbots? (za = zopeproject, com = community, ztk = Zope TollKit, bb = BlueBream). -- Sebastien Douche <sdouche@gmail.com> Twitter: http://bit.ly/afkrK (agile, python, open source)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sebastien Douche wrote:
On Tue, Mar 2, 2010 at 17:32, Christian Theune <ct@gocept.com> wrote:
here's my first shot at a summary of today's meeting. I found the meeting itself very positive and energetic - thanks again to everyone who joined.
The current state of nightly builds is a bit untidy. According to http://docs.zope.org/zopetoolkit/process/buildbots.html there's four buildbot installations with various scopes. The last two in this listing are currently non-functional.
The new URL is : http://bluebream.buildbot.securactive.org/
Other buildbots : http://grok.buildbot.securactive.org/ http://bfg.buildbot.securactive.org/ http://misc.buildbot.securactive.org/
Get a volunteer who will oversee our buildbot installations. The job description would mainly include coordination efforts: ensuring consistent configuration, visibility, reporting and helping people to get nightly builds or contribute builders. mgedmin is pondering until next week whether he volunteers.
Funny, it's the same thing each year (read the Message-ID: <20090616060020.GC9437@elzar.ws.whq.gocept.com> for a example), developers are not affected by the buildbot state and when I (or other) send a mail about failures, the response is : don't spam the mailing list.
Anybody who complains about legitimate failure reports making it to this list is dead wrong. I think having "sparse" errror messages to this list would be fine (once when a given build failed the first time, another when it built successfully), but others find that too noisy. To that end, We have asked that the run-every-day reports go to a separate list[1], which aggregates them and sends a summary to this list every day. Stefan Holek runs his Zope2 tests and sends the results there. The convention is that the Subject: header for the message starts with 'OK', 'FAILURE', or 'UNKNOWN' (a checkout or build failure), and names the "configuration" being tested. [1] https://mail.zope.org/mailman/listinfo/zope-tests
BTW I'm a volunteer.
Thank you very much for your efforts! 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 iEYEARECAAYFAkuQKosACgkQ+gerLs4ltQ78OQCggIOrjZeh02yv2rNzUqfkEn7E 4PkAn0FRLKpC6XliU9+HWr9ydgxi+ifg =kNiv -----END PGP SIGNATURE-----
Hi Sebastien, On Fri, Mar 5, 2010 at 1:47 AM, Sebastien Douche <sdouche@gmail.com> wrote:
The current state of nightly builds is a bit untidy. According to http://docs.zope.org/zopetoolkit/process/buildbots.html there's four buildbot installations with various scopes. The last two in this listing are currently non-functional.
The new URL is : http://bluebream.buildbot.securactive.org/
Thanks for setting up Buildbot for BB. Can you please co-ordinate with Christophe Combelles, he already setup a Buildbot for BB: http://zope3.afpy.org/buildbot/waterfall (I have CC'ed him here)
Baiju : Do you want another Buildbots? (za = zopeproject, com = community, ztk = Zope TollKit, bb = BlueBream).
A single build master as you organized looks good. Do we need multiple masters located at different servers ? What I really needed is more slaves. We need to find volunteers to provide Windows slaves (both 32bit & 64bit) Regards, Baiju M
Hi, On 03/05/2010 02:56 AM, Baiju M wrote:
Hi Sebastien,
On Fri, Mar 5, 2010 at 1:47 AM, Sebastien Douche <sdouche@gmail.com> wrote:
The current state of nightly builds is a bit untidy. According to http://docs.zope.org/zopetoolkit/process/buildbots.html there's four buildbot installations with various scopes. The last two in this listing are currently non-functional.
The new URL is : http://bluebream.buildbot.securactive.org/
Thanks for setting up Buildbot for BB. Can you please co-ordinate with Christophe Combelles, he already setup a Buildbot for BB: http://zope3.afpy.org/buildbot/waterfall (I have CC'ed him here)
Baiju : Do you want another Buildbots? (za = zopeproject, com = community, ztk = Zope TollKit, bb = BlueBream).
A single build master as you organized looks good.
Do we need multiple masters located at different servers ? What I really needed is more slaves. We need to find volunteers to provide Windows slaves (both 32bit & 64bit)
I'm currently making the ZTK documentation a point where all the efforts at least get listed so we see who takes care of what. I'm not pressing a single master so we get better coverage because more people can directly influence their setups. For now that probably makes the best out of that energy. :) With the overview you should be able to talk to the maintainers of those buildbots and ask them whether they can help you. Enfold seems to be happy to provide Windows environments generally. I also noticed that the health agency runs Windows tests. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi, On 03/04/2010 09:17 PM, Sebastien Douche wrote:
On Tue, Mar 2, 2010 at 17:32, Christian Theune <ct@gocept.com> wrote:
here's my first shot at a summary of today's meeting. I found the meeting itself very positive and energetic - thanks again to everyone who joined.
The current state of nightly builds is a bit untidy. According to http://docs.zope.org/zopetoolkit/process/buildbots.html there's four buildbot installations with various scopes. The last two in this listing are currently non-functional.
The new URL is : http://bluebream.buildbot.securactive.org/
Other buildbots : http://grok.buildbot.securactive.org/ http://bfg.buildbot.securactive.org/ http://misc.buildbot.securactive.org/
Thanks. I will list those in the ZTK documentation.
Get a volunteer who will oversee our buildbot installations. The job description would mainly include coordination efforts: ensuring consistent configuration, visibility, reporting and helping people to get nightly builds or contribute builders. mgedmin is pondering until next week whether he volunteers.
Funny, it's the same thing each year (read the Message-ID: <20090616060020.GC9437@elzar.ws.whq.gocept.com> for a example), developers are not affected by the buildbot state and when I (or other) send a mail about failures, the response is : don't spam the mailing list.
Actually, there's a specific aggregation thing (who's running this again?) that can accept the individual buildbot messages and creates a daily message. I think that actually works quite well. I think all the various buildbots should send their messages to this aggregator.
BTW I'm a volunteer.
Great!
We need to put down a list of projects (Zope 2, grok, BB, ZTK, ...), branches and platforms (64-bit!) which we want the nightly builds to be executed on/for. Alan Runyan offered supporting Windows builds. No action/responsibility was agreed upon for this.
I have Linux (32 & 64 bits) Buildbots for all Zope3 projects (grok, bfg, ztk, bb)
Cool. I'm also expanding the documentation of what is tested where and who's the contact for the individual buildbots. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1 Zope and Plone consulting and development
participants (14)
-
Baiju M -
Brian Sutherland -
Chris McDonough -
Christian Theune -
Christophe Combelles -
Fred Drake -
Hermann Himmelbauer -
Jim Fulton -
Lennart Regebro -
Marius Gedminas -
Martijn Faassen -
Sebastien Douche -
Simon Michael -
Tres Seaver