Re: [Zope-dev] Zope 4 release management

2012-02-06 Thread Martijn Faassen

On 11/17/2011 07:01 PM, Martin Aspeli wrote:


I would actually argue that Zope4 have no real release cycle at all:
instead, the individual pieces which make up Zope should have their own
cycles, with perhaps a ZTK-like tracking set that Plone and others use as
platform targets.


-1 - we'll need something to amalgamate this into a release and we'll
need a way to manage and number those releases.


I agree; actually ZTK-like tracking set is really already talking 
about doing releases, just like the ZTK has releases. And just like ZTK 
releases do, this needs some release management effort.


Now I would advocate that Zope 4 releases mimic the ZTK in the way 
things are managed.


Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists -
https://mail.zope.org/mailman/listinfo/zope-announce
https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] congrats on the new zope.org launch, but..

2011-07-15 Thread Martijn Faassen
Hey,

On 07/11/2011 06:09 PM, Andreas Jung wrote:

 According to zope.org Gork is more like ZPT than it is
 like BlueBream. Griok is more like CMF than it is like BlueBream. This
 is because Grok is listed under the grab-bag framework category.

 I partly agree with you - I think Grok can be considered both as an
 application server and as a framework. I would not object to move Grok
 to the app server section if you want it.

+1

 The problem is more that
 grab-bag framework. The ZCA is to be honest not a framework but a
 concept and ZPT is a part of the ZTK and all other frameworks.

Yeah, it's a grab bag item, I already mentioned that previously, but I 
still think Grok should be in the same category with BlueBream.

We can look up my previous post to see what I suggested about the 
framework category there; I did offer some suggestions there.

 I also mention that 'Application Servers' may not be the best heading
 for the category which could contain Zope and BlueBream and Grok. Zope's
 an application server, the other two are called web framework

 I won't start a new philosophical discussion about differences between
 application servers and web-frameworks - any better naming suggestion
 for a category holding Zope, Bluebream and Grok?

I'd just call the category web framework; 2 out of 3 already say they 
are. Zope can then itself say in its description that it's an 
application server if that's an important term. It's still a compromise 
but I think it's better to compromise towards web framework which is 
the more recognizable term.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] congrats on the new zope.org launch, but..

2011-07-15 Thread Martijn Faassen
On 07/15/2011 03:13 PM, Hanno Schlichting wrote:
 On Fri, Jul 15, 2011 at 1:50 PM, Martijn Faassenfaas...@startifact.com  
 wrote:
 I'd just call the category web framework; 2 out of 3 already say they
 are. Zope can then itself say in its description that it's an
 application server if that's an important term.

 At least zope2.zope.org uses the web framework term to describe Zope
 2 as well. application server doesn't describe todays Zope 2
 codebase and aim anymore either.

 So I'd rather place all of the big guys in the web framework box.

+1

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] congrats on the new zope.org launch, but..

2011-07-08 Thread Martijn Faassen
Hi there,

Congrats on the relaunch of zope.org, I know it's been a hard slog!

But I brought up an item twice already and nothing appears to have been
done about it. According to zope.org Gork is more like ZPT than it is
like BlueBream. Griok is more like CMF than it is like BlueBream. This
is because Grok is listed under the grab-bag framework category.

I also mention that 'Application Servers' may not be the best heading
for the category which could contain Zope and BlueBream and Grok. Zope's
an application server, the other two are called web framework

I really think it's obvious that this is wrong, so, please fix, thanks.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] direction

2011-07-06 Thread Martijn Faassen
On 07/05/2011 12:22 PM, Jonas Meurer wrote:

 Since we don't market Zope2 anymore, I think there's actually much
 less confusion from this than we'd fear. It's just an internal version
 number used in some buildout files, not something that has any
 particular meaning.

 I don't like either of these solutions. And I don't agree with Hanno,
 that it's 'just an internal version number'. It will show up on
 zope.org, launchpad.net, and many more places.

 I would rather bump the version number to 2.20 to highlight the major
 changes, and keep the 2 as major for Zope2 versions.

I agree calling it Zope 2 version 3 would be very confusing. There's a 
lot of Zope 3 google juice around that would get muddled up even more.

Concerning not marketing Zope 2, heh, Zope and marketing strategies? I 
thought we were going to call Zope 2, Zope now, so people will 
obviously be curious about this Zope thing... Never make any assumptions 
about a coherent Zope marketing strategy! I'll also drop in a reference 
to the existence of zope2.zope.org.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] beta.zope.org (www.zope.org relaunch project)

2011-05-10 Thread Martijn Faassen
Hi there,

On 05/10/2011 06:55 AM, Andreas Jung wrote:

 Constructive criticism and feedback is welcome _now_.

Application servers has Zope  BlueBream.

Then Grok's at the bottom under 'Frameworks' together with CMF, Repoze, 
ZCA, ZTK and ZPT.

Grok is most like BlueBream and should be in a category with BlueBream. 
If Grok's a framework so's BlueBream.

I'd call 'Application servers', which is mostly a term from Java land, 
web frameworks instead, because that's what Python developers will 
understand, and put Zope, BlueBream and Grok under it. If it sorts 
alphabetically (frameworks seems to do so) and Grok comes first, I don't 
mind. :)

Just think about whether Zope stuff is more like this:

http://en.wikipedia.org/wiki/Application_server

or more like this:

http://en.wikipedia.org/wiki/Web_framework

The Frameworks entry seems like a total grab bag to me (I didn't know 
where to put this), which is why I wouldn't want Grok presented that 
way. But you'd need to split up 'Frameworks' really.

ZCA and ZPT can be successfully presented as libraries (framework-style 
libraries perhaps, but they're just libraries you can install and use), 
and ZTK is a collection of libraries (which in fact contains the former 
two libraries).

I'd say make a new heading:

Zope Toolkit

Put under it:

* ZCA

* ZPT

* other Zope toolkit libraries

So we're highlighting two important libraries and say we have a lot 
more, managed within the ZTK.

You can put CMF and Repoze under Frameworks if you wish.

But a question: do we really want to present CMF as a current framework 
that people can use to start projects on? If not, and it's legacy only, 
should we really present it as an entry point? I'm not sure where Repoze 
would go in all this though.

Regards,

Martijn


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] beta.zope.org (www.zope.org relaunch project)

2011-05-10 Thread Martijn Faassen
Hi there,

http://beta.zope.org/the-world-of-zope

dekade - decade:

And just talk about 'Zope community has grown' instead of starting with 
Zope Corp. and the Zope community, which I think gives the impression 
the community is some kind of appendage to Zope corp, the driving force 
behind it all. While this was true 10 years ago, it isn't today. And 
Zope corp is a part of the Zope community, right? And we're not talking 
about Zope corp specific products either, so that could lead to 
confusion the other way: somebody might call Zope corp about Plone.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Test fixture concepts

2011-04-20 Thread Martijn Faassen
On 03/27/2011 05:13 PM, Martin Aspeli wrote:
 On 27 March 2011 15:54, Uli Fouquetu...@gnufix.de  wrote:

 The (limited) experiences with py.test, however, were awesome. Some
 points that are quite cool IMHO:

 - Easy finding of tests: just write some ``test_function`` in a
   ``test_module`` and it will be found and executed. That also makes
   py.test tests more readable and maybe more intuitive.

 I'm not sure this is always a good idea. It feels a bit implicit, and
 having a base class isn't really a big problem, IMHO. It seems a bit
 like the kind of thing that sounds cool (look, it's even easier!), but
 in practice makes little difference.

Belatedly adding my few cents here: in practice I quite enjoy not having 
to copy ugly boilerplate from test modules that I always always forget.

It's actually nice to just write a test_* function and have the test 
runner just work.

So it's cool for some people, namely me.

Regards,

Martijn


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Test fixture concepts

2011-04-20 Thread Martijn Faassen
On 03/29/2011 02:43 PM, Wichert Akkerman wrote:
 On 3/29/11 14:40 , Stephan Richter wrote:

 Yeah, Marius led me recently to that path too. Write a narrative in text 
 files
 and use doc strings of functions to do edge cases (or when you don't have 
 time
 for the narrative). I am getting used to it. I still much prefer the sort of
 output comparison that doctests/manuel gives me over the assertion language
 that unittest.TestCase requires.

 FWIW unittest2 has much nicer output if you use the new assert methods.

py.test has very nice output if you use the Python 'assert' statement. 
There are no assert methods to remember.

Regards,

Martijn



___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] fanstatic and preprocessors

2011-04-17 Thread Martijn Faassen
Hey,

[snip Wolfgang]

 [1] 
 http://www.rubyinside.com/rails-3-1-adopts-coffeescript-jquery-sass-and-controversy-4669.html
 [2] https://github.com/sstephenson/sprockets

Thanks for these links! We should investigate Sprockets to see what 
other features it has, and perhaps in the future collaborate with them 
on a packaging format.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope test layers, pytest, and test isolation

2011-03-24 Thread Martijn Faassen
Hi there,

[extensive introduction by Uli of zope.pytest]

Thanks Uli for that introduction to the package and its problems!

I've been using zope.pytest within 2 Grok projects so far to test 
through webob some JSON webservices, and it's worked well for me. I 
hadn't had to deal with the issue of multiple configurations in those 
tests though, as they're basically functional/integration tests.

I've also been happily using plain py.test in several other non-Zope 
projects, and I must say it has many nice features that make life 
easier, and makes a lot of test cruft go away.

I'm particularly hoping that Wolfgang Schnerring will give feedback: I'm 
curious how his investigations on improving the layer story might also 
benefit py.test integration.

Regards,

Martijn

P.S.

Uli did a lot of work himself to make this package and help document it, 
by the way, he's doing himself injustice in his introduction. :)

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)

2011-03-22 Thread Martijn Faassen
Hi there,

It is my understanding that the ZTK is primarily to adopt proven 
solutions that arise from our community that we intend to be shared by 
this community. I'll also note that Martian is already in use in 
combination with Bluebream, Zope 2 and Grok.

With that, I was thinking, concerning alternative configuration 
mechanisms I think we should have:

* a clear statement of use cases concerning configuration.

* a weighing of the importance of these use cases, underlying reasons, etc.

* an evaluation whether Martian or Venusian can fulfill those use cases.

* if use cases are found that Martian or Venusian cannot fulfill, then 
an evaluation whether these can be made to fulfill them by modifying them.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)

2011-03-21 Thread Martijn Faassen
Hi there,

For Martian, Python 3 support is mostly an issue of making class 
directives work as class decorators.

I'm not sure what Lennart means by point 1.

Anyway, Grok's configuration is dependent on the rules you give it, so 
it's possible to have a completely explicit set of directives with no 
implicit fallback to default values whatsoever. Martian supports that 
scenario right now.

The only implicit behavior left would be the grokking process, which 
generally recognizes subclasses of particular base classes as something 
to register. You could do away with this using class decorators as well, 
but that would require some changes to Martian to allow it to recognize 
things that way. (and it won't work for grokking instances, just classes 
and functions)

Note that Pyramid as far as I understand also has a non-ZCML 
configuration method that is closer to ZCML.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?

2011-03-21 Thread Martijn Faassen
On 03/19/2011 10:02 PM, Lennart Regebro wrote:
 Getting ZCA/ZTK to run on PyPy is probably easier, and actually more
 useful. Maybe someone would want to mentor that?

I agree it'd be easier and more useful. There's also interesting 
potential in exploiting PyPy's magic in things like security and ZODB 
persistence.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?

2011-03-21 Thread Martijn Faassen
On 03/20/2011 02:31 PM, Jim Fulton wrote:
 On Sat, Mar 19, 2011 at 5:02 PM, Lennart Regebrorege...@gmail.com  wrote:
 Getting ZCA/ZTK to run on PyPy is probably easier, and actually more
 useful. Maybe someone would want to mentor that?

 This is another porting project.  If I was a student, I wouldn't find it very
 interesting to port some code I hadn't written and probably don't
 understand from
 one platform to another.  (My earlier comment on py2k-py3k porting wasn't 
 meant
 as a dig against py3k bit rather to say that I didn't think porting
 projects would
 be very interesting.)

That's true, we had bad experience with the Jython project a few years 
ago. It depends on the students though; I think we had better experience 
with a project to move Zope 2 forward to a newer version of Python 2.x 
(if I recall that correctly).

But writing new code is a lot more fun. But if you're going to do 
porting, PyPy is a lot more tempting as a target for me.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?

2011-03-21 Thread Martijn Faassen
Hi,

On 03/20/2011 03:28 PM, Jim Fulton wrote:

 Hm, it's been a while since I've looked at grok. Some notes:

We have more than four years of experience with this topic...

 - The mechanism I'm thinking of should not require *any* ZCML.

Check. we just bootstrap the grokking process from ZCML right now. We 
use zope.configuration actions to be compatible with ZCML.

 - The mechanism shouldn't require something to grok/analyze the
code.  The mechanism should be explicit. This is implied by
pythonic.  I remember Grok being more implicit than skimming the
links above suggest. Perhaps Grok has has become more explicit than
I remember.

The basic principles are still the same. We still import code and grok 
those classes/instances/functions we want to do something with.

Now that we have class decorators we could come up with another 
collection mechanism however. That said, you'd still need to import the 
modules at some point, otherwise collection will not take place as the 
decorators don't get executed in the first place.

Martian has been expanded a lot though. I recommend looking at Martian.

 - I'd prefer not to rely on subclassing, but I'm not dead set against it.

Class decorators might work. Subclassing does have some nice properties 
though; it feels Python and it becomes easy to come up with your own 
domain specific base classes. But it's not a major gain over class 
decorators I imagine.

Note that if you do directives on classes at all, you're going to have 
to think about how subclassing interacts with configuration. 
'implements' is a good example of that.

 - Whataever we come up with has to work with Python 3, so
unfortunately, we can't use the syntactic trick of having a call in a
class like::

  grokcore.component.implements(IContentProvider)

 The effort should certainly include an analysis of approaches like
 grok.  Maybe the mechanism should have the effect of enabling tools
 like grok to be implemented more cleanly.

Yeah, a nice project would be to let Grok use class decorators instead 
of old style traceback-exploiting class directives. We have a fairly 
well defined directive mechanism which knows about inheritance. It even 
knows about module-level directives that affect all classes in the 
module and then those classes have subclasses.

 Note that the move from advice-based syntax to class decorators
 provides a good opportunity to revisit how some of this works based
 on experience using the ztk.

I'm not sure how the behavior would be affected based on experience. For 
'implements' for example, we still want subclassing behavior, don't we, 
decorator or not.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?

2011-03-21 Thread Martijn Faassen
On 03/21/2011 10:17 AM, Jan-Wijbrand Kolman wrote:

 - scanning can take a long time, making application (re)start slow for
  non-trivial projects

 At what point is an application not trivial anymore? In applications I
 build so far, startup time has not been an issue at all. But maybe my
 applications are still on the trivial-end of the spectrum ;)

In general we haven't really gotten much feedback about this being a 
performance issue, as far as I know. The modules need to be imported at 
some point anyway so we don't really add much overhead there, and 
otherwise it's just going through the module's attributes, which I 
imagine comes down to looping through a dictionary really and doing a 
lot of isinstance and issubclass calls. That's going to be pretty fast. 
It might even be faster than ZCML XML parsing, it's hard to say. :)

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?

2011-03-21 Thread Martijn Faassen
On 03/20/2011 04:29 PM, Jim Fulton wrote:
 On Sun, Mar 20, 2011 at 11:00 AM, Hanno Schlichtingha...@hannosch.eu  wrote:
[snip]
 I think you cannot avoid this, if you want to support an explicit
 configuration phase. Otherwise the first import of a module could
 occur at any point at runtime and have a configuration side-effect
 like registering a new view. Personally I find the venusian approach
 pretty simple and explicit enough.

 I disagree.  First, the notion that you'd import at run time is pretty odd,
 unless you count start-up in runtime.

You might have a module that you don't import at all, but does define 
components you want to be wired up. How is this module going to be 
registered? You could import it after all in some module you *know* is 
going to be imported (which one?). It seems rather easy to make a 
mistake here and wonder why things don't get configured. Plus you're 
importing stuff that you then don't use.

 Second, well, really, I'm not ready to give up on a straightforward
 definition of wiring that doesn't rely on module scanning.

You could do the wiring using class decorator side effects, but the 
module will still need to be touched to get the decorators to kick in.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?

2011-03-21 Thread Martijn Faassen
Hi there,

On 03/20/2011 04:00 PM, Hanno Schlichting wrote:

 Taking one of the examples of grokcore.component, I think there's a
 lot that can be made simpler:

 import grokcore.component
 from zope.i18n.interfaces import ITranslationDomain

 class HelloWorldTranslationDomain(grokcore.component.GlobalUtility):
  grokcore.component.implements(ITranslationDomain)
  grokcore.component.name('helloworld')

 Based on my Pyramid exposure, I'd write this as something like:

 from something import utility
 from zope.i18n.interfaces import ITranslationDomain

 @utility(ITranslationDomain, name='helloworld')
 class HelloWorldTranslationDomain(object):
  pass

It's interesting to consider inheritance rules here. What if you 
subclass from HelloWorldTranslationDomain? What happens to name and the 
interface that the utility is provided under?

I'm not saying I know the right rules for inheritance in all cases, or 
that grokcore.component is sane here, but I know in some cases having 
directive values inherit is pretty neat, and in some cases it isn't. I 
imagine registration can always be explicit, however.

Note also that if we're simply talking spelling, this makes grok a bit 
shorter and is the way Grok code typically looks:

import grokcore.component as grok

from zope.i18n.interfaces import ITranslationDomain

class HelloWorldTranslationDomain(grok.GlobalUtility):
  grok.implements(ITranslationDomain)
  grok.name('helloworld')

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Anyone want to do Google Summer of code mentoring for PSF?

2011-03-21 Thread Martijn Faassen
Hi there,

On 03/20/2011 05:47 PM, Hanno Schlichting wrote:

 Maybe there's something in Grok that comes close to this. I've just
 not been able to distinguish the Grok the web framework code with
 its convention over configuration idea from some basic explicit
 configuration approach.

I don't understand. Venusian took its ideas from Martian, and Martian's 
not a web framework and never has been.

http://pypi.python.org/pypi/martian

Surely you've heard of this library before?

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)

2011-03-21 Thread Martijn Faassen
On 03/21/2011 03:07 PM, Lennart Regebro wrote:
 On Mon, Mar 21, 2011 at 14:17, Martijn Faassenfaas...@startifact.com  wrote:
 Anyway, Grok's configuration is dependent on the rules you give it, so
 it's possible to have a completely explicit set of directives with no
 implicit fallback to default values whatsoever. Martian supports that
 scenario right now.

 Sure, but I'm of course referring to how it behaves by default,
 including the associations made by the grokking process.
 I think that makes sense in a webapp, but not otherwise, and we should
 at least as a start concentrate on the generic component architecture
 case.

 For Martian, Python 3 support is mostly an issue of making class
 directives work as class decorators.

 And the same goes for zope.component support, of course.

We have a much more extensive directive abstraction though. That should 
make it harder and easier at the same time. :)

  With martian, the registration is then done by the grokking process,
  but I think decorators would be a process that is more acceptable to
  the Python world in general. Instances does indeed require something
  else than decorators, I hadn't thought of that, that's a drawback.

Do we really care about the Python world in general? Is that relevant 
to the discussion? Can't we just talk about what we care about? The 
Python world in general uses metaclasses for this kind of stuff, which 
relies on base classes too, by the way.

You'll still need a module importing process, as I sketched out 
elsewhere, if you use class decorators, to have the class decorators 
kick in at all for modules you don't need to import otherwise. Note that 
we do support function decorators with Martian.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)

2011-03-21 Thread Martijn Faassen
On 03/21/2011 03:28 PM, Jim Fulton wrote:
 I don't know what the right answer is ... at least not yet. :)

In Django and sqlalchemy declarative a meta class is used for this kind 
of configuration. Since that is subclassing, it implies inheritance, I 
think.

Of course metaclasses are not very good for this as they're surprising 
in other ways and use unstructured configuration happening at import time.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Non-ZCML config for ZCA. (Was: Anyone want to do Google Summer of code mentoring for PSF?)

2011-03-21 Thread Martijn Faassen
On 03/21/2011 04:08 PM, Jim Fulton wrote:
 On Mon, Mar 21, 2011 at 10:38 AM, Martijn Faassen
 faas...@startifact.com  wrote:
 On 03/21/2011 03:28 PM, Jim Fulton wrote:
 I don't know what the right answer is ... at least not yet. :)

 In Django and sqlalchemy declarative a meta class is used for this kind
 of configuration. Since that is subclassing, it implies inheritance, I
 think.

 Ick.

 Of course metaclasses are not very good for this as they're surprising
 in other ways

 Agreed.

Martian allows you to use a similar spelling to metaclasses (base 
classes), without the weird surprises during run-time (after 
configuration is already done), and without significant import-time 
side-effects.

With megrok.rdb I actually use SQLAlchemy declarative without their 
declarative metaclass, as the SQLAlchemy folks were kind enough to tweak 
their config code so I could call it directly from a grokker.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] PyPy 1.4.1 and the ZTK

2010-12-23 Thread Martijn Faassen
Hi there,

On 12/22/2010 09:56 PM, Chris McDonough wrote:

 FWIW, for our web stuff I've found PyPy to be about 3X as slow as
 CPython (even allowing for the JIT to warm up).  But the elephant
 dances!

Any clue what's taking up the time? Do you think it's simply that it 
doesn't speed up zope.interface to the level of the C version?

I vaguely recall something about PyPy's JIT not being good with 
interpreter-style patterns in code - so that might slow down things if 
templating is involved.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] PyPy 1.4.1 and the ZTK

2010-12-22 Thread Martijn Faassen
Hi there,

I thought it'd be interesting to note that PyPy 1.4.1 (with JIT) now 
works out of the box with buildout (at least if I use the '-d' option 
for distribute with bootstrap.py, but I suspect plain setuptools also 
works). I actually added a few compatibility fixes to buildout the other 
day that are now unnecessary: PyPy 1.4.1 adds the compatibility with 
released versions of buildout out of the box.

This makes it possible to start testing some of the ZTK with PyPy. There 
are challenges of course: certain packages, such as zope.interface, use 
C extensions and would need to be installed in plain-python mode (if 
available). The ZODB would definitely be an interesting challenge too.

One snag is that PyPy is only compatible up to Python 2.5. This might 
make some of the code fail. Then again, if it's the 'with' statement the 
fix is an from __future__ import with_statement away.

A release of PyPy with Python 2.7 support is still a while away, but 
being worked on.

The benefit of using PyPy? It has a JIT on board, so that should speed 
up some code significantly. Whether it'll speed up some of our tests is 
hard to say though - the JIT might be more overhead than gain in that case.

Regards,

Martijn


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope Toolkit 1.0 release

2010-10-15 Thread Martijn Faassen
On 10/13/2010 05:57 PM, Jan-Wijbrand Kolman wrote:
 On behalf of the Zope Toolkit release team and the Zope community, I'm
 happy to announce the release of Zope Toolkit version 1.0!

Congrats to the ZTK release team!

Regards,

Martijn


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] lxml dependency in Zope 2.12.10 KGS

2010-09-10 Thread Martijn Faassen
Hi there,

On 09/10/2010 03:04 PM, Hanno Schlichting wrote:
 This is unfortunate, but really a problem for the lxml community and
 not us. So the lxml community cannot keep up with providing binary
 Windows eggs.  This cannot force us to stick with old and buggy
 versions of the software.

I might make sense to just email Sidnei. He's been responsible for the 
lxml windows eggs for years, and he's been doing some Zope egg work too.

I.e. if you have a problem with lxml, it might make sense to just talk 
with the lxml people...

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] docs.zope.org automation

2010-08-02 Thread Martijn Faassen
On 07/31/2010 07:22 PM, Jens Vagelpohl wrote:

 Here's a followup on a docs.zope.org automation task I took over during
 one of the Zope developer IRC metings[1]. The task was to provide
 individual package documentation, if it exists, directly underneath
 docs.zope.org, e.g.:

 http://docs.zope.org/zope.event/

Really cool!

Wouldn't it be good to put this under /package/zope.event to avoid 
potential naming conflicts? I realize they're rare, but I can imagine 
that a project foo could exist that wants to expose its documentation 
separately from project foo. Perhaps Zope would be a good example. :)

Regards,

Martijn

P.S. It'd be good if the ZODB section had at least a link to zodb.org. 
Links to buildout.org and grok.zope.org might also be useful.

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] docs.zope.org automation

2010-08-02 Thread Martijn Faassen
On 08/02/2010 05:25 PM, Jens Vagelpohl wrote:
 python setup.py --long-description

 Can someone tell me how to do that when I am in Python code already?
 Given the path to the checkout, can I use some setuptools/pkg_resources
 or pkginfo magic to get at this data?

Oh, this is where I always get scared because I always get lost. :)

The pkg_resources documentation is here:

http://packages.python.org/distribute/pkg_resources.html

You can probably create a Distribution object somehow (handwave) from a 
path (whether that's the path of the package or the path the package is 
in, not sure).

Then maybe 'get_metadata('long_description') on the distribution object, 
but maybe not as one seems to have to supply metadata when constructing 
a distribution..

But again, I always get lost here, perhaps you need an Environment or a 
WorkingSet first, etc.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] docs.zope.org automation

2010-08-02 Thread Martijn Faassen
On 08/02/2010 06:34 PM, Jens Vagelpohl wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 8/2/10 18:26 , Martijn Faassen wrote:
 http://packages.python.org/distribute/pkg_resources.html

 You can probably create a Distribution object somehow (handwave) from a
 path (whether that's the path of the package or the path the package is
 in, not sure).

 The issue, just like with pkginfo.Develop, is that I can't find any
 function or method that finds package information in subfolders. If you
 look at...

 http://packages.python.org/distribute/pkg_resources.html#getting-or-creating-distributions

 ...there's this function find_distributions which supposedly offers
 subfolder searching, but it just doesn't work. At least it doesn't do
 what I would expect when I read the documentation. It finds nothing.

Yeah, unfortunately this is generally the point where I find myself 
being lost too.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Can ZTK 1.0 support Python 2.7?

2010-07-13 Thread Martijn Faassen
On 07/13/2010 02:12 PM, Hanno Schlichting wrote:
 Given all of these, I'm leaning towards not supporting Python 2.7 for
 a ZTK 1.0 release. A 1.1 can drop Python 2.4 support and we can try to
 support 2.7 in addition.

+1

For Zope standards we'd still be very fast with supporting Python 2.7 if 
we do this (assuming 1.1 will be out before, say, 2012 :).

Regards,

Martijn


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.traversing's ILocation behavior

2010-07-09 Thread Martijn Faassen
Hey,

[zope.traversing absolute URL behavior]

I've applied the fix to zope.traversing and added a test as well. It's 
released as zope.traversing. I've also updated the ZTK to use this version.

(initially I used checkversions to update a few other packages too, 
namely zope.dublincore, zope.index, zope.pagetemplate and zope.testing, 
but this *did* result in zopeapp breakages, so I reverted that quickly. 
Someone needs to look into this to see what can be upgraded and what 
causes the break later)

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Including Paste into the ZTK version list?

2010-07-09 Thread Martijn Faassen
On 07/09/2010 04:50 PM, Hanno Schlichting wrote:
 I noticed that all three frameworks (BB, Grok, Zope2) have version
 pins for Paste, PasteDeploy and PasteScript. Does anyone object to
 including them into the ztk-versions.cfg under dependencies?

No objections from Grok.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] buildout 1.5 sometime ever please?

2010-07-08 Thread Martijn Faassen
Hi there,

I've been waiting for years for a release of buildout that contains 
proper isolation from Python's site-packages. The non-isolation is a 
major flaw in buildout that makes it SO much harder to write proper 
installation instructions for software such as Grok.

We need to wrap Grok's buildout installation using virtualenv 
--no-site-packages. I just discovered that this installation actually 
fails if I use an ubuntu-installed virtualenv (or setuptools)! It works 
with a manually installed version of either, and I'm sure the problem is 
somewhere in z3c.autoinclude too, but it's still an issue.

Last year in september I hacked up some code that would do the 
isolation. I was then informed that Gary was working on a branch 
instead, and indeed the branch I saw then looked much improved in 
features. So I waited. I saw new versions of the branch come and go and 
I'm not sure what's going on, but I waited.

I noticed that in april there was a beta release of buildout that 
featured such improvements. This release was then withdrawn and 
overridden with 1.50b2 with the message:

This is a re-release of 1.4.3 to hide the brown-bag release of 1.5.0b1. 
The changes in 1.5.0b1 will reappear as 1.5.0 soon, when the additional 
reported problems have been addressed.

It is now july, so I'm starting to get my doubts about the word soon. 
Have the reported problems been addressed? Is there any hope I can get a 
buildout that actually provides proper isolation sometime? Can I help?

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] buildout 1.5 sometime ever please?

2010-07-08 Thread Martijn Faassen
Hi there,

I was told to ask this question on distutils-devel, which I recall is 
the proper list for buildout related discussions. See you there.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Grok 1.1 doesn't send error messages to terminal?

2010-07-08 Thread Martijn Faassen
Hi there,

It appears that Grok 1.1 doesn't send error messages to the terminal by 
default? This is really inconvenient and I wonder what change broke it.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Grok 1.1 doesn't send error messages to terminal?

2010-07-08 Thread Martijn Faassen
On 07/08/2010 03:36 PM, Martijn Faassen wrote:
 Hi there,

 It appears that Grok 1.1 doesn't send error messages to the terminal by
 default? This is really inconvenient and I wonder what change broke it.

Argh, wrong mailing list, sorry.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] zope.traversing's ILocation behavior

2010-07-08 Thread Martijn Faassen
Hi there,

in zope.traversing.browser.absoluteurl there was a change a while back 
that breaks my code, now that I'm upgrading to it.

The code in the absolute URL generation code used to be this:

  container = getattr(context, '__parent__', None)

This simply gets the __parent__ of the context so that it can ask for 
its absolute URL. If no container can be found the answer will be None 
and the system will raise a TypeError, complaining about insufficient 
context.

The code was then changed to this:

 context = ILocation(context, context)
 container = getattr(context, '__parent__', None)

While this code looks initially confusing, what it does is try to adapt 
context to ILocation, but if it fails, falls back to 'context' to look 
up parent, preserving backwards compatibility but adding the feature 
that people can register custom ILocation adapters for models.

But then, in dependency work by Christian Theune, the code got changed 
to this:

 context = ILocation(context)
 container = getattr(context, '__parent__',  None)

In addition, in zope.location an adapter got added for everything 
(Interface) that creates a LocationProxy.

This means that the ILocation adaptation *always* succeeds, and might 
return a location proxy with __parent__ and __name__ set to None.

This rather confused me initially, as this is one of those magic 
transparent proxies (except for __parent__ and __name__!). 'context' has 
a __parent__ *until* the point where ILocation() is called on it, and 
then the proxied context suddenly loses it __parent__!

This broke the behavior of code that relied on __parent__ being checked 
first. I realize that this was depending implicit behavior, as models 
don't *really* provide ILocation. But on the other hand working code is 
broken in a really obscure way.

The fix in my code was to make my model provide ILocation itself, so 
that it would adapt itself and therefore avoid the proxy. I think that 
might be correct but at the same time is really obscure; in my code the 
__parent__ is provided by a completely different subsystem (traject). 
Models that didn't provide ILocation used to work, and now they fail. Do 
we really want to require everybody to start providing ILocation in all 
their models?

I propose the following adjustment:

   try:
  container = context.__parent__
   except AttributeError:
  container = ILocation(context).__parent__

So, try to find the __parent__ the old way first, without adapter 
lookup. If that fails because the attribute is missing, look up the 
adapter. That might get one the proxy again, but at least not when a 
__parent__ is actually available. Still, this deserves some commenting 
for future people trying to debug what's going on.

I've verified that at least in my application this unbreaks the code. 
I'll also try to add a test that demonstrates the expected behaviors so 
that this doesn't get broken again.

Opinions?

Regards,

Martijn

P.S. I want a publisher with location support but without proxy magic. :)

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope summit topics

2010-07-06 Thread Martijn Faassen
On 07/05/2010 08:56 PM, Sidnei da Silva wrote:
 On Mon, Jul 5, 2010 at 3:52 PM, Martijn Faassenfaas...@startifact.com  
 wrote:
 (But hurry.resource is not perfect; I think it'd be better to step out
 of Python land and create a Javascript packaging system somewhat modeled
 on Python's, with easy integration into Python projects. A sprint task?)

 YUI 3's loader comes to mind (as its the one I have most experience with).

I've used YUI 2's loader (and hurry.resource was inspired by it). I 
don't know YUI 3's loader so I should take a look at it. (It strikes me 
that whatever its technical merits, a javascript packaging system will 
have to appear neutral politically and YUI's loader won't do that. The 
YUI 3 loader is connected to the YUI global object?)

Anyway, YUI's loader only solves part of the problem - at least the YUI 
2 loader doesn't feature a packaging system, just a loading system. I 
want the ease of saying: my project depends on YUI version blah and 
having YUI version blah being there, just like I can do for a Python 
package. Such a package should include a dependency map of the included 
resources as well, not just the code.

Regards,

Martijn


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope summit topics

2010-07-06 Thread Martijn Faassen
On 07/05/2010 09:32 PM, Jim Fulton wrote:
 On Mon, Jul 5, 2010 at 2:56 PM, Sidnei da Silva
 sidnei.da.si...@canonical.com  wrote:
 On Mon, Jul 5, 2010 at 3:52 PM, Martijn Faassenfaas...@startifact.com  
 wrote:
 (But hurry.resource is not perfect; I think it'd be better to step out
 of Python land and create a Javascript packaging system somewhat modeled
 on Python's, with easy integration into Python projects. A sprint task?)

 YUI 3's loader comes to mind (as its the one I have most experience with).

 Ditto for dojo. :)

All javascript libraries grow their own packaging systems... I'd be nice 
if they were all compatible with a more neutral version.

Some consolidation would be nice, plus bridging all of that to the 
Python packaging world.

I'd envision a JSON-based metadata system that include intra and inter 
package dependencies between resources, a way to wrap these packages, a 
package host along the lines of PyPI, and integration with the Python 
packaging system. And then wrap all these javascript libraries up and 
upload them to the package index. The wrapping up can be fairly 
straightforward (YUI contains a dependency graph), or need analysis.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Python 2.7 and the ZTK - three test failures

2010-07-06 Thread Martijn Faassen
On 07/06/2010 09:46 AM, Wichert Akkerman wrote:
 On 2010-7-5 23:08, Hanno Schlichting wrote:
 Hi there,

 with Python 2.7 final being released, I ran the ZTK tests against it.

 zope.exceptions, zope.formlib and zope.proxy all have one test output
 related failure.

 We seem to have a lot of problems with doctests breaking due to changes
 in exception formatting. Perhaps a policy to check exceptions using a
 try/except or self.assertRaises instead of relying on exact formatting
 would be useful?

I wish the Python developers saw the exception messages as a core part 
of their interface, but I guess they won't.

While I acknowledge its fragility, I do like the way doctests express 
exceptions quite a lot, so I'd prefer something that kept them like 
that. We've used normalization in the past, so if core Python exception 
messages changed I'd imagine more normalization could help again?

Anyway, since we've only had a few test failures the problems with 
changing message formatting seems to be limited, right?

Regards,

Martijn


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Python 2.7 and the ZTK - three test failures

2010-07-06 Thread Martijn Faassen
Hey,

On 07/06/2010 01:04 PM, Charlie Clark wrote:
  In the specific zope.formlib test we have a doctest
 embedded within another:

 MyForm(None, request)() # doctest: +NORMALIZE_WHITESPACE +ELLIPSIS
   There were errors:
   (u'Invalid floating point data',
exceptions.ValueError instance at ...)

What do you mean, a doctest embedded within another? I'm probably 
missing something.

 Furthermore, while it's great that form.txt actually runs I wasn't aware
 that it contained any additional tests that are not already run and I've
 always treated it as testable documentation not as an integral part of the
 formlib tests. But I'm ready to be believe this is a large misconception
 on my part.

I follow the principle that all testable stuff should actually be run 
during the tests - just in case. :)

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Python 2.7 and the ZTK - three test failures

2010-07-06 Thread Martijn Faassen
On 07/06/2010 01:27 PM, Charlie Clark wrote:
 Am 06.07.2010, 13:12 Uhr, schrieb Martijn Faassenfaas...@startifact.com:

 What do you mean, a doctest embedded within another? I'm probably
 missing something.

 No, it's probably me getting the explicit doctest call wrong. It looks to
 my novice eyes like print statement is being passed to a doctest method.
 In matters like these it's usually safe to assume I'm wrong! :-)

No, that comment (if you mean that?) is just a way to send configuration 
parameters to the doctest engine. It calls the view.

 hm, I don't think that can be argued with really, particularly given the
 amount of time I've actually studied this and other documents over reading
 the code. But I do think that, whether the module runs as specified, and
 whether the documentation is up to snuff, are of a different nature and,
 consequently, so are their failures. Shouldn't we be testing documentation
 differently?

I think a failure in documentation should ideally show up when running 
the tests. I do agree that documentation and tests have different 
concerns and that mixing them can (but does not necessarily have to) 
lead to poor documentation.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope Toolkit - 1.0a1 release

2010-07-06 Thread Martijn Faassen
On 07/06/2010 05:00 PM, Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Fred Drake wrote:
 On Wed, Jun 30, 2010 at 3:47 PM, Hanno Schlichtingha...@hannosch.eu  wrote:
 On behalf of the Zope Toolkit release team and the Zope community, I'm
 happy to announce the first 1.0 alpha release of the Zope Toolkit.

 I've yet to hear any response to my post about non-backward-compatible 
 classes:

  https://mail.zope.org/pipermail/zope-dev/2010-July/040898.html

 Is no one else concerned about the backward incompatibility introduced
 by zope.pluggableauth.plugins.session.SessionCredentialsPlugin?

 Given that ZODB3 and zope.app.container are still non-optional
 dependencies of the package, I can't see any reason not to restore those
 base classes.

zope.pluggableauth doesn't seem to depend on zope.app.container? Or did 
you mean zope.container? I think you meant the latter. I have no 
objection to adding these back in (zope.container.contained.Contained, 
that is), as it doesn't change the dependency.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope summit topics

2010-07-05 Thread Martijn Faassen
Hi there,

Thanks for kicking off this discussion, here's my old grump response. :)

On 06/29/2010 05:24 PM, Hanno Schlichting wrote:

 - Agree on a process for larger feature changes in Zope. Things like
 zope.publisher vs. WSGI, changes to zope.interface semantics, security
 without proxies, the NoZCML movement, ... - we need to have a way to
 talk about these in a structured way, document things, create
 opportunities for feedback from various stakeholders and get a
 definitive answer on whether we allow it or not. There's different
 options for how exactly such a process might look like, but I think we
 definitely need one.

A way to support more drastic innovations in Zope?

It's hard to make decisions when there's no code yet, and it's hard to 
start writing code when there's nobody to make a decision that might 
ever lead to such a change.

I just know what I've been working on:

* a new publisher

* iface to replace zope.interface and zope.component

I think deciding upon such directions as a community can only be done in 
a very broad sense (we want to replace the publisher); as soon as you 
get into details you might get a few useful ideas and then a lot of 
bikeshedding (or nobody talking). Whether such changes will ever make it 
will depend on a small group of people doing the initial work and then 
doing some marketing.

I've been going around the Zope project for years now to get anything 
innovative done; the community in zope-dev only seems to support 
maintenance work that everybody can more or less agree on (and we have 
trouble even with that). I think in a large measure this is all right: 
the Zope project shouldn't radically change at every whim of a 
developer. It should however support a community in which developers can 
experiment with more radical improvements and then adopt them back 
again. We should support innovation better, and have a way to 
consolidate innovations back into the ZTK.

Candidates include:

* the work surrounding zope.sqlalchemy and z3c.saconfig; both already 
represent consolidations of earlier SA integration work.

* Chameleon replacing zope.pagetemplate, and deprecating zope.pagetemplate?

* javascript resource handling: we have zc.resourcelibrary, and 
hurry.resource (radically improving the former), and z3c.hashedresource. 
Most web frameworks aren't even aware that they need such features yet, 
but we've had them for a while. megrok.resource integrates them all in a 
usable way for Grok, but we could adopt this more widely.

(But hurry.resource is not perfect; I think it'd be better to step out 
of Python land and create a Javascript packaging system somewhat modeled 
on Python's, with easy integration into Python projects. A sprint task?)

 - Try to find a way how we can communicate cool new things we do in
 the various projects.

Good point.

We used to have such ways:

Conference presentations and dedicated Zope sprints. Let's have a few 
more of those? And putting more life into planet.zope.org would 
certainly help too.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] buildbot for ZTK released packages (linux 32)

2010-05-19 Thread Martijn Faassen
Tres Seaver wrote:

 python 2.5 and 2.6 :
 - zope.app.wsgi
 
 I plan to work on fixing this failure, which is due to moving the
 zope.testbrowser pin from 3.8.2 to 3,9.1.

How are you going to fix it? I'm asking because we depend on 
zope.app.wsgi for the browser testing of Grok now, at least on a branch.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] buildbot for ZTK released packages (linux 32)

2010-05-19 Thread Martijn Faassen
Tres Seaver wrote:

 I don't know yet -- I planned to look at the failure more closely, and
 figure out something that would work with the newer mechanize.

Just for your information, what we're doing is using wsgi_intercept, 
which hooks into zope.testbrowser, which uses mechanize. But I think we 
actually need more tests for it in zope.app.wsgi.

Anyway, let me know if you need any help on this.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZTK release team - kickoff meeting - delayed summary

2010-05-18 Thread Martijn Faassen
Hanno Schlichting wrote:

 - Look at Tres's list of packages in all three frameworks, decide on a way to
   drop things from the initial ZTK set and on a process for the future.

As long as things are not dropped immediately. Even though Grok 1.2 
might not need foo.bar, transition support might mean it requires it 
still for those people who are porting over existing projects.

Note also that Tres' list is not exactly accurate as it comes to Grok, 
as Tres assumed that information about deprecation in Grok's setup.py 
was actually correct. :). Please be careful with that. I think Grok's 
upcoming 1.2 list will be better.

  - Look at and update
  http://docs.zope.org/zopetoolkit/about/coreextra.html for
adding/removing policies, probably have a deprecated.cfg file

A deprecated.cfg would be a way to support this. Most of zopeapp.cfg 
could eventually go into deprecated.cfg.

The tricky question is what to do those things in zopeapp.cfg which 
won't be deprecated any time soon. An example is zope.app.wsgi. Should 
it stay in zopeapp.cfg? we could rename it to zope.wsgi and move it into 
the ztk.cfg too.

You can then argue that since Zope 2 doesn't use it, it shouldn't be in 
the ZTK, but there are already packages in the ZTK that aren't used by 
Zope 2. If we moved the four to six things out of zopeapp.cfg over into 
ztk.cfg (and deprecated the rest) might that be an acceptable extra 
burden for those who don't use these packages?

Eventually of course we'd even want to dump deprecated stuff completely 
so that we don't need to maintain it at all anymore. We can even move 
that code into a subdir in SVN and put markers in pypi. You'd need a 
clear procedure for that too.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] SVN: zopetoolkit/trunk/ztk.cfg Update to ZODB3 = 3.9.5 and include a pin for the new package providing the mkzeoinst script

2010-05-06 Thread Martijn Faassen
Tres Seaver wrote:
 Vincent Fretin wrote:
 If I followed the commits correctly, the mkzeoinst was extracted from
 ZODB3 package and is now in the zope.mkzeoinstance, right?
 
 Yes.  I was questioning why a ZTK user, rather than somebody using an
 appserver like Zope2, etc., would need a bin/mkzeoinst script (the only
 thing provided by the egg, which I extracted from ZODB at Jim's request).
 
 ZODB is only included in the ZTK as a dependency, because some packages
 import it:  nothing else in the ZTK configures server instances.

Nothing in zopeapp uses it either?

If nothing depends on it, it's less important to track it carefully. Of 
course if app servers start using it they should be tracking it, and if 
common infrastructure emerges that builds on it, it might make sense to 
push it into something more common.

Regards,

Martijn


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] SVN: zopetoolkit/trunk/ztk.cfg Update to ZODB3 = 3.9.5 and include a pin for the new package providing the mkzeoinst script

2010-05-06 Thread Martijn Faassen
Tres Seaver wrote:
 BlueBream or grokproject, which generate code to set up applications,
 might want to pull it in (or emit the depenency into the generated
 code).  Zope2 definitely needs it.

If it's sensible for all three projects to use it I think it makes sense 
for it to be in the ZTK. Even if not all three projects are using it yet. :)

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Zope Tests: 10 OK, 4 Failed, 2 Unknown

2010-05-04 Thread Martijn Faassen
Hanno Schlichting wrote:
 Dropping Python 2.4 supports makes most sense to me at this stage.
 Zope2/Plone only support Python 2.6 for any modern version.
 
 I don't know what BlueBream and Grok want to support, but would guess
 they aim for Python 2.5 + 2.6 support. 2.4 is really old by now.

Grok 1.1 aims for 2.5 and 2.6. Grok 1.0 goes for 2.4 and 2.5, but Grok 
1.0's stable so we don't have problems when the ZTK is updated.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] adding the weekly irc meetings record to the ZTK docs?

2010-05-04 Thread Martijn Faassen
Hi there,

Wouldn't it be useful to add the reports of the weekly IRC meetings to 
the ZTK docs? This way we have an archive that includes some decisions 
and such that's easier to go through than the mailing list archive. It 
also provides a source of information that could then later be 
integrated into the documentation proper.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] adding the weekly irc meetings record to the ZTK docs?

2010-05-04 Thread Martijn Faassen
Charlie Clark wrote:
 I think some kind of paper trail is definitely a good idea. Not sure if  
 docs is the right place but Christian is planning to put the reports into  
 the svn repository. And both location and form are less important than  
 having an archive*. We'll have something sorted by next week. Probably.

Cool! I think since Sphinx + SVN has been working pretty well for us, it 
makes sense to do more of that. Creates easy access through a website.

But separating it from the ZTK procedural docs might make sense, I don't 
know exactly how the scopes relate.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.exceptiosn release has no relaese date

2010-05-03 Thread Martijn Faassen
Lennart Regebro wrote:
 I thought it was painless already, but maybe I was wrong. :)

It's very nice to be able to do a full release by just typing 
'fullrelease' and saying 'yes' a number of times. The tool made a 
convert out of me, and I know others who also were pleased by how much 
it sped things up, even though, as I was, they were initially somewhat 
skeptical.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-03 Thread Martijn Faassen
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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-03 Thread Martijn Faassen
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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-03 Thread Martijn Faassen
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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-03 Thread Martijn Faassen
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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-03 Thread Martijn Faassen
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


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-03 Thread Martijn Faassen
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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-03 Thread Martijn Faassen
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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-03 Thread Martijn Faassen
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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-03 Thread Martijn Faassen
Wichert Akkerman wrote:
 Sorry, my mistake. I meant the ZTK release manage group, not the now 
 defunct ZTK steering group,

If it's defunct someone better update the documentation.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] summary of suggestions

2010-05-03 Thread Martijn Faassen
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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-03 Thread Martijn Faassen
Lennart Regebro wrote:
 On Mon, May 3, 2010 at 13:22, Martijn Faassen faas...@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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] summary of suggestions

2010-05-03 Thread Martijn Faassen
Hanno Schlichting wrote:
 Hi Martijn,
 
 On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen faas...@startifact.com 
 wrote:
 Because my suggestions (besides the fork issue) as a ZTK
 user/contributor were scattered through the thread, here's a handy summary:
 
 Thank you very much for your suggestions. I'm sure the release team
 will pick these up, once we get to start actual discussions.
 
 We have only started talking to each other last week and are slowly
 bootstrapping. Please don't expect us to solve everything in a matter
 of days.

Why not? Why can't you solve things in a matter of days?

The fork took 5 minutes. Does it really take more than saying, okay, 
we're going to unfork, a few modifications to a buildout.cfg and 
figuring out a couple of test failures? I know it's hard to admit a 
mistake, but heck, it shouldn't have to take 4 months.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-03 Thread Martijn Faassen
Lennart Regebro wrote:
 On Mon, May 3, 2010 at 15:41, Martijn Faassen faas...@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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-03 Thread Martijn Faassen
Hi there,

On Mon, May 3, 2010 at 6:06 PM, Lennart Regebro rege...@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
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-03 Thread Martijn Faassen
Hi there,

On Mon, May 3, 2010 at 7:48 PM, Lennart Regebro rege...@gmail.com wrote:
 On Mon, May 3, 2010 at 18:09, Martijn Faassen faas...@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
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] summary of suggestions

2010-05-03 Thread Martijn Faassen
Hi there,

Tres Seaver wrote:
 One issue with insta-updates to ztk.cfg is that ongoing development of a
 package can be in real tension with the needs of ZTK consumers for
 stability in the package set.  

Since there are no ZTK releases Grok and BlueBream gain stability by 
pinning to a particular revision of ztk.cfg (and moving it forward when 
needed). Zope 2 could easily do the same. If more is needed, then a 
branch or tag can easily be made. Besides the perennial documentation 
issues, I also don't see why we couldn't just start releasing the ZTK; 
instead of pinning to an SVN revision we'd start pinning to an SVN tag 
(or a release URL with version number in it). What's the holdup, really?

One objection I can see is that we might end up with quite a few 
releases in a short period, and it might be nicer to have a more stable 
base that people can build on. But they could simply pin to one release 
and stick with it for a while, right?

 E.g., I have updated
 zope.testbrowser/trunk to use the new version of mechanize, but don't
 know whether pulling that version into the ZTK proper is reasonable (in
 fact, I decided to have the ZTK development buildout use a stable
 branch for the meanwhile).

Why wouldn't it be reasonable to try at least? If you tested it with the 
ZTK, you might find issues with your integration of a new version of 
mechanize. But anyway, you didn't release zope.testbrowser either yet, 
so this isn't a very good example of what I'm complaining about.

I understand that you sometimes want to be careful about what to 
include, but this kind of ZTK-breaking release is very rare and I 
haven't seen a good example of it in Zope 2's list. Is there?

 If you are a ZTK consumer, and would like to see the ZTK include a newer
 version of one of its packages, then that need has to be balanced with
 the needs of the downstream projects.  In effect, the new release
 manager group is supposed to represent the interests of Grok, Zope2,
 and BlueBream in a shared definition of the ZTK known good set.
 Getting that nailed down into a version which works for all three is
 *way* more important than picking up individual package changes.

I'll note that Zope 2's fork is moving *faster* than the ZTK itself 
right now; a whole slew of mostly bugfix versions are used by Zope 2's 
list that aren't in the ZTK. I don't see a reason why instead the ZTK 
couldn't have been updated with those bugfix releases and Zope 2 
could've used that. That way Grok and BlueBream would have benefited 
from the same fixes.

And if Zope 2 needs to do a bigger change of a package that's in the 
ZTK, that might break other users of the ZTK, and do a release without 
discussing it here, then there is something wrong already.

Anyway, this all has nothing to do with why the fork happened in 
december. The fork happened in december because of a very specific 
debate that has nothing to do with this. Such lack of commitment made me 
less interested in committing my own time and energy as well.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-03 Thread Martijn Faassen
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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-03 Thread Martijn Faassen
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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] summary of suggestions

2010-05-03 Thread Martijn Faassen
Lennart Regebro wrote:
 On Mon, May 3, 2010 at 20:13, Martijn Faassen faas...@startifact.com wrote:
 Since there are no ZTK releases Grok and BlueBream gain stability by
 pinning to a particular revision of ztk.cfg (and moving it forward when
 needed). Zope 2 could easily do the same. If more is needed, then a
 branch or tag can easily be made. Besides the perennial documentation
 issues, I also don't see why we couldn't just start releasing the ZTK;
 instead of pinning to an SVN revision we'd start pinning to an SVN tag
 (or a release URL with version number in it). What's the holdup, really?
 
 Making a ZTK 1.0a seems to be a good idea to me, and should help here.
 And we don't have to commit to anything, since it's an alpha. 

I think the list needs to commit to something, because we do have people 
coming from older versions of Grok, BlueBream (in the form of Zope 3) 
and Zope 2 (though apparently Zope 2 has the least issues). While the 
ZTK might be new the underlying codebase isn't new at all.

Regards,

Martijn


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-03 Thread Martijn Faassen
Hi there,

On Mon, May 3, 2010 at 10:26 PM, Hanno Schlichting ha...@hannosch.eu wrote:
 On Mon, May 3, 2010 at 9:56 PM, Martijn Faassen faas...@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
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] summary of suggestions

2010-05-03 Thread Martijn Faassen
Hey,

Christophe Combelles wrote:
 Thanks for these suggestions. This is *exactly* what we (the ztk
 release team) need.

How wonderfully diplomatic and constructive, my compliments! The
release team (you, Hanno and JW) look good to me.

 * please let these guidelines not block most updates by most people
  most of the time; it should be easy to update the ZTK. Gatekeepers
  tend to slow things down a lot, and we don't have them for most
 Python code.
 
 We have already started discussing about this. One idea is to let the
 ZTK update or even release by itself, with the help of the buildbot
 infrastructure. I would like to replace the expected ztk bureaucracy
 with automated scripts that enforce some rules and *help* people.
 Particularly the implicit rules that make people upset when they are
 not respected. One example is the first message of the previous
 thread ;)

 The Zope ecosystem and its processes has become quite complex, and we
 cannot expect people to never do errors or to know or read
 everything.

Yes. But I don't think you can replace people's judgment with processes
completely. Differences of judgment will continue to exist too, and they
shouldn't lead to deadlocks. In that case it becomes useful to have
leadership with vision with the authority to break deadlocks. Vision is 
also useful to go beyond processes.

I think one interesting distinction has to do with structure versus
versions.

I think we should be quite open in allowing people to release new
versions of packages and update the ZTK. Especially bugfix releases, of
course, but I think many feature releases can also be safely integrated.

Structural changes, where packages are dropped or added, need more
discussion. I think the cost for having a package in the ZTK is fairly
low as long as it doesn't have a lot of things depending on it, but I
realize that the cost is non-zero so shrinking the ZTK sounds like a
good plan. Dropping is dangerous for other reasons than adding.

Adding a package is dangerous as you give a certain commitment to
maintain this package for a long time.

Dropping a package is dangerous as you break this commitment.

We have the complexity here that we have a *new* project that is
actually the underpinning of several projects (Grok, BlueBream, Zope 2)
with a long history. I therefore think the issue of dropping is
immediately relevant, not only after the 1.0 release.

Why is dropping a package an issue? It's an issue because you break
backward compatibility promises. Another way to look at it is that
you're removing features from the ZTK. Another way to look at it is that
you're removing *tests* from the ZTK. We don't expect people to just
remove a bunch of tests from zope.component without a very good reason
and probably some discussion.

I think this is why version updates are generally okay, even drastic 
version updates, and structural updates are more risky. Of course there 
are some cases where a version update can break a lot of other packages. 
I.e. the package is depended on a lot by other packages and you're 
changing a contract. This is a situation that should be as carefully 
considered as removing a package.

I think the structural organization should follow the lines of interest 
of project groups more than it should follow lines of content. But I'm 
wary about trying to organize too much, as separating bits *does* make 
maintenance harder.

 * there's a 'checknew.py' script to see whether there are releases
 newer than the ZTK. I'd be useful if this were integrated in the
 standard ZTK buildout.cfg so you just get a 'bin/checknew'. It'd
 also be nice if that were reusable by other toolkit projects.
 
 It's on the way. It will probably take the buildout.cfg as an
 argument, to allow checking different buildout files with possibly
 different versions.

Cool. Also reasonable to make 'buildout.cfg' the default, I think?

 * In general it'd be useful if the release team recorded decisions 
 in the ZTK documentation. It's confusing to have to go look for
 them in mailing list archives and people tend to forget or
 reinterpret decisions as time goes by.
 
 Ok, we will write down decisions or status somewhere. We are just
 starting organizing ourselves.

I think you can just use this:

http://docs.zope.org/zopetoolkit/

That's what it is for. It's a Sphinx site. Just a few updates that 
Wichert can point me to when I get confused would probably help both me 
and Wichert tremendously. :)

I kept decisions here, though they should be reorganized:

http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html

You could probably start a new page like that.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] summary of suggestions

2010-05-03 Thread Martijn Faassen
Hi again,

One more suggestion I can make is a way to get an integrated changelog 
for lists of packages such as the ZTK. Right now it's hard to track what 
kind of changes there have been in the ZTK as a whole; you have to go 
through all packages. If there were a way to generate a unified 
changelog between two versions of a ztk.cfg (or other such files), that 
would be useful in doing releases.

A long time ago I experimented with a way to turn a CHANGES.txt into an 
atom feed and then to aggregate those feeds into a Planet in order to 
get some idea of what's going on. Maybe that'd be an interesting 
approach to this.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] zope.exceptiosn release has no relaese date

2010-05-02 Thread Martijn Faassen
Hi there,

I saw a zope.exceptions release on pypi, but it has no release date is 
marked in its change log:

http://pypi.python.org/pypi/zope.exceptions/3.6.0

I recommend following the procedure to avoid such issues:

http://docs.zope.org/zopetoolkit/process/releasing-software.html

I highly recommend the use of zest.releaser to make releasing pretty 
painless.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] Hanno, please update the ZTK

2010-05-02 Thread Martijn Faassen
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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-02 Thread Martijn Faassen
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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Hanno, please update the ZTK

2010-05-02 Thread Martijn Faassen
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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.exceptiosn release has no relaese date

2010-05-02 Thread Martijn Faassen
Hi there,

Two typos in the title, maybe I'm turning into Jim. :)

Regards,

Martijn


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] pypi access to zope.browserresource, zope.browsermenu

2010-04-27 Thread Martijn Faassen
Stephan Richter wrote:
 On Monday 26 April 2010, Martijn Faassen wrote:
 Could someone give me and Hanno pypi access to zope.browserresource and 
 zope.browsermenu?
 
 I am in the process to give you access to all the packages that I am an owner 
 of (now that PyPI is fixed again. :-)
 
 Let me know if hannosch wants the same.

Thanks! Thanks to you doing this in the previous round, I already was 
the owner already of a huge range of packages, but some of the ones that 
dropped out of refactorings were missing. I'll let Hanno speak for 
himself. :)

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZTK community packages

2010-04-26 Thread Martijn Faassen
Hi there,

Tres Seaver wrote:
 Martijn Faassen wrote:
 
 Interesting, and thanks for doing this. Concerning Grok, did you look at 
 Grok 1.0 or Grok 1.1?
 
 Just grok/trunk (I was trying to think about the state of ZTK in terms
 of how it was being used by latest-and-greatest versions of downstream
 projects).

Okay, that should be approximately 1.1.

 and the following further packages say that they are marked as unused,
 according to the dependency checker:
 
 - - zope.app.appsetup

This is definitely being used. I figure it's a dependency through ZCML.

 Of course we'll also need the other zope.app.* packages for a while 
 longer to provide backward compatibility imports and such for those 
 upgrading existing Grok apps.
 
 I'm assuming that BBB imports could be soft dependencies, and that
 developers who are upgrading from earlier Grok versions can adjust their
 own buildouts or package depenencies to pull the extras in without Grok
 needing to provide convenience dependencies -- am I right?

Yes. We'll likely have a grok-backwards package or something like that 
that depends on the lost dependencies, so a developer can depend on 
that with their project.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] pypi access to zope.browserresource, zope.browsermenu

2010-04-26 Thread Martijn Faassen
Hi there,

Could someone give me and Hanno pypi access to zope.browserresource and 
zope.browsermenu?

Our pypi usernames are:

faassen
hannosch

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] ZTK community packages

2010-04-25 Thread Martijn Faassen
Hey,

Interesting, and thanks for doing this. Concerning Grok, did you look at 
Grok 1.0 or Grok 1.1?

For Grok 1.2 we've identified that the following zope.app packages are 
certainly used:

* zope.app.wsgi

* zope.app.appsetup

* zope.app.publication

We've eliminated the dependencies of these packages on zope.app.testing 
and zope.app.zcmlfiles, which both pull in a lot of zope.app.* stuff.

We've expanded zope.app.wsgi so we can run functional tests and 
testbrowser tests without zope.app.testing involved; see 
zope.app.wsgi.testlayer.

We're in the process for Grok 1.2 to try to reduce Grok's dependencies 
to this subset. The grokcore.* packages already eliminate the 
zope.app.zcmlfiles and zope.app.testing dependencies (in the proper 
development branches), but as of yesterday Grok itself only eliminates 
the zope.app.testing dependency so far - zope.app.zcmlfiles is next.

We expect more zope.app.* packages than the ones above will be needed to 
actually run Grok; we don't quite know which ones yet, and we'll be 
looking at them on a case by case basis.

Of course we'll also need the other zope.app.* packages for a while 
longer to provide backward compatibility imports and such for those 
upgrading existing Grok apps.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Summary of today's developer meeting

2010-03-02 Thread Martijn Faassen
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

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] Summary of today's developer meeting

2010-03-02 Thread Martijn Faassen
Hi there,

I've said my piece. I'm not going to argue about it.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] quitting the ZTK steering group

2010-01-22 Thread Martijn Faassen
Hi there,

This is to announce my withdrawal from the Zope Toolkit steering
group.

I withdraw from the Zope Toolkit steering group for two reasons:

* The steering group is not working as a group. Most steering group
   members haven't been doing much steering. This left me by myself to
   try to give direction. I cannot blame the others for committing
   their time differently, but this isn't the balance of work I signed
   up for.

* Trying to steer the ZTK took a large amount of my energy. The
   discussions are quite draining and the benefit to me has not
   been worth the frustration.

In the past year we've made large changes to the dependency structure
of packages, cleaning it up. We've also improved compat testing and
dependency analysis infrastructure a lot.

That's the technical part. The community consequences are also
important. We've been able to redefine the focus of various projects
under the Zope umbrella. Separating the concern of the ZTK from Zope 3
made another refocusing project like BlueBream possible, and made more
clear the relation Grok and Zope 2 have with the libraries in the ZTK.

I think there is a lot more that can be done, but I don't want to feel 
responsible for it.

Here is my analysis of problems with the ZTK:

* Unclear leadership situation. I tried to resolve this by founding
   the ZTK project and steering group in the first place. Besides the
   time investment problems mentioned before, this (my?) leadership is
   also not fully accepted, or its judgment is not fully trusted.

* Even though endless discussions take place, communication is
   frequently poor and frustrating at the same time. Bigger changes
   take too much energy to discuss. People give up even trying to
   cooperate and do it alone as it's a way to get things done. This
   creates a vicious cycle.

* The commitment of parties to work together on the ZTK is
   fragile. Witness Zope 2 withdrawing from the ZTK quickly
   after some disagreements (with me).

My commitment to leading the ZTK as a community project has now 
disappeared as well. I am primarily interested in the development of 
Grok. I came to the ZTK to tackle important issues for Grok, and now am 
going to focus my attention on Grok again. This means that I may 
contribute to the vicious cycle I mentioned above, but so be it.

What this means for the ZTK or the steering group I do not know. The ZTK 
matters to me as a foundation to Grok. In a wider sense, I believe that 
a broader base of people using the ZTK is good for the Zope community 
and Grok as well. I also believe a person or group who offers leadership 
and has a final say is healthy for the project -- just random interested 
people voting -1 or +1 or -1000 or +1000 on the mailing list is a recipe 
for stagnation. We will have to see what the steering group, or anyone 
else, will come up with.

I've tried to ignore zope-dev as much as possible recently, because I 
don't want to be dragged back into sometimes frustrating discussions. If 
you want to reach me you can email me or talk on grok-dev.

Good luck, everybody.

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] New Zope 3 name: BlueBream

2010-01-05 Thread Martijn Faassen
robert rottermann wrote:
[snip]
 all the other items bear so little market value that even an insider can not
 place them.
 
 Therefore I think either of the two should be part of any new packages name
 meant to be recognized by non Zope affectionados.
 
 Bluebream for Zope

I've sometimes called Grok Zope Grok, but there's a value if 
establishing a new brand as well.

Grok, Zope 2 and Blue Bream would all be unified as users of the Zope 
Toolkit. You can also do a lot with domain names to give a unified 
sense, we have grok.zope.org and we could also have 
docs.zope.org/bluebream or something like that. And with web page 
layouts. Anyway, the BlueBream documentation would certainly talk about 
Zope anyway.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] shrinking the ZTK: a proposed solution

2010-01-05 Thread Martijn Faassen
Hermann Himmelbauer wrote:

 But I have to further state that I'm locked into Zope 3.4.0 as the support 
 for 
 Python 2.4 was dropped, so I can't upgrade to the current ZTK.

This is a surprise to me. I thought we still supported Python 2.4

Regards,

Martijn


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] shrinking the ZTK: a proposed solution

2010-01-05 Thread Martijn Faassen
Hi Tres,

You don't seem to get what I kept telling you over and over. I'm 
therefore going to be more blunt.

I don't want to use zope.app packages in Grok. Grok wants to get rid of 
zope.app packages. That's the very idea. We pushed this from the start. 
I spent a huge amount of time to make this possible, just like everyone 
else. But Grok isn't there yet. Neither are people who have to maintain 
Zope 3 apps.

But I have to use zope.app packages in Grok 1.1, because people need to 
have a way to move off zope.app in a working system. It will be the 
equivalent, I believe, of Zope 2.12, though the details are different. 
We cannot ask users to switch their imports in Grok 1.0, as there, for 
instance, zope.app.container is the only thing that exists. There is no 
zope.container yet to switch your imports to.

I am not asking you to help me maintain zope.app packages until the end 
of time. I'm asking you to help me support backwards compatibility code 
in zope.app for a while longer, until I and others have transitioned 
away from those packages as well.

If that code goes untested, it breaks. It already started breaking. 
Jan-Wijbrand noticed test failures on zope.app.exception, just checking 
it out from svn.zope.org. He didn't know a zope.publisher 3.12 was 
released that created this breakage. He didn't even pin down the ZTK or 
anything; it was just a checkout using the most recent releases. The 
person who makes the change in the original package is likely able to 
identify the cause for such breakage much more easily, and either warn 
people about what to do, or make a quick fix himself.

So I'm using zope.app packages, and changes happen in the zope.* subset, 
and zope.app packages are now breaking in SVN when buildouts are run.

Until recently Zope 2 used zope.app packages too, for backwards 
compatibility reasons. If the situation had been reversed and Grok had 
been off zope.app first, I don't think you would have been very happy if 
suddenly these started breaking as they became unmaintained.

Zope 2 is able to move off it more easily for a variety of reasons. Now 
that you're done, but we aren't yet, I am hearing a loud screw you, 
we're done, we don't care about you anymore from you.

That really pisses me off.

It's also just plain stupid if you only a little bit enlightened in your 
self-interest and want the ZTK to succeed and people outside the Zope 2 
community to use it. You're making that a lot harder. You're making my 
lots life harder for short-term selfish reasons. And it makes me really 
want to say screw you too. But that would not be very enlightened.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] shrinking the ZTK: a proposed solution

2010-01-05 Thread Martijn Faassen
Hermann Himmelbauer wrote:
 Am Dienstag 05 Januar 2010 11:58:38 schrieb Martijn Faassen:
 Hermann Himmelbauer wrote:
 But I have to further state that I'm locked into Zope 3.4.0 as the
 support for Python 2.4 was dropped, so I can't upgrade to the current
 ZTK.
 This is a surprise to me. I thought we still supported Python 2.4
 
 That's a surprise to me, too: I remember endless discussions about dropping 
 support for Python 2.4 on this list, let me see:
 
 https://mail.zope.org/pipermail/zope-dev/2009-April/036387.html
 
 I thought the outcome was somehow that Python 2.4 support was dropped?

I recall the conclusion was not to do that yet.

 But I'd appreciate it a lot, if I'm wrong on this! Do the tests pass with 
 Python 2.4 for the ZTK?

I think we have a buildbot for it.

http://dev.thehealthagency.com/buildbot/waterfall

But I do see that Python 2.4 has a failed test, so we do need to fix that.

Regards,

Martijn


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] shrinking the ZTK: a proposed solution

2010-01-05 Thread Martijn Faassen
Jens Vagelpohl wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Hermann Himmelbauer wrote:
 Am Montag 04 Januar 2010 23:10:05 schrieb Tres Seaver:
 Martijn Faassen wrote:
 Obviously I cannot *force* ZTK
 maintainers to worry about this. Instead I'm appealing to your
 self-interest. And of course the transition burden is shared and should
 not fall solely or even predominantly on the ZTK maintainers.
 My self-interest?  Not really:  you are appealing to my altruism, in the
 fact that I care about the *broader* Zope community (broader than Zope2,
 Grok, Plone, or whatever.  Neither of my chosen platforms (Zope2, bfg)
 rely any longer on any of thsoe pacakages at all, which makes my direct
 interest in them exactly zero.
 If the ZTK is decoupled from other users, e.g. from people who rely on 
 zope.app, then they will simply not use it, or do a fork.

 This way, ZTK users are lost, which also leads to a loss of supporters and 
 developers and results in a shrinking interest in ZTK, whose primary goal 
 was/is to be _the_ base for all other Zope-based applications.
 
 How is that any different from people who won't use the ZTK because they
 don't want to deal with any zope.app* baggage?

We were all together carrying the old zope.app* baggage for reasons of 
transitioning out of it. Then one of the party managed to transition out 
of it first. So without warning, they dropped the baggage and ran away 
as fast as they could. :)

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] shrinking the ZTK: a proposed solution

2010-01-05 Thread Martijn Faassen
Jens Vagelpohl wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Martijn Faassen wrote:
 Hey Tres,


 Tres Seaver wrote:

 You're kidding, right?
 [snip]
 My self-interest?  Not really:  you are appealing to my altruism, in the
 fact that I care about the *broader* Zope community (broader than Zope2,
 Grok, Plone, or whatever.  Neither of my chosen platforms (Zope2, bfg)
 rely any longer on any of thsoe pacakages at all, which makes my direct
 interest in them exactly zero.
 Basically we all worked together for a year. Now Zope 2 happens to be 
 done first moving off zope.app, so you're telling me f$%#%Q#k you, I 
 don't need you anymore, go away.
 
 That's not what he is telling you. I don't think he ever intentionally
 worked together to support zope.app* packages in any way. If anything,
 he may have had input into and interest in the small ZTK packages
 and/or direction, so his viewpoint has never changed.

Well, Zope 2 released with a smaller but present dependency on zope.app 
some time ago. Those zope.app packages were at least until then relevant 
to Zope 2 developers. If support for them had been dropped by someone 
then, they would have had to pick up maintaining them themselves, if 
they wanted to continue tracking the ZTK and give Zope 2 users an 
upgrade path out of zope.app.

Whether they are still relevant today is harder to say as Zope 2 already 
had some transition time behind it.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] shrinking the ZTK: a proposed solution

2010-01-05 Thread Martijn Faassen
Martijn Faassen wrote:
[snip]
 But I do see that Python 2.4 has a failed test, so we do need to fix that.

Some of those failure appears to be because some code was switched over 
to the Python standard library pprint from the version in zope.testing, 
and in Python 2.4 that doesn't sort dictionaries.

http://dev.thehealthagency.com/buildbot/builders/ztk%20slave-ubuntu32-py2.4/builds/4/steps/test/logs/stdio

We already talked about undeprecating that pprint function in 
zope.testing.doctestunit. It'd be nice if someone looked into doing that.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] how to help Martijn (how can we have better discussions?)

2010-01-04 Thread Martijn Faassen
Martin Aspeli wrote:
 Martijn Faassen wrote:
 
 Instead, we had endless debates about whether it was a legitimate
 concern for the ZTK maintainers. I'm of course still right that it is.
 I have wonderful and coherent reasons to support my position just like
 everybody else does who disagrees with me. It's not really very
 important anyway. We're here together on this list to work together
 beyond the ZTK itself.
 
 I think one problem is that we speak about abstract groups of people, 
 the ZTK maintainers, or the Zope 3 maintainers and now The ZopeApp 
 maintainers. These groups don't really exist in any cultural sense. 
 They don't have an identity in the same way that, say, the Plone 
 maintainers or the Grok maintainers (and possibly, the Zope 2 
 maintainers) do. It's hard for any one group to make their voice heard 
 when no-one knows if they're part of that group or not. :)

Agreed that this is a problem, though it's hard to find a balance here. 
It's useful to speak of roles that are a bit more abstract than me and 
my apps. So, in that sense Zope 3 maintainers is a useful concept 
instead of just mentioning, say, me, and Marius and others who have to 
deal with Zope 3 applications on various occasions.

It's also useful to speak about such groups if you want to actually 
change the focus of energy in this community. That's where the idea of 
ZTK maintainers come from. It's a convenient way to say: we are going 
to care about zope.app. stuff less together, and focus on something else.

But in the end this mailing list is just the community of people who 
talk and work together here, no matter what roles they have.

 I think in general, it's more useful to talk about the Zope community 
 until such time that these groups actually self-organise, if indeed they 
 ever do.

You still need to be able to talk about groups with various concerns. We 
do have some organizational structure in place for ZTK, for instance. 
That was one of the points: having a decision making infrastructure at all.

 I know we have had a lot of problems reaching conclusions in such
 discussions in the past, but we can't learn how to do better at that if
 we don't. And we are going to do better if I can help it.
 
 I think we normally do reach conclusions, thanks often to people like 
 you tirelessly summarising and soliciting input. I don't think that part 
 is broken. Big discussion threads usually mean people are either 
 passionate about or highly dependent on Zope as a framework, or both. 
 I'd take that over apathy any day.

We definitely have problems. It takes a lot of energy, too much, to get 
bigger changes through. A bit of a slow-down for big changes isn't 
necessarily a bad thing, but all too often it makes people feel they 
have to work around zope-dev and just do things somewhere else (or anyway).

In the past, we frequently blocked on issues that just never reached a 
conclusion because nobody was there to say yes go ahead at the right 
time. We also regularly forgot conclusions. We've improved somewhat over 
the course of the last year, but we need to improve a lot further in my 
opinion.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] how to help Martijn (how can we have better discussions?)

2010-01-04 Thread Martijn Faassen
Martijn Faassen wrote:
[snip]
 So how can we have better discussions?
 
 We can have better discussions by helping me.
 
 How can you help me? Of course it helps if you agree with me. I realize 
 that's frequently infeasible, but I certainly wouldn't mind. :)
 
 If you disagree with me, I'd like you to try to understand my concerns 
 as much as you possibly can. In addition, try acknowledge my concerns as 
 much as you possibly can without feeling you're lying. This works beter 
 than just rejecting them.

Chris McDonough pointed out to me that I didn't help in that discussion 
by not making my own individual concerns clear. I contributed to the 
problem by talking about abstract responsibilities instead of focusing 
on concrete needs of myself and people I know about.

So: I actually *need* the zope.app information (and a well-tested 
zope.app) in transitioning applications (in Zope 3 or Grok) I work on 
the ZTK. As a Grok developer I also need that info to help transition 
Grok and Grok users to the ZTK. This way we can port Grok and our 
applications to ZTK and zope.app.* first, and then when the tests run, 
slowly change the imports to strip away zope.app.* dependencies. Like 
what we did with the ZTK itself, in fact.

I'd like to share the burden of maintaining zope.app* with others. I 
hope those of you who want to improve the ZTK also will help in making 
sure zope.app.* doesn't suddenly break.

I wasn't very successful in explaining all that before, so perhaps it's 
clearer in the personal.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] upload zope.app.exception to pypi

2010-01-04 Thread Martijn Faassen
Martijn Faassen wrote:
 It seems to be occurring somewhere in the setup of the test layer, but 
 strangely enough the publisher kicks in somewhere. I'm curious why the 
 ZTK tests didn't catch this issue (or now the zopeapp tests).

Hm, the zopeapp tests are catching this today. They weren't catching it 
last week. I think something broke in the mean time. I'm getting these 
problems across a lot of zope.app.* packages now, not just 
zope.app.exception.

I updated the ZTK a few times with changes Hanno made to the Zope 2 
fork. Perhaps I neglected to run the zopeapp tests. That's not a good 
sign for the future.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


[Zope-dev] zope.publisher 3.12 broke 25 zope.app packages

2010-01-04 Thread Martijn Faassen
Hi there,

25 zope.app packages are broken due to changes in zope.publisher 3.12. 
zope.publisher had some components factored out of it into zope.login.

I fixed zope.app.exception: it could be fixed by adding the zope.login 
requirement and adding a zcml include statement. I suspect most, 
probably all, other failures are similarly shallow.

The breaking of so many packages wasn't noticed by anyone, until tests 
of svn checkouts that previously worked now broke.

I hope we can put mechanisms in place so that developers of ZTK packages 
can be better made aware of breaking other packages that depend on the 
ZTK. This way the developer making the changes could do one or more of 
the following:

* provide better backward compatibility

* fix up the breaking packages

* provide a better warning to others who are maintaining these packages 
that something was broken.

I faintly, faintly recall we had such early-warning mechanisms in the 
past. :)

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] zope.publisher 3.12 broke 25 zope.app packages

2010-01-04 Thread Martijn Faassen
Hanno Schlichting wrote:
 On Mon, Jan 4, 2010 at 11:51 PM, Martijn Faassen faas...@startifact.com 
 wrote:
 Good news, it was only 24 packages, I counted wrong. :)
 
 Couldn't you have solved that by updating one underlying package, like
 zope.app.testing? Most of zope.app generally depends on things like
 app.testing, app.zcmlfiles or things like app.publsher.

You're probably right - I am not really thinking straight today.

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 )


  1   2   3   4   5   6   7   8   9   10   >