Re: [Zope-dev] the Zope Framework project

2009-03-05 Thread Hermann Himmelbauer
Am Mittwoch 04 März 2009 18:03:17 schrieb Lennart Regebro:
 On Wed, Mar 4, 2009 at 17:48, Martijn Faassen faas...@startifact.com 
wrote:
  Note that the Zope Steering group is not about
  packages that are not in the framework, so if lovely.remotetask isn't
  there, it can say little.

 Which is exactly my point. It surely isn't at the moment, and I don't
 see that it should be any time soon. What Hermann suggested is
 somebody that keeps track of all Zope software modules and tells him
 which is good and which is bad. That's not what you suggested, and as
 mention, I don't think it's even possible, and definitely not a good
 idea.

Well, yes and no: My idea is that there will be a well-defined set of core 
packages, and probably some extra packages that are also embraced (e.g. maybe 
z3c packages, e.g. z3c.form).

Of course, trying to embrace every zope package out there will not work. But I 
think it will make sense to embrace packages that cover a common usecase, for 
instance, creating remote tasks is nothing uncommon and will be needed by 
many people. Therefore I'd suggest to embrace at least one package that 
covers that functionality (e.g. lovely.remotetaks, or zc.async, or something 
else).

For all other packages, it will make sense to create some infrastructure, as 
stated in another mail of Martijn.

Best Regards,
Hermann

-- 
herm...@qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-05 Thread Hermann Himmelbauer
Am Mittwoch 04 März 2009 17:48:37 schrieb Martijn Faassen:
 Hi there,

 Lennart Regebro wrote:
 [snip]

  And it is in any case in no way even remotely connected to the group
  Martijn proposed and has been discussed in this thread.

 - Attracting newbies to web development is not a task of the Zope
 Framework project directly, and here I diverge from Hermann. That's a
 task of the Plone project or the Grok project, etc. I do think that the
 Zope Framework leadership could be much better at attracting and
 stimulating contributions to the libraries.

 Attracting more users is important, but that's a task for the Zope 3 app
 server developers (however they organize) or the Grok project. The Zope
 Framework is a second-level provider to these projects, and in reality
 of course people who care about these projects will do most of the
 driving of development of the Zope Framework. It's a forum where all
 users of these libraries (many or just a few) can get together, work out
 our diverse interests, and coordinate.

Ok, it seems I mixed up the Zope3 app server and the Zope Framework a 
little.So, I agree that attracting newbies should better be done via 
Grok/Zope3 app server or anything else that build on top of the Zope 
Framework, as this is the logic path.

Nevertheless the Zope Framework should have:

- Documentation
- Central Website
- Some other structure for collaboration (mailing list...)

And I think that these points should also be a topic of the steering group.

I think an ideal approach would be that the above can be seamingless 
integrated in upper-level frameworks, so that the step from Zope3 app 
server/Grok to the Zope Framework is as easy as possible, and, moreover, that 
efforts need not to be doubled (e.g. that someone writing documentation for 
Zope 3 app server has to write something about interfaces or the component 
architecture).

Best Regards,
Hermann

-- 
herm...@qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-05 Thread Hermann Himmelbauer
Am Mittwoch 04 März 2009 19:00:12 schrieb Baiju M:
 On Wed, Mar 4, 2009 at 9:55 PM, Martijn Faassen faas...@startifact.com
 wrote:

 [snip]

  The steering group isn't intended to take a responsibility for the
  entirety of the Zope software. Zope 2, Grok and the Zope 3 app server
  (which would be a distinct entity) would manage themselves and the Zope
  Framework steering group would not have a say over the libraries and
  configuration they add.

 [snip]

  I do also think that we should go to a smaller set of libraries. We
  currently share a huge amount of code that only one consumer actually
  uses. For instance, I think all of the zope.app.* packages which contain
  ZMI code can eventually be left to the management of the Zope 3
  developers, meaning they'd not be part of the Zope Framework anymore.

 [snip]

  
  As a service to the users of the Zope Framework, the Zope developers
  also make available lists of version numbers of core libraries that
  have been tested to work together as a Known Good Set. This receives
  a version number and is the Zope Framework release.  Users of the Zope
  framework can use this list, but may also diverge from it where they
  see fit. Other projects (such as the Zope 3 application server and the
  Grok project) also have a Known Good Sets that expand on the Zope
  framework list (and may diverge from it). Each of these consumer
  projects can of course have their own release process, schedule and
  version numbering.
  

 [snip]

  It may very well be true that in some time we'll develop clusters of
  libraries that can be more or less managed on their own. The ZMI is such
  a cluster that I hope will eventually emerge (and that the Zope
  Framework Steering Group doesn't care about directly). That'd reduce the
  coordination overhead. But sometimes we do need to take coordinated
  action, and I don't see that need disappearing entirely.

 I think those who care about Zope 3 (framework/app server/libraries/
 or whatever)
 should form a team and mailing list to discuss about the future
 development. All other major consumers of the Zope Framework Project has
 their on mailing list for discussions.  I guess very soon zope-dev list
 will become inappropriate to discuss about Zope 3.  Just like Grok,Repoze
 etc. it is better
 to create a list for Zope 3, may be re-activate zope3-dev list to
 discuss about
 the Zope 3 (framework/app server/libraries/ or whatever). Well, if
 no one cares
 about Zope 3, let's leave it.

What would be interesting to know is:

- Who is out there
- What these people are using:
  * Zope libraries
  * Zope 2
  * Zope 3 app server
  * Plone
  * Grok
  * Something else
- Who has already contributed (and what)
- Who has the technical expertise and time to contribute

This probably would help us/the steering group to form teams around different 
projects. For instance, as the steering group is not about the Zope 3 app 
server, there needs to be some team for that part.

And I am personally interested if the Zope 3 app server is something that's 
dying in favour for other projects (Plone/Grok) or is actively used.

Best Regards
Hermann

-- 
herm...@qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-05 Thread Dieter Maurer
Martijn Faassen wrote at 2009-3-3 00:36 +0100:
 ...
* how will the community make hard decisions where lots of people 
disagree?

You try to achieve consensus. When you do not, you get the chance
that people turn away.

 ...
* who reminds us of necessary tasks and directions we're going into? 

Beside the reminders, you need people that do the work.
For this, at least, these people must be convinced.



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


Re: [Zope-dev] the Zope Framework project

2009-03-05 Thread Dieter Maurer
Martin Aspeli wrote at 2009-3-3 17:21 +0900:
 ...
How many times have we gotten bogged down in semantics or 
naming discussions and killed off the momentum behind something?

A clear notion of semantics and well chosen names are important
for any project.

I would not want momentum resulting in confused semantics and
misleading names.



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


Re: [Zope-dev] the Zope Framework project

2009-03-05 Thread Dieter Maurer
Martijn Faassen wrote at 2009-3-3 22:11 +0100:
 ...
 backwards compatibility at all costs,

I agree that have erred on the side of too much backwards compatibility. 
That increased the overhead of changes tremendously and blocked innovation.

Large applications are built upon the framework.

If the framework too often drifts away, the maintenance costs
for these applications gets too high -- and make the framework
unattractive.



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


Re: [Zope-dev] the Zope Framework project

2009-03-05 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dieter Maurer wrote:
 Martijn Faassen wrote at 2009-3-3 22:11 +0100:
 ...
 backwards compatibility at all costs,
 I agree that have erred on the side of too much backwards compatibility. 
 That increased the overhead of changes tremendously and blocked innovation.
 
 Large applications are built upon the framework.
 
 If the framework too often drifts away, the maintenance costs
 for these applications gets too high -- and make the framework
 unattractive.

But if the framework is no longer monolithic, you can keep using the
bits you need for BBB, while selectively updating newer pieces.  The
more loosely-coupled the pieces are, the more likely such a partial
upgrade is to work.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJsIWO+gerLs4ltQ4RAlWuAKCwUyNkbz9zKaLHgWp/WwTTPjufVgCePgxk
PIIdR4FnOAUMuJgKupdjpYQ=
=WiRX
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Andreas Jung
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04.03.2009 8:50 Uhr, Chris McDonough wrote:
 Andreas Jung wrote:
 
 2) I'm also not in favor of a giant lockstep set of software versions shared
 between notional releases Zope 3.5, Grok, and Zope 2.12.  I can only see 
 this as
 continuing our mistakes of old by trying to treat some collection of 
 software as
 Zope as opposed to letting parts of it survive or die on their own based 
 on
 merit; it'd be more effective to just let each framework use (or disuse!)
 whatever versions of stuff that work best for it.  That's why the software 
 is
 broken out into individual components in the first place; we should 
 encourage
 diversity in component usage.  Instead of trying to legislate and bless 
 some set
 of components as a version, we should just work to make each piece better 
 and
 worthwhile to use independently; it's value would be in its actual 
 usefulness
 rather than some belief that it works well with the other components in the
 version.  Could we at least agree that lockstep versioning of a huge set 
 of
 Zope eggs to be shared across many frameworks is not optimal for the long 
 term
 and that it would be better if each framework could pick and choose whatever
 components and versions it actually needed?  Could we also agree that this 
 would
 tend to result in better dependency partitioning (X depends on Y, I don't 
 need
 Y, I just need X, let's fix that)?

 A central maintained KGS for Zope 3.X components is necessary since only
 a minor number of core developers knows exactly which version match
 together. You can not expect that non-core developers have this
 knowledge. 
 
 In places that require cross-package API contracts, each contract should be
 spelled out in an interface.  If each contract is spelled out in an interface,
 non-core developers should have no problem gaining this knowledge.  That's 
 what
 interfaces are for.

Interfaces are one side of the medal, the other side are dependencies
expressed through version pinning. We have had enough examples with
version conflict with modules that would obviously fit together based
on their interface definitions. That's where a KGS helps a lot - however
this is not a contradiction to the approach that Tres pointed out with
maintaining a per-project index with hand-selected packages. I find this
idea very compelling for a bunch of usecases - not sure if this a
general approach - one out of many.

Andreas

- -- 
ZOPYX Ltd.  Co. KG - Charlottenstr. 37/1 - 72070 Tübingen - Germany
Web: www.zopyx.com - Email: i...@zopyx.com - Phone +49 - 7071 - 793376
Registergericht: Amtsgericht Stuttgart, Handelsregister A 381535
Geschäftsführer/Gesellschafter: ZOPYX Limited, Birmingham, UK
- 
E-Publishing, Python, Zope  Plone development, Consulting

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkmuOPAACgkQCJIWIbr9KYwOjQCgt9O7I4qdRBlzqsm93OfzYBf2
VYQAoII60shD+EkPF9TqaTb5ZaQQ3rDT
=DrbH
-END PGP SIGNATURE-
begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX Ltd.  Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany
email;internet:i...@zopyx.com
title:CEO
tel;work:+49-7071-793376
tel;fax:+49-7071-7936840
tel;home:+49-7071-793257
x-mozilla-html:FALSE
url:www.zopyx.com
version:2.1
end:vcard

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Chris McDonough
Lennart Regebro wrote:
 On Wed, Mar 4, 2009 at 07:52, Chris McDonough chr...@plope.com wrote:
 Tather than reply in kind here, let me summarize:  I'm glad we agree more 
 than
 we disagree, and I apologize if I've attributed to you beliefs that you don't
 have.  It's heartening to hear that you're in favor of most of the things I'm
 also in favor of.  But we do have real differences in opinion I think.  I'd
 rather be constructive than obstructionist here: at the end of each item 
 below I
 ask for an opinion based on a suggestion.

 1)  I'm not in favor of a single steering group for the *entirety* of all 
 Zope
 software.   We've tried a similar thing in the past (via the foundation
 structure); it didn't work and I'm not sure how we'd expect things to turn 
 out
 any differently this time.  Instead, perhaps the focus of groups should be on
 some much smaller subset of Zope-related software (e.g. the
 zope.interface+zope.component group, the zope.schema group, the ZODB group,
 etc).  Could we consider this?
 
 It's better certainly, but isn't this small enough in itself that
 these groups will form naturally by whoever is working on it?

To the extent we can discourage the formation of the
one-big-group-to-rule-them-all by encouraging the formation of smaller groups, I
think it's a good idea.  But in reality, I think nothing needs to be done:
group-forming will always be a self-selecting process.

 No, we want Zope 3.4 to have one set of modules with one API, and Grok
 1.0 and Zope 2.12 to use exactly the same. And then a Zope 3.4 with a
 Grok 1.1 (or something) and a Zope 2.13. So we DO want lockstep and
 to use the same major KGS over all these versions. At least I do I
 don't see why this must result in parts that should die being left
 undead.

This just seems like a blindingly obvious antigoal to actually breaking apart
the software into more discrete bits using eggs.  Why not just stick with a huge
tarball release or one single egg if it all has to be versioned through time to
99% of its consumers as one giant collection of software treated as a unit?

 If Repoze.bfg doesn't want to lockstep, the Zope2/Zope3/Grok lockstep
 would not pose a problem for Repoze, would it?

Nope.

 Then again, if Repoze
 doens't want to be a part of The Zope Framework users but always make
 their own set of modules, that will admittedly lessen the purpose of
 it, as the minimalistic attitude of Repoze.bfg would work as a good
 test of what should be in the framework in the first place.

Right.  No one except people who've already bought in to the notion of Zope
software as one huge pile will benefit from the lockstep centralized planning.
It won't gain Zope any new users; no different framework users will begin to use
Zope software as a result of this plan.  How is this different than the current
status quo?

 Could we at least agree that lockstep versioning of a huge set of
 Zope eggs to be shared across many frameworks is not optimal for the long 
 term
 
 Well, since it's shared by many frameworks, I'm not sure it would be
 huge. But that's a matter of taste of course. But in any case,
 through this discussion, I must admit that I not not understand why
 this would pose problem.

It doesn't pose a problem.  It's just business as usual.

 and that it would be better if each framework could pick and choose whatever
 components and versions it actually needed?
 
 It can. These are not mutually exclusive. A central KGS for the core
 framework does not exclude you making your own KGS, neither does it
 mean you can't release each module separately.
 
 Could we also agree that this would tend to result in better dependency 
 partitioning
 (X depends on Y, I don't need Y, I just need X, let's fix that)?
 
 I don't see how these are related.

When components are not treated as one giant pile, and it's expected that you
should be able to use pieces of the pile selectively without buying in to some
unrelated software, dependency management becomes far more brutal and realistic.

- C

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Hermann Himmelbauer
Am Mittwoch 04 März 2009 07:52:09 schrieb Chris McDonough:
 Tather than reply in kind here, let me summarize:  I'm glad we agree more
 than we disagree, and I apologize if I've attributed to you beliefs that
 you don't have.  It's heartening to hear that you're in favor of most of
 the things I'm also in favor of.  But we do have real differences in
 opinion I think.  I'd rather be constructive than obstructionist here: at
 the end of each item below I ask for an opinion based on a suggestion.

 1)  I'm not in favor of a single steering group for the *entirety* of all
 Zope software.   We've tried a similar thing in the past (via the
 foundation structure); it didn't work and I'm not sure how we'd expect
 things to turn out any differently this time.  Instead, perhaps the focus
 of groups should be on some much smaller subset of Zope-related software
 (e.g. the
 zope.interface+zope.component group, the zope.schema group, the ZODB group,
 etc).  Could we consider this?

What I don't see in your proposal is, how these subset-groups would be 
coordinated, which leads to the following:

- How would these groups be formed? If there's nobody who encourages people to 
do so, 

- Higher level package/groups may have a hard life in case basic 
packages/groups are not coordinated and all go their own way.

- How does some foreigner know, if a package is actively supported, 
umaintaned, deprecated etc.? How does he know, what packages exist, what they 
are good for and the like? For instance, I yesterday wrote that I use 
lovely.remotetask, then I was asked on the list why I did not use the (maybe 
better) zc.async package. Know why? I did not know that it existed.

- I think, Zope 3 is not only about some seperate packages, but about a 
complete programming experience. Thus there needs to be some integrating 
force, that draws together all these packages, writes some documentation / 
tutorial / website etc.

- Newbies won't be attracted by single packages. Instead, they want something 
complete. Who would be interested in Plone if it would consist of various 
packages that people would have to draw together by themselves, without 
decent documentation?

To my mind, one key point is attracting more users. And that can only be done 
if we try to view things from an external, newbie-perspective. Some Ruby on 
Rails / Java / Turbogears programmer will only be attracted by some big 
picture but probably not by a collection of some subpackages.

So, my impression is that there is a need for some steering group, that will, 
however, encourage people to form groups around packages and maintain them.

Best Regards,
Hermann

-- 
herm...@qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Lennart Regebro
On Wed, Mar 4, 2009 at 09:21, Chris McDonough chr...@plope.com wrote:
 To the extent we can discourage the formation of the
 one-big-group-to-rule-them-all by encouraging the formation of smaller 
 groups, I
 think it's a good idea.  But in reality, I think nothing needs to be done:
 group-forming will always be a self-selecting process.

Well, at least we should try this first, I agree with that.

 No, we want Zope 3.4 to have one set of modules with one API, and Grok
 1.0 and Zope 2.12 to use exactly the same. And then a Zope 3.4 with a
 Grok 1.1 (or something) and a Zope 2.13. So we DO want lockstep and
 to use the same major KGS over all these versions. At least I do I
 don't see why this must result in parts that should die being left
 undead.

 This just seems like a blindingly obvious antigoal to actually breaking apart
 the software into more discrete bits using eggs.  Why not just stick with a 
 huge
 tarball release or one single egg if it all has to be versioned through time 
 to
 99% of its consumers as one giant collection of software treated as a unit?

But it doesn't have to be treated as a unit. I don't know what you
mean with version through time to 99% of its customers. To me having
releases of modules and releases of sets of modules is orthogonal and
does not contradict each other.

 Then again, if Repoze
 doens't want to be a part of The Zope Framework users but always make
 their own set of modules, that will admittedly lessen the purpose of
 it, as the minimalistic attitude of Repoze.bfg would work as a good
 test of what should be in the framework in the first place.

 Right.  No one except people who've already bought in to the notion of Zope
 software as one huge pile will benefit from the lockstep centralized planning.

I have the feeling that either you or me have completely misunderstood
the proposal, because I don't think you are talking about the same
proposal as me.

 Could we also agree that this would tend to result in better dependency 
 partitioning
 (X depends on Y, I don't need Y, I just need X, let's fix that)?

 I don't see how these are related.

 When components are not treated as one giant pile, and it's expected that you
 should be able to use pieces of the pile selectively without buying in to some
 unrelated software, dependency management becomes far more brutal and 
 realistic.

Yes. And I still do not see how this is related to the proposal. It is
expected that you should be able to use pieces of the pile
selectively, and it will continue to be expected.

-- 
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Lennart Regebro
On Wed, Mar 4, 2009 at 10:04, Hermann Himmelbauer du...@qwer.tk wrote:
 What I don't see in your proposal is, how these subset-groups would be
 coordinated, which leads to the following:

 - How would these groups be formed? If there's nobody who encourages people to
 do so,

They will be formed by people grouping together to work on a piece of
software, if such a group is necessary.

 - Higher level package/groups may have a hard life in case basic
 packages/groups are not coordinated and all go their own way.

Then these higher level groups will help coordinate the lower level packages.

 - How does some foreigner know, if a package is actively supported,
 umaintaned, deprecated etc.? How does he know, what packages exist, what they
 are good for and the like? For instance, I yesterday wrote that I use
 lovely.remotetask, then I was asked on the list why I did not use the (maybe
 better) zc.async package. Know why? I did not know that it existed.

 - I think, Zope 3 is not only about some seperate packages, but about a
 complete programming experience. Thus there needs to be some integrating
 force, that draws together all these packages, writes some documentation /
 tutorial / website etc.

 - Newbies won't be attracted by single packages. Instead, they want something
 complete. Who would be interested in Plone if it would consist of various
 packages that people would have to draw together by themselves, without
 decent documentation?

 To my mind, one key point is attracting more users. And that can only be done
 if we try to view things from an external, newbie-perspective. Some Ruby on
 Rails / Java / Turbogears programmer will only be attracted by some big
 picture but probably not by a collection of some subpackages.

 So, my impression is that there is a need for some steering group, that will,
 however, encourage people to form groups around packages and maintain them.

The steering group would not and could not help with any of these problems.

-- 
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Hermann Himmelbauer
Am Mittwoch 04 März 2009 08:16:26 schrieb Lennart Regebro:
 On Wed, Mar 4, 2009 at 07:52, Chris McDonough chr...@plope.com wrote:
  Tather than reply in kind here, let me summarize:  I'm glad we agree more
  than we disagree, and I apologize if I've attributed to you beliefs that
  you don't have.  It's heartening to hear that you're in favor of most of
  the things I'm also in favor of.  But we do have real differences in
  opinion I think.  I'd rather be constructive than obstructionist here: at
  the end of each item below I ask for an opinion based on a suggestion.
 
  1)  I'm not in favor of a single steering group for the *entirety* of all
  Zope software.   We've tried a similar thing in the past (via the
  foundation structure); it didn't work and I'm not sure how we'd expect
  things to turn out any differently this time.  Instead, perhaps the focus
  of groups should be on some much smaller subset of Zope-related software
  (e.g. the
  zope.interface+zope.component group, the zope.schema group, the ZODB
  group, etc).  Could we consider this?

 It's better certainly, but isn't this small enough in itself that
 these groups will form naturally by whoever is working on it?

But isn't that the current situation?

I think there are two scenarious when people will deal with a package in-depth 
on their own:

1) They found a bug: I made the experience that in case I find some bug and 
dig into some Zope 3 code, things tend to become very complicated and I often 
can't understand/fix it. For instance, I found some bug/misbehaviour 
regarding combination of virtual hosts and ++xyz++ URL-variables (forgot the 
name for that) and was not able to apply a clean fix due to lack of 
understanding. I could not find anyone on the list, who was responsible for 
that piece of code, so I did some hacking and never committed this (dirty) 
hack as it's certainly not up to the Zope 3 standards.

2) They want to extend a package: In order to do that, I'd first like to 
understand the package in-depth, so that my extensions don't break concepts 
and code. But it seems that there are many packages (and even core packages) 
where nobody seems to feel responsible for, or, I just don't know who it is 
and can therefore not get to the required information.

If there's no one that is motivated by (1) or (2), the package is abandoned 
(although it may even have core functionality). And my impression is that 
this has already happend for some packages, which is bad.

Therefore I think it would be a great advantage if there is some group that 
makes sure that each package has someone associated with, who has in-depth 
knowledge and maintains it. And if there is no interest in a package anymore 
and it's not used, this group may give it the status umaintained and kill 
it off.

Best Regards,
Hermann

-- 
herm...@qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Baiju M
On Wed, Mar 4, 2009 at 2:34 PM, Hermann Himmelbauer du...@qwer.tk wrote:
[snip]
 - I think, Zope 3 is not only about some seperate packages, but about a
 complete programming experience. Thus there needs to be some integrating
 force, that draws together all these packages, writes some documentation /
 tutorial / website etc.

+1

I believe packages developed as part of the Zope 3 project is
here to stay for a long time (of course, after dependency cleanup
some of them may become obsolete). This will happen even if some
of the frameworks based on it are no more available.

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Hermann Himmelbauer
Am Mittwoch 04 März 2009 10:25:19 schrieb Lennart Regebro:
 On Wed, Mar 4, 2009 at 10:04, Hermann Himmelbauer du...@qwer.tk wrote:
  What I don't see in your proposal is, how these subset-groups would be
  coordinated, which leads to the following:
  - How does some foreigner know, if a package is actively supported,
  umaintaned, deprecated etc.? How does he know, what packages exist, what
  they are good for and the like? For instance, I yesterday wrote that I
  use lovely.remotetask, then I was asked on the list why I did not use the
  (maybe better) zc.async package. Know why? I did not know that it
  existed.
 
  - I think, Zope 3 is not only about some seperate packages, but about a
  complete programming experience. Thus there needs to be some
  integrating force, that draws together all these packages, writes some
  documentation / tutorial / website etc.
 
  - Newbies won't be attracted by single packages. Instead, they want
  something complete. Who would be interested in Plone if it would consist
  of various packages that people would have to draw together by
  themselves, without decent documentation?
 
  To my mind, one key point is attracting more users. And that can only be
  done if we try to view things from an external, newbie-perspective. Some
  Ruby on Rails / Java / Turbogears programmer will only be attracted by
  some big picture but probably not by a collection of some subpackages.
 
  So, my impression is that there is a need for some steering group, that
  will, however, encourage people to form groups around packages and
  maintain them.

 The steering group would not and could not help with any of these problems.

Why? Can you elaborate? Who/what group woud play that central/integrating 
role? Maybe we have different perceptions of a steering group, but my 
impression was that this group would see the above points as their key 
topics.

Maybe I don't get your point, but your suggestion seems to be to let things 
go in a natural flow as it happens now. But that would imply that the 
current situation is satisfying, which seems not to be, as can be read in all 
those various posts regarding this topic.

What would be further interesting is, if there are any successful open-source 
projects, that implement such a non-leadership/natural flow model, because 
I'm not aware of any.

Best Regards,
Hermann

-- 
herm...@qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Lennart Regebro
On Wed, Mar 4, 2009 at 10:56, Hermann Himmelbauer du...@qwer.tk wrote:
 Am Mittwoch 04 März 2009 10:25:19 schrieb Lennart Regebro:
 On Wed, Mar 4, 2009 at 10:04, Hermann Himmelbauer du...@qwer.tk wrote:
  What I don't see in your proposal is, how these subset-groups would be
  coordinated, which leads to the following:
  - How does some foreigner know, if a package is actively supported,
  umaintaned, deprecated etc.? How does he know, what packages exist, what
  they are good for and the like? For instance, I yesterday wrote that I
  use lovely.remotetask, then I was asked on the list why I did not use the
  (maybe better) zc.async package. Know why? I did not know that it
  existed.
[...]
 The steering group would not and could not help with any of these problems.

 Why? Can you elaborate? Who/what group woud play that central/integrating
 role? Maybe we have different perceptions of a steering group, but my
 impression was that this group would see the above points as their key
 topics.

I don't think it's possible, and it seems to me to be a rather strange
idea to have a group keep track of all the packages in the Zope world
and somehow categorize them by quality.

And it is in any case in no way even remotely connected to the group
Martijn proposed and has been discussed in this thread.

-- 
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Paul Everitt
On 3/4/09 1:07 AM, Chris McDonough wrote:
 Martin Aspeli wrote:
 Chris McDonough wrote:

 Sorry, the you above in you scolded was Martin Aspeli, not Faassen.
 Note that the scolding had something to do with you breaking Plone
 trunk due to a transitive change in Chameleon, and the realisation that
 from this point on, any package shared between repoze.bfg and Plone (or
 anything else) that is configured with ZCML, will probably need to be
 forked. We found a workaround with Chameleon, but not one that will scale.

 The fix is totally scalable and completely correct.  Chameleon.zpt just does 
 not
 have any (real) ZCML anymore.  Any package that has ZCML is, by definition,
 written for some framework as stuff that is meant to be overridden, otherwise 
 it
 wouldn't be written as configuration.  ZCML is unlike code in this way.  If it
 wasn't meant to be overridden, it would be in code.

 All packages which are meant to be maximally useful outside the scope of that
 framework should be split into two things: the library portion, then some
 portion that contains ZCML for gluing in to some framework that wants ZCML in
 some specific configuration.

When I read Martin's post, I had a similar reaction.  Namely, that the 
convenience of the Uberthing (Plone in this case) will always trump the 
desire of packages trying to survive on their own for new audiences.  At 
the time of the configuration scolding, I remember thinking: there's 
little interest here in Chameleon's goal to be bigger than Zope.  Keep 
things convenient for us in Plone!

Package sharing between repoze.bfg and Plone should not mean that BFG 
gets dragged down, paying for things it specifically doesn't want to 
eat.  BFG never claimed to sign up for Plone's contracts.

I sense the logic of Chris's position: if the Zope Framework is as big 
as every current use case in Zope2+Zope3+Grok+etc., with nine years of 
accumulations on each (3 forms systems in one of them), then we're 
missing the goal (IMO).  We'll make life incrementally better for 
ourselves, but we'll still scare off the folks who aren't after Uberthing.

Plone is going towards a smaller-and-smaller core that is only as big 
as the manpower to do a great job at keeping it stable.  Meaning, very 
small.  Hopefully the Zope Framework is a tiny little thing that pays 
only for what it eats.

Hopefully the goal is to make a very good microframework (or even 
better, set of libraries).  If you can't make the best configuration 
language possible because one line of includes to get trusted adapters 
is an unconscionable burden is the rule, then I know how this movie ends.

--Paul

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Martin Aspeli
Paul Everitt wrote:

 When I read Martin's post, I had a similar reaction.  Namely, that the 
 convenience of the Uberthing (Plone in this case) will always trump the 
 desire of packages trying to survive on their own for new audiences.  At 
 the time of the configuration scolding, I remember thinking: there's 
 little interest here in Chameleon's goal to be bigger than Zope.  Keep 
 things convenient for us in Plone!

In this case, you totally misread my post. It broke for all users of 
zope.component, and I never, once, made the argument that Chameleon was 
part of Plone or should be driven purely by Plone's needs. I have no 
such pretentions, nor does anyone else I know, about this, or zope.* or 
the CMF package or, well, anything that is not expressly part of Plone.

That particular discussion is over, though, and I have no interest in 
having it again.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Paul Everitt
On 3/4/09 8:16 AM, Martin Aspeli wrote:
 Paul Everitt wrote:

 When I read Martin's post, I had a similar reaction.  Namely, that the
 convenience of the Uberthing (Plone in this case) will always trump the
 desire of packages trying to survive on their own for new audiences.  At
 the time of the configuration scolding, I remember thinking: there's
 little interest here in Chameleon's goal to be bigger than Zope.  Keep
 things convenient for us in Plone!

 In this case, you totally misread my post. It broke for all users of
 zope.component, and I never, once, made the argument that Chameleon was
 part of Plone or should be driven purely by Plone's needs. I have no
 such pretentions, nor does anyone else I know, about this, or zope.* or
 the CMF package or, well, anything that is not expressly part of Plone.

Chameleon provided something that made it work for those users, while 
allowing it to not be burdened by those needs.  Everybody wins. 
Hopefully such solutions will be the norm in the future.

 That particular discussion is over, though, and I have no interest in
 having it again.

These two paragraphs seem contradictory. [wink]  We'll consider the 
matter closed.

--Paul

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Kent Tenney
On Thu, Mar 5, 2009 at 3:04 AM, Hermann Himmelbauer du...@qwer.tk wrote:
 Am Mittwoch 04 März 2009 07:52:09 schrieb Chris McDonough:
 Tather than reply in kind here, let me summarize:  I'm glad we agree more
 than we disagree, and I apologize if I've attributed to you beliefs that
 you don't have.  It's heartening to hear that you're in favor of most of
 the things I'm also in favor of.  But we do have real differences in
 opinion I think.  I'd rather be constructive than obstructionist here: at
 the end of each item below I ask for an opinion based on a suggestion.

 1)  I'm not in favor of a single steering group for the *entirety* of all
 Zope software.   We've tried a similar thing in the past (via the
 foundation structure); it didn't work and I'm not sure how we'd expect
 things to turn out any differently this time.  Instead, perhaps the focus
 of groups should be on some much smaller subset of Zope-related software
 (e.g. the
 zope.interface+zope.component group, the zope.schema group, the ZODB group,
 etc).  Could we consider this?

 What I don't see in your proposal is, how these subset-groups would be
 coordinated, which leads to the following:

 - How would these groups be formed? If there's nobody who encourages people to
 do so,

 - Higher level package/groups may have a hard life in case basic
 packages/groups are not coordinated and all go their own way.

 - How does some foreigner know, if a package is actively supported,
 umaintaned, deprecated etc.? How does he know, what packages exist, what they
 are good for and the like? For instance, I yesterday wrote that I use
 lovely.remotetask, then I was asked on the list why I did not use the (maybe
 better) zc.async package. Know why? I did not know that it existed.

 - I think, Zope 3 is not only about some seperate packages, but about a
 complete programming experience. Thus there needs to be some integrating
 force, that draws together all these packages, writes some documentation /
 tutorial / website etc.

 - Newbies won't be attracted by single packages. Instead, they want something
 complete. Who would be interested in Plone if it would consist of various
 packages that people would have to draw together by themselves, without
 decent documentation?

 To my mind, one key point is attracting more users. And that can only be done
 if we try to view things from an external, newbie-perspective. Some Ruby on
 Rails / Java / Turbogears programmer will only be attracted by some big
 picture but probably not by a collection of some subpackages.

 So, my impression is that there is a need for some steering group, that will,
 however, encourage people to form groups around packages and maintain them.

I envision a Council of Elders with student representation.

The Elders either know, or know who knows the history and current
state of affairs,
the students know the struggles of the newbies.

They could provide welcome wagon, triage, and guide service for
navigating the Zope wilds.


 Best Regards,
 Hermann

 --
 herm...@qwer.tk
 GPG key ID: 299893C7 (on keyservers)
 FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
 ___
 Zope-Dev maillist  -  zope-...@zope.org
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Roger Ineichen
Hi Paul

 Betreff: Re: [Zope-dev] the Zope Framework project
 
 On 3/4/09 8:16 AM, Martin Aspeli wrote:

[...]

 Chameleon provided something that made it work for those 
 users, while allowing it to not be burdened by those needs.  
 Everybody wins. 
 Hopefully such solutions will be the norm in the future.
 
  That particular discussion is over, though, and I have no 
 interest in 
  having it again.

I hope not! I don't like to have any code in an application which
I don't use.

But right now I don't see a better solution for the chicken
and egg problem we have with z3c.pt and chameleon support
in our base packages. In older days we used monkey patches
for that problem, but that's no solution anymore.

Regards
Roger Ineichen


 These two paragraphs seem contradictory. [wink]  We'll 
 consider the matter closed.
 
 --Paul
 
 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  ** (Related lists -  
 http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )
 

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Paul Everitt
On 3/4/09 9:47 AM, Roger Ineichen wrote:
 Hi Paul

 Betreff: Re: [Zope-dev] the Zope Framework project

 On 3/4/09 8:16 AM, Martin Aspeli wrote:

 [...]

 Chameleon provided something that made it work for those
 users, while allowing it to not be burdened by those needs.
 Everybody wins.
 Hopefully such solutions will be the norm in the future.

 That particular discussion is over, though, and I have no
 interest in
 having it again.

 I hope not! I don't like to have any code in an application which
 I don't use.

 But right now I don't see a better solution for the chicken
 and egg problem we have with z3c.pt and chameleon support
 in our base packages. In older days we used monkey patches
 for that problem, but that's no solution anymore.

I agree, and I think this case is a good exemplar for the challenge.

Chameleon wanted to make a good templating engine that was independent 
of megaframeworks.  For that, it needed/wanted a configuration language 
that met your statement I don't like to have any code...I don't use.

But legacy in one of the projects changed this from a self-contained, 1x 
amount of work into a cobweb of bigger issues, control in the hands of 
others, and 10x the work.  Human nature says that's demoralizing.

Hopefully the Zope Framework proposal helps untangle this, and gets to a 
point where you don't have to keep the Uberthing in your head when doing 
something small.

--Paul

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Martijn Faassen
Gary Poster wrote:
 On Mar 3, 2009, at 12:31 PM, Martijn Faassen wrote:
 
 Hey Gary,

 [panarchist approach where we have people starting groups that could
 compete for attention]
 
 [Had to look up panarchist, but yes, essentially.]

I shouldn't have used that word, I actually didn't realize anyone else 
had made it up beyond me but it seems to have a century + history. :)

[snip]
 I think your statements and mine mesh well enough.  If you don't  
 agree, that's fine.  Practically, it means I support what you are  
 trying to do (and in fact I would tend towards your camp in my  
 proposed panarchy), if from a slightly different perspective.

Sure, they mesh well enough. I'm just pointing out that freely competing 
projects only work to a certain extent; as soon as there's code or 
community resources shared between them there are going to be points of 
conflicts of interests that need to be resolved somehow. I think often 
this can be resolved to the satisfaction of everybody, but I do think we 
need a structure in which things can be resolved. Freely competing 
structures might equal no structure, and that's something to watch out for.

 I'm glad you sent your proposal email first.  Now that you have, I  
 hope you pursue your vision without needing 100% buy-in from the  
 community.  I'm optimistic that you will. :-)

I'm a stubborn fool with no idea of what I seem to be signing up for, so 
I guess I might. :)

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Martijn Faassen
Hi there,

Hanno Schlichting wrote:
[snip]
 You can try to bake more leadership of the overall Zope community into
 this, but I think this is a fruitless fight right now. Reduce the scope,
 try make some things better and don't step on other peoples feet if you
 don't need to. For example don't try to push out style-guides for the
 entirety of the svn.zope.org repository. They lead to bike-shed
 discussions and discourage contributions.

Yes, I agree with restricting scope. I wanted to restrict scope to a set 
of libraries that's shared between a bunch of the big consumer projects, 
and that I called the Zope Framework. It's not something you install 
by itself, and it's not something that everybody uses every bit of. But 
it is something that is shared by a lot of people and we need to take 
responsibility for and manage as a whole, not just as a whole bunch of 
parts.

Beyond that in our repository, the framework steering group would have 
influence but no authority. The document reflects that thinking.

Repository-wide guidelines do exist, such as the copyright assignment 
policy, and the general 'trunk'/'branches'/'tags' structure of projects, 
and the way people name distributions of packages the same name as the 
package name ('zope.foo' is released as 'zope.foo'), and I'm sure we can 
come up with many more of such conventions. It's not something for the 
Zope Framework group to care about though. Part of that will just happen 
by consensus and example anyway, but outside of the realm of the Zope 
Framework Steering Group.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Martijn Faassen
Hey there,

Chris McDonough wrote:

 1)  I'm not in favor of a single steering group for the *entirety* of all Zope
 software.   We've tried a similar thing in the past (via the foundation
 structure); it didn't work and I'm not sure how we'd expect things to turn out
 any differently this time.  Instead, perhaps the focus of groups should be on
 some much smaller subset of Zope-related software (e.g. the
 zope.interface+zope.component group, the zope.schema group, the ZODB group,
 etc).  Could we consider this?

I don't recall we actually did anything within the Foundation structure. 
The structure was there in the bylaws but was never applied, so I don't 
think that can be qualified as a failure. :)

The steering group isn't intended to take a responsibility for the 
entirety of the Zope software. Zope 2, Grok and the Zope 3 app server 
(which would be a distinct entity) would manage themselves and the Zope 
Framework steering group would not have a say over the libraries and 
configuration they add.

I do think the steering group should start worrying about a larger 
amount of the libraries rather than a small set. Part of the reason is 
exactly so we *can* identify subsets and properly delegate their 
management. Delegating their management will require some kind of 
agreement on groups coordinating however. We need to have an overview of 
the whole in order to know how to evolve the parts in many cases. For 
instance, if we move some class due to a dependency cleanup, we need to 
have an effort to update the libraries in the whole to use the new 
imports relations.

I do also think that we should go to a smaller set of libraries. We 
currently share a huge amount of code that only one consumer actually 
uses. For instance, I think all of the zope.app.* packages which contain 
ZMI code can eventually be left to the management of the Zope 3 
developers, meaning they'd not be part of the Zope Framework anymore.

The ZODB is a good example where I'm not sure whether the ZODB should be 
considered part of the Zope Framework at all. I think we should see this 
as an external library that the framework builds on.

The idea that there is a bunch of people who take the responsibility for 
managing the whole doesn't mean they should be obstructing moves to 
improve the parts. Similarly I assume you're taking some form of 
responsibility for Repoze and that this is helpful the evolution of 
the parts of it.

My hope is that we'll see more of a catalyst function than anything 
else. I think the answer to proposed changes in the lower layers (which 
is always risky) should be to point out potential risks and say: we can 
make this change, but we also need to make sure we do X. The answer 
should typically not be no. If it is a no, we should actively try to 
identify the use cases driving the proposed change and look for 
alternative solutions.

 2) I'm also not in favor of a giant lockstep set of software versions shared
 between notional releases Zope 3.5, Grok, and Zope 2.12.  I can only see this 
 as
 continuing our mistakes of old by trying to treat some collection of software 
 as
 Zope as opposed to letting parts of it survive or die on their own based on
 merit; it'd be more effective to just let each framework use (or disuse!)
 whatever versions of stuff that work best for it.  That's why the software is
 broken out into individual components in the first place; we should encourage
 diversity in component usage.  Instead of trying to legislate and bless some 
 set
 of components as a version, we should just work to make each piece better 
 and
 worthwhile to use independently; it's value would be in its actual usefulness
 rather than some belief that it works well with the other components in the
 version.  

I don't understand why you think a list of versions that has release 
numbers that we know works together is a blocker for independent 
evolution for the individual libraries.

I think there are two parallel efforts:

* evolving libraries standalone. We should improve those libraries so we 
can think about them standalone. If a library contains ZMI code, it's 
harder to think about it standalone for instance.

* making sure that there is a list of library versions that people can 
install that isn't broken. That is, run the tests for these libraries in 
isolation and together. If a decision was made to change one library, 
make sure that all the other libraries in the list are updated so they 
actually still work.

I see both efforts as necessary. If you just care about a smaller list 
of libraries, you don't have to worry about a larger list of course, 
though you will have to coordinate with some people who do. You probably 
can do quite well constructing your own list as it's a much smaller one. 
That's fine, and nothing should stop you. But the reality is that many 
people in this group *do* care about a larger list of libraries.

 Could we at least agree that lockstep versioning of a huge set of

Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Martijn Faassen
Hi there,

Andreas Jung wrote:
[snip]
 This would definitely make sense to me. With respect to a steering
 committee: I am also a bit skeptical about such a committee. I think
 that the upcoming ZF board will have a good representation of each Zope
 project on the board in order to address things on the board level.

You haven't read my document very well if you think I'm proposing a 
Steering Group for all Zope projects.

I don't agree the Zope Foundation board should directly steer 
development of the Zope software.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Stephan Richter
On Wednesday 04 March 2009, Martijn Faassen wrote:
 I don't agree the Zope Foundation board should directly steer
 development of the Zope software.

I totally agree.

Regards,
Stephan
-- 
Stephan Richter
Web Software Design, Development and Training
Google me. Zope Stephan Richter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Martijn Faassen
Chris McDonough wrote:
[snip]
 This just seems like a blindingly obvious antigoal to actually breaking apart
 the software into more discrete bits using eggs.  Why not just stick with a 
 huge
 tarball release or one single egg if it all has to be versioned through time 
 to
 99% of its consumers as one giant collection of software treated as a unit?

Why not:

* Repoze and others couldn't use the bits they care about.

* Grok (or anything else) couldn't diverge from a common KGS when it 
needs to.

* individual apps couldn't diverge from a common KGS when *they* need to.

* A clear set of explicit, layered dependencies in software is generally 
a good thing. We can start thinking about smaller pieces better. By 
splitting up into individually packaged and released bits, we are forced 
to think about these things more.

I don't see this as at all incompatible with a group managing a list of 
versions that is known to work together, as a service to various groups 
which do need such lists anyway.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Martijn Faassen
Hi there,

Lennart Regebro wrote:
[snip]
 And it is in any case in no way even remotely connected to the group
 Martijn proposed and has been discussed in this thread.

Of course it is connected. The Zope Framework needs leadership that can 
help:

- bless efforts by individuals and subgroups that want to take care of 
particular areas.

- help with the coordination between individuals and groups that want to 
make changes. The Steering Group will need to keep an overview of what 
is going on so they can help point out points where coordination is 
necessary.

- mark status (deprecation ,etc) of particular packages that are part of 
the Zope Framework. Note that the Zope Steering group is not about 
packages that are not in the framework, so if lovely.remotetask isn't 
there, it can say little. The idea is to limit the things that Zope 
Framework is about so we can take better care of it. Hopefully it can 
provide the infrastructure and encouragement so that others will do this 
work however. How this will turn out is a bit of a gray area.

- Individual systems such as Grok, Zope 3, Zope 2 and repoze.bfg each 
provide their own complete programming experience. The Zope Framework 
is at best only part of this experience, but it *is* a part of the 
experience. We could for instance provide a website with documentation 
about framework packages that individual projects could refer to.

- Attracting newbies to web development is not a task of the Zope 
Framework project directly, and here I diverge from Hermann. That's a 
task of the Plone project or the Grok project, etc. I do think that the 
Zope Framework leadership could be much better at attracting and 
stimulating contributions to the libraries.

Attracting more users is important, but that's a task for the Zope 3 app 
server developers (however they organize) or the Grok project. The Zope 
Framework is a second-level provider to these projects, and in reality 
of course people who care about these projects will do most of the 
driving of development of the Zope Framework. It's a forum where all 
users of these libraries (many or just a few) can get together, work out 
our diverse interests, and coordinate.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Martijn Faassen
Baiju M wrote:
 On Wed, Mar 4, 2009 at 2:34 PM, Hermann Himmelbauer du...@qwer.tk wrote:
 [snip]
 - I think, Zope 3 is not only about some seperate packages, but about a
 complete programming experience. Thus there needs to be some integrating
 force, that draws together all these packages, writes some documentation /
 tutorial / website etc.
 
 +1
 
 I believe packages developed as part of the Zope 3 project is
 here to stay for a long time (of course, after dependency cleanup
 some of them may become obsolete). This will happen even if some
 of the frameworks based on it are no more available.

I'm fine if some people want to get together and organize Zope 3 to 
offer an integrated experience. Zope 3 is the thing people install and 
start projects with. It's what should have a website explaining what it 
is all about.

It's not what the Zope Framework Steering Group cares for however. It 
doesn't directly care for Zope 3. Zope 3 is explictly *not* the Zope 
Framework project, just like Grok isn't the Zope Framework project. Both
have a stake in the project and will participate in the project, but 
just like the Zope Framework Steering Group doesn't manage 
grok.zope.org, it won't manage zope3.zope.org (if such a thing exists) 
either.

While I'm quite interested in volunteering to help coordinate Zope 
Framework development, I'm not at all interested in volunteering to help 
coordinate Zope 3 app server development.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Andreas Jung
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04.03.2009 17:26 Uhr, Martijn Faassen wrote:
 Hi there,
 
 Andreas Jung wrote:
 [snip]
 This would definitely make sense to me. With respect to a steering
 committee: I am also a bit skeptical about such a committee. I think
 that the upcoming ZF board will have a good representation of each Zope
 project on the board in order to address things on the board level.
 
 You haven't read my document very well if you think I'm proposing a 
 Steering Group for all Zope projects

I wasn't proposing that. I wanted to point out that the persons on the
board could work out on proposal or on some agreement how to approach
the controversial points...basically to layout a consensus plan. This
not about steering the development but about finding some overall consensus.

Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkmuszUACgkQCJIWIbr9KYwcbgCglkri5JcNPKHAQu/pWGcYWgUM
WNIAoKQXa0HW404juEf/6zDo1ENdnjhU
=h1TJ
-END PGP SIGNATURE-
begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX Ltd.  Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany
email;internet:i...@zopyx.com
title:CEO
tel;work:+49-7071-793376
tel;fax:+49-7071-7936840
tel;home:+49-7071-793257
x-mozilla-html:FALSE
url:www.zopyx.com
version:2.1
end:vcard

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Lennart Regebro
On Wed, Mar 4, 2009 at 17:48, Martijn Faassen faas...@startifact.com wrote:
 Note that the Zope Steering group is not about
 packages that are not in the framework, so if lovely.remotetask isn't
 there, it can say little.

Which is exactly my point. It surely isn't at the moment, and I don't
see that it should be any time soon. What Hermann suggested is
somebody that keeps track of all Zope software modules and tells him
which is good and which is bad. That's not what you suggested, and as
mention, I don't think it's even possible, and definitely not a good
idea.

-- 
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Martijn Faassen
Hi there,

Paul Everitt wrote:
[snip]
 Hopefully the Zope Framework proposal helps untangle this, and gets to a 
 point where you don't have to keep the Uberthing in your head when doing 
 something small.

It's not small, as it has an impact on a lot of things that build on 
zope.component. Changing things low in something that lots of people 
have built stacks on is almost never a small change.

Just look at Python 3, which makes a bunch of actually rather small but 
still incompatible changes to the language. While small from the 
perspective of the language, they're *huge* from the perspective of the 
users.

So you need ways to coordinate such changes.

I hope that having someone actually taking responsibility for 
zope.component's evolution can get the zope.security dependency out of 
it, and then improvements of repoze.zcml into it, or alternatively move 
the ZCML implementations *entirely* out of zope.component. I hope Chris 
will coordinate with us where necessary.

I don't want security bits to sit around in zope.component either. 
grokcore.component doesn't need that code, just like repoze.zcml doesn't 
need that code. It's still there, even if you use repoze.zcml, just 
inactive. I tried to propose various ways forward. I got nowhere as I 
got 10 people giving 10 answers. Original problem unresolved.

I'd like there to be someone who can make this decision and I'd like 
this someone to usually make *positive* decisions that work towards 
resolving the underlying issue, while coordinating with everybody that 
is impacted by this decision.

The zope.component ZCML case was very much in my head as I wrote this 
proposal.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Lennart Regebro
On Wed, Mar 4, 2009 at 18:03, Martijn Faassen faas...@startifact.com wrote:
 I'd like there to be someone who can make this decision and I'd like
 this someone to usually make *positive* decisions that work towards
 resolving the underlying issue, while coordinating with everybody that
 is impacted by this decision.

But we know pretty much who is impacted by this, and the people with
enough gravitas to be able to say Yay or Nay to these sorts of
refactoring. And they are all on this list. And if there was a
Steering Group, most of them would need to be on that group.

If it's impossible for these people to agree when discussing on this
mailing list today, why would the suddenly agree on this mailing list
if we call them The Zope Framework Steering Group? I really don't
understand that.

I think it is WAY more likely that we get agreement and come forward
if we first of all stop having the internet between us. We all know
how easy it is to misunderstand intentions and tone of voices on
mailing lists as compared to real life.

And if it *still* is impossible for these people to agree, then I
can't see the Steering Group working either, and then we need a new
dictator. But I don't think that's needed, because the technical
disagreements we have here are so minor, and seems mostly based in
massinderstindung.

-- 
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Martijn Faassen
Andreas Jung wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 On 04.03.2009 17:26 Uhr, Martijn Faassen wrote:
 Hi there,

 Andreas Jung wrote:
 [snip]
 This would definitely make sense to me. With respect to a steering
 committee: I am also a bit skeptical about such a committee. I think
 that the upcoming ZF board will have a good representation of each Zope
 project on the board in order to address things on the board level.
 You haven't read my document very well if you think I'm proposing a 
 Steering Group for all Zope projects
 
 I wasn't proposing that. I wanted to point out that the persons on the
 board could work out on proposal or on some agreement how to approach
 the controversial points...basically to layout a consensus plan. This
 not about steering the development but about finding some overall consensus.

If you're talking about consensus about code, that's really not my 
vision of what the Zope Foundation board is for. I do think the Zope 
Foundation board might do something about community organization.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Chris McDonough
Martijn Faassen wrote:
snip

 * A clear set of explicit, layered dependencies in software is generally 
 a good thing. We can start thinking about smaller pieces better. By 
 splitting up into individually packaged and released bits, we are forced 
 to think about these things more.

(I'm running out of steam on responses here.  This will likely be one of the 
last).

You've been saying this: we'll just identitfy and maintain this giant set of
versions for backwards compatibility purposes and for purposes of *moving
platforms forward through time*.  But you also seem to be saying  *real soon
now* we'll also be making hard choices about the life and death of things that
make up the 'framework' and evaluating each on its merit as an idependent
entity.  Personally, I disbelieve that this real soon now will ever happen
without having it as the *primary* and maybe the *only* goal.

I believe to get success here (measured as gaining new Python developer users),
our path forward needs to be way, way, way more radical and needs to involve
making hard choices that treat individual packages on their own merit rather
than even considering their role as part of a larger collection.  That's the
bottom line and I believe it's our fundamental point of disagreement.  IMO, the
part a package plays as part of the larger collection should be utterly and
brutally subservient to its merit as a standalone package.  Also IMO, if there
were absolutely no list of versions known to work together, but each piece
worked on its own and had merit on its own, we'd be in a far better place as far
as attracting new users.  Any list of packages-known-to-work-together should be
a oh, by the way, this might be handy, not the raison d'etre of the group and
this discussion.

 I don't see this as at all incompatible with a group managing a list of 
 versions that is known to work together, as a service to various groups 
 which do need such lists anyway.

Maybe not.  But as far as I can tell, maintaining such a list is just business
as usual and doesn't require any proposal at all.

- C

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Martijn Faassen
Lennart Regebro wrote:
 On Wed, Mar 4, 2009 at 17:48, Martijn Faassen faas...@startifact.com wrote:
 Note that the Zope Steering group is not about
 packages that are not in the framework, so if lovely.remotetask isn't
 there, it can say little.
 
 Which is exactly my point. It surely isn't at the moment, and I don't
 see that it should be any time soon. What Hermann suggested is
 somebody that keeps track of all Zope software modules and tells him
 which is good and which is bad. That's not what you suggested, and as
 mention, I don't think it's even possible, and definitely not a good
 idea.

I think it would be possible to provide an infrastructure so that people 
who care about communicating certain bits of information (this package 
exists and here is its documentation, this package is really not 
maintained and therefore deprecated) could do so.

Perhaps this infrastructure will be developed as a side-effect of what 
needs to be done for those libraries in the Zope Framework anyway.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Martijn Faassen
Lennart Regebro wrote:
 On Wed, Mar 4, 2009 at 18:03, Martijn Faassen faas...@startifact.com wrote:
 I'd like there to be someone who can make this decision and I'd like
 this someone to usually make *positive* decisions that work towards
 resolving the underlying issue, while coordinating with everybody that
 is impacted by this decision.
 
 But we know pretty much who is impacted by this, and the people with
 enough gravitas to be able to say Yay or Nay to these sorts of
 refactoring. And they are all on this list. And if there was a
 Steering Group, most of them would need to be on that group.
 
 If it's impossible for these people to agree when discussing on this
 mailing list today, why would the suddenly agree on this mailing list
 if we call them The Zope Framework Steering Group? I really don't
 understand that.

Two answers:

* they wouldn't all be on the steering group

* the steering group is *tasked* with coming to a single answer that is 
recorded.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Baiju M
On Wed, Mar 4, 2009 at 9:55 PM, Martijn Faassen faas...@startifact.com wrote:

[snip]

 The steering group isn't intended to take a responsibility for the
 entirety of the Zope software. Zope 2, Grok and the Zope 3 app server
 (which would be a distinct entity) would manage themselves and the Zope
 Framework steering group would not have a say over the libraries and
 configuration they add.

[snip]

 I do also think that we should go to a smaller set of libraries. We
 currently share a huge amount of code that only one consumer actually
 uses. For instance, I think all of the zope.app.* packages which contain
 ZMI code can eventually be left to the management of the Zope 3
 developers, meaning they'd not be part of the Zope Framework anymore.

[snip]

 
 As a service to the users of the Zope Framework, the Zope developers
 also make available lists of version numbers of core libraries that
 have been tested to work together as a Known Good Set. This receives
 a version number and is the Zope Framework release.  Users of the Zope
 framework can use this list, but may also diverge from it where they
 see fit. Other projects (such as the Zope 3 application server and the
 Grok project) also have a Known Good Sets that expand on the Zope
 framework list (and may diverge from it). Each of these consumer
 projects can of course have their own release process, schedule and
 version numbering.
 

[snip]

 It may very well be true that in some time we'll develop clusters of
 libraries that can be more or less managed on their own. The ZMI is such
 a cluster that I hope will eventually emerge (and that the Zope
 Framework Steering Group doesn't care about directly). That'd reduce the
 coordination overhead. But sometimes we do need to take coordinated
 action, and I don't see that need disappearing entirely.

I think those who care about Zope 3 (framework/app server/libraries/
or whatever)
should form a team and mailing list to discuss about the future development.
All other major consumers of the Zope Framework Project has their on mailing
list for discussions.  I guess very soon zope-dev list will become
inappropriate to discuss about Zope 3.  Just like Grok,Repoze etc.
it is better
to create a list for Zope 3, may be re-activate zope3-dev list to
discuss about
the Zope 3 (framework/app server/libraries/ or whatever). Well, if
no one cares
about Zope 3, let's leave it.

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Martijn Faassen
Hi there,

On Wed, Mar 4, 2009 at 6:26 PM, Chris McDonough chr...@plope.com wrote:
 Martijn Faassen wrote:
 snip

 * A clear set of explicit, layered dependencies in software is generally
 a good thing. We can start thinking about smaller pieces better. By
 splitting up into individually packaged and released bits, we are forced
 to think about these things more.

 (I'm running out of steam on responses here.  This will likely be one of the 
 last).

 You've been saying this: we'll just identitfy and maintain this giant set of
 versions for backwards compatibility purposes and for purposes of *moving
 platforms forward through time*.  But you also seem to be saying  *real soon
 now* we'll also be making hard choices about the life and death of things that
 make up the 'framework' and evaluating each on its merit as an idependent
 entity.  Personally, I disbelieve that this real soon now will ever happen
 without having it as the *primary* and maybe the *only* goal.

It can't be the only goal, we also want to build new stuff, right?
Anyway, cleaning this stuff up is one of my most important goals for
me personally; I and 5 others spent a week of our life doing that a
month ago.

Real soon now, zope.app.container and zope.app.folder and
zope.app.keyreference and zope.app.catalog are not going to be the
business of the Zope Framework developers anymore. They contain ZMI
stuff the Zope Framework developers do not care about directly and
will only care about indirectly if enough people speak up for it and
are willing to work on it. I hope many of them join the real soon now.
We have a line behind which I, and many others, don't have to care
anymore. A receding line, leaving many things behind.

I don't want to stop anyone else from caring about these other things.
I can't anyway. If people do get together who want to develop Zope 3
the app server they should get together and organize. I hope I can
convince them that this line is important and I hope I can convince
people in general to care *more* about the stuff in the Zope Framework
than anything else. The ZMI isn't the main thrust of Zope 3
development, and hasn't been for a long time anyway. I want to stop
having to worry about it as soon as possible, and am willing to do
work to get there.

 I believe to get success here (measured as gaining new Python developer 
 users),

I think success is not just python developer users, but also serving
current users in the Zope 2, Zope 3 and Grok worlds better by having a
more comprehensible platform.

 our path forward needs to be way, way, way more radical and needs to involve
 making hard choices that treat individual packages on their own merit rather
 than even considering their role as part of a larger collection.  That's the
 bottom line and I believe it's our fundamental point of disagreement. IMO, the
 part a package plays as part of the larger collection should be utterly and
 brutally subservient to its merit as a standalone package.

Look, I know you are not using the packages the way that I am, but
can't we work together? I want these packages to make sense
stand-alone very much, but I also need to consider them as part of a
whole that needs to be managed.

 Also IMO, if there
 were absolutely no list of versions known to work together, but each piece
 worked on its own and had merit on its own, we'd be in a far better place as 
 far
 as attracting new users.  Any list of packages-known-to-work-together should 
 be
 a oh, by the way, this might be handy, not the raison d'etre of the group 
 and
 this discussion.

I think the group needs to have a list of packages it cares about, so
we know what we're talking about. That way we know which packages we
need to document and present and clean up, and we know *what* code we
want to move out of packages that are in that list. And none of these
packages can be broken so they *need* to work together! And we also
present a list of versions that we have tested together as a service
to the people who need such lists.

If we *don't* make such a list we'll remain in the limbo where *all*
packages are of some nebulous importance.

 I don't see this as at all incompatible with a group managing a list of
 versions that is known to work together, as a service to various groups
 which do need such lists anyway.

 Maybe not.  But as far as I can tell, maintaining such a list is just business
 as usual and doesn't require any proposal at all.

We're maintaining a different list now, for the Zope 3 app server that
you install. What's in the list is mainly just inertia and ad-hoc
decision making. That's not the list I'm talking about, though
there'll be tremendous overlap to start with. I'm proposing not just a
different list but a community that cares about those libraries.

Regards,

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

Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Chris Withers
Chris McDonough wrote:
 I believe to get success here (measured as gaining new Python developer 
 users),
 our path forward needs to be way, way, way more radical and needs to involve
 making hard choices that treat individual packages on their own merit rather
 than even considering their role as part of a larger collection.  That's the
 bottom line and I believe it's our fundamental point of disagreement.  IMO, 
 the
 part a package plays as part of the larger collection should be utterly and
 brutally subservient to its merit as a standalone package.  Also IMO, if there
 were absolutely no list of versions known to work together, but each piece
 worked on its own and had merit on its own, we'd be in a far better place as 
 far
 as attracting new users.  Any list of packages-known-to-work-together should 
 be
 a oh, by the way, this might be handy, not the raison d'etre of the group 
 and
 this discussion.

+ lots

Chris

-- 
Simplistix - Content Management, Zope  Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Baiju M
On Wed, Mar 4, 2009 at 11:38 PM, Martijn Faassen faas...@startifact.com wrote:
 Real soon now, zope.app.container and zope.app.folder and
 zope.app.keyreference and zope.app.catalog are not going to be the
 business of the Zope Framework developers anymore. They contain ZMI
 stuff the Zope Framework developers do not care about directly and
 will only care about indirectly if enough people speak up for it and
 are willing to work on it. I hope many of them join the real soon now.
 We have a line behind which I, and many others, don't have to care
 anymore. A receding line, leaving many things behind.

 I don't want to stop anyone else from caring about these other things.
 I can't anyway. If people do get together who want to develop Zope 3
 the app server they should get together and organize. I hope I can
 convince them that this line is important and I hope I can convince
 people in general to care *more* about the stuff in the Zope Framework
 than anything else. The ZMI isn't the main thrust of Zope 3
 development, and hasn't been for a long time anyway. I want to stop
 having to worry about it as soon as possible, and am willing to do
 work to get there.

+1 for organizing a Zope 3 team, may be we should re-activate
zope3-dev list?  Well, ripping out ZMI and other things can be
discussed there.  I think Zope 3 should bring many packages
in 'z3c' namespace into core Zope 3 (no need to change namespace)
Documenting how Zope 3 packages can be used together to build
application is also very important.

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Lennart Regebro
On Wed, Mar 4, 2009 at 18:27, Martijn Faassen faas...@startifact.com wrote:
 If it's impossible for these people to agree when discussing on this
 mailing list today, why would the suddenly agree on this mailing list
 if we call them The Zope Framework Steering Group? I really don't
 understand that.

 Two answers:

 * they wouldn't all be on the steering group

Why not? They are the people who should have a say, and they are the
people most likely to be able to actually implement the decisions.

 * the steering group is *tasked* with coming to a single answer that is
 recorded.

And implement it?

-- 
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Martijn Faassen
Hey everybody,

This thread is now closed, thanks everybody for your contributions!

See my unilateral announcement about the formation of the Steering Group 
and Zope Framework. It do its best to try to balance the concerns in 
this thread.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martijn Faassen wrote:
 Hi there,
 
 Paul Everitt wrote:
 [snip]
 Hopefully the Zope Framework proposal helps untangle this, and gets to a 
 point where you don't have to keep the Uberthing in your head when doing 
 something small.
 
 It's not small, as it has an impact on a lot of things that build on 
 zope.component. Changing things low in something that lots of people 
 have built stacks on is almost never a small change.
 
 Just look at Python 3, which makes a bunch of actually rather small but 
 still incompatible changes to the language. While small from the 
 perspective of the language, they're *huge* from the perspective of the 
 users.
 
 So you need ways to coordinate such changes.
 
 I hope that having someone actually taking responsibility for 
 zope.component's evolution can get the zope.security dependency out of 
 it, and then improvements of repoze.zcml into it, or alternatively move 
 the ZCML implementations *entirely* out of zope.component. I hope Chris 
 will coordinate with us where necessary.
 
 I don't want security bits to sit around in zope.component either. 
 grokcore.component doesn't need that code, just like repoze.zcml doesn't 
 need that code. It's still there, even if you use repoze.zcml, just 
 inactive. I tried to propose various ways forward. I got nowhere as I 
 got 10 people giving 10 answers. Original problem unresolved.
 
 I'd like there to be someone who can make this decision and I'd like 
 this someone to usually make *positive* decisions that work towards 
 resolving the underlying issue, while coordinating with everybody that 
 is impacted by this decision.
 
 The zope.component ZCML case was very much in my head as I wrote this 
 proposal.

OK, can we table the proposal per se for the moment, and prototype the
process around the how do we move zope.component forward question?
I'm not even sure I understand why you think anything in repoze.zcml has
squat to do with zope.component, but I could just be missing the obvious.

I have a strawman proposal, focused on stripping zope.component down
as far as possible:

1. Merge my branch which drops the deferred import stuff.

2. Move the persistent registry stuff out into another package,
   including whatever support is needed to allow for people to migrate
   existing persistent references.  Effectively, this moves one extra
   out to a package, *including* its testing dependencies.

3. Move the ZCML directive implementations out into another package,
   taking the zope.security and zope.configuration dependencies along
   with them.

4. Rework zope.hookable to use a pure-Python implementation via
   descriptors, instead of the C extension.  Make it a non-optional
   dependency (but small and lightweight) of zope.component.  If
   *current* profiling shows that the hooked things are bottlenecks,
   make the C version and optional replacement for the Python version.

At the end, we would have three packages:

  zope.component
depends on:
- zope.interface
- zope.event
- zope.hookable

  zope.componentzcml (BIKESHED NAMING ALERT)
depends on:
- zope.configuration
- zope.security
- zope.configuration
- zope.proxy
- zope.i18nmessageid

  zope.persistentregistry (BIKESHED NAMING ALERT)
depends on:
- zope.configuration
- ZODB3

Folks could then work on refactoring the new packages (e.g., depending
on a separate 'persistent' package, making the secuirity bits optional,
etc.).


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJrv9u+gerLs4ltQ4RApPjAJ4nZKFNxrrpiQfXgR8YRxtgn4YMSQCgk4wx
TnvvQUfwhVo2X64YAyPAdm0=
=KDnz
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-04 Thread Martijn Faassen
Hey Tres,

Could you repost this to a new thread as I think people aren't paying 
attention to this thread very much anymore? I'd very much like to make 
progress on actual cleanups now.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Christian Theune
Hi,

On Tue, 2009-03-03 at 08:52 +0100, Lennart Regebro wrote:
 On Tue, Mar 3, 2009 at 08:42, Christian Theune c...@gocept.com wrote:
  On Tue, 2009-03-03 at 08:35 +0100, Lennart Regebro wrote:
  1. Areas that need somebody responsible should get one. We need
  somebody to bug people about bugs in the bug tracker. That should be
  one person, for example. Responsibilities need to be well defined and
  individual. There isn't anybody called Someone here, so if Someone has
  to do it, that doesn't get done.
 
  That's a valid point. However, the steering group was thought of with
  having fail over in mind so that few people would know about the tasks
  at hand and can jump in for each other (in a coordinated fashion).
 
 Sure. But what happens in those cases is that everybody sits around
 waiting for the steering group to do it, so it stops acting as a
 failover, and gets swamped.
 
  However, the group should be able to make a better job at keeping things
  in flow and focused.
 
 Well, maybe it should. I don't think it would. Groups generally don't.

For some reason the argument evades me: People randomly doing stuff will
end in good things. People (trying) to thoughtfully organize won't.

  As much as I prefer discussing with people in real life, there is the
  notion of no backroom conversations WRT to driving development of an
  open source project.
 
 OK. *Cough*. You and Martijn wrote this proposal. And you asked
 Stephan about it. You did backroom conversations. No, you did not do
 anything wrong. You did everything completely correct. But forget not
 having backroom conversations. That will and must happen. It is
 backroom *decisions* that is the problem. When a group will come out
 with a decision they made by themselves. This *will* happen when you
 have a dedicated group of people making decision. The only way to
 avoid that is to not have a steering group, but somehow have everybody
 involved in a decision. And that is as noted not always practical
 either.

I do see the contradiction in this. ;)

But as Martijn pointed out for his doing with grok: it's thought of as a
hack.

We've done this backroom discussion because we felt that zope-dev won't
be able to drive a fruitful discussion without preparing as much.
However, I'd like that to not be the default or the desired state of
things.

  Having major issues resolved in RL meetings will exclude all those whose
  schedules don't match and those who can't afford to travel to Far Far
  Away.
 
 Aren't we now saying that to avoid excluding some people, we should
 exclude all but a steering group? :-)

No. The steering group should not have backroom discussions. They should
act as open as possible. I think of it as a catalyst.

Christian

-- 
Christian Theune · c...@gocept.com
gocept gmbh  co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1
Zope and Plone consulting and development


signature.asc
Description: This is a digitally signed message part
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martin Aspeli
Lennart Regebro wrote:

 I'm talking about a group of people who act as if they're responsible,
 not your mythical committee. We should be able to find a bunch of people
 with a sense of responsibility, right?
 
 Yes. But I don't think making them a steering group is going to help.

Just to take some experience from Plone again: sometimes it's *very* 
useful to have someone (be that one or more persons) with some 
legitimacy and responsibility, for two reasons:

  - it makes other people sit up and listen
  - it nudges those people into performing a role that may not otherwise 
have

So, in Plone, we have a few loci of legitimacy:

  - The founders, Alex and (now to a lesser extent involved) Alan, who 
get it through respect and historical position

  - The Plone Foundation Board, who have a proper voting structure and 
deals with non-code/functionality matters.

  - The release manager, who is elected, confirmed by the board, and 
paid (a tiny bit) for his duties

  - The framework team, who are lieutenants and advisers to the release 
manager

Sometimes, those people can step in and say enough is enough in a 
discussion. Sometimes they can take the lead and summarise a particular 
debate, or try to nudge people into being more constructive. Sometimes, 
they will cast the deciding vote if the community is split in its 
opinion. Sometimes they will be careful to ensure that decisions are 
recorded and disseminated through documentation, mailing lists and blogs.

This role is very important, and I think it's lacking in the Zope 
community. How many discussions have there been recently that just died 
under the sheer weight of the number of lengthy and opinionated replies 
there were? How many times have we gotten bogged down in semantics or 
naming discussions and killed off the momentum behind something?

I'd argue that the reason this happens is not (just) that we're a bunch 
of opinionated people. It happens because no-one, save perhaps Jim, who 
is largely silent in these debates, has the legitimacy to make any kind 
of decision or prod people to move along. And even if someone does have 
that legicimacy, they don't *feel* that they do (or think that others 
feel that they do) and so they don't exercise it.

We're not talking about dictatorship here, nor are we talking about 
anyone going off and making a whole bunch of decisions that others have 
to blindly follow. Open source doesn't work like that. But there are 
ways to provide some guidance:

  - Elect rather than appoint, so that the people being led feel that 
they have a stake in the decisions made.

  - Elect the right types of people. Thankfully, we have many capable 
and pragmatic people to choose from.

  - Create a process for self-perpetuation of the group that means 
responsibility rotates. This is a good way to get people more involved 
in a project as well as a way to share the burden when there's a lot of 
work.

  - Be transparent and document the discussions that take place, to 
avoid conspiracy theories.

Again, looking at Plone, the framework team has worked out pretty well. 
If anything, we started out with too little process and found there were 
gaps we had to plug. It's not overly process-heavy, though, nor does 
anyone have any illusion that a team that is focused on achieving a 
particular task (roughly, getting a good release out the door without 
compromising the future of the stack) for a particular period of time 
(one major release) is going to be able to boss anybody around. But 
having *some* process and *some* structure is incredibly useful, if only 
because it makes things a bit more predictable and easier to fit oneself 
into.

I'm sure that if you asked an outsider how they could contribute 
meaningfully to the architectural direction of Zope, they wouldn't have 
a clue, because it's all ephemeral, undocumented and dynamic. We rely on 
a lot of unwritten rules. If you asked them the same question about 
Plone, they would at least have some ideas, because there's some 
structure there to be understood and taken advantage of.

This type of thing is pretty well researched in the social science of 
organisations and groups. It's also pretty common in other open source 
projects that have reached a certain size or age, including Plone.

I think Martijn is trying to address something that Zope has lacked for 
a while. I don't think it'll solve all of the world's problems, nor do I 
think that Martijn things so, but it will make some things - things like 
this very debate - a bit easier and more productive.

Martin
-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

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

Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Lennart Regebro
On Tue, Mar 3, 2009 at 09:13, Christian Theune c...@gocept.com wrote:
 For some reason the argument evades me: People randomly doing stuff will
 end in good things. People (trying) to thoughtfully organize won't.

It's not an argument, it's a statement of fact.

 No. The steering group should not have backroom discussions. They should
 act as open as possible. I think of it as a catalyst.

The operative here is *should*. Compare that to *will*. These are
different words. What the steering group *should* do and what they
*will* do is not the same thing.

-- 
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Lennart Regebro
On Tue, Mar 3, 2009 at 09:21, Martin Aspeli optilude+li...@gmail.com wrote:
 If anything, we started out with too little process and found there were
 gaps we had to plug.

Ah. Now, THIS I like. Let's focus on this: Start out with as little
process and as few officialisms as possible. And I don't see that a
steering group is as little as possible. If it turns out to be
necessary, we add it then.

-- 
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Hermann Himmelbauer
Am Montag 02 März 2009 18:11:59 schrieb Chris McDonough:
 Martijn Faassen wrote:
  The Zope Framework project
  ==
 
  :Author: Martijn Faassen
  :Date: 2009-03-02
 
  Introduction
  
 
  This document offers suggestions to reorganize our community so we can
  act more effectively. It does this by trying to clarify what our
  community is about. The document tries to innovate minimally in
  concepts and naming in order to provide a relatively small
  evolutionary step forward that can still make us all work together
  better. Even though this is an evolutionary step, it will still have a
  big impact if implemented, so please read on.
 
  This document should be relevant to *all* the parts of our community
  that build web applications, whether they use Zope 2, Zope 3, Grok,
  Repoze, or applications built on top of these such as Plone or
  Silva. While it talks a lot about Zope 3 this is because the Zope
  technology within Zope 3 is used within all these projects. The
  document wants to recognize this officially.
 
  The main innovations in concepts are the name Zope Framework to
  distinguish it from the Zope 3 application server and the
  core/extra concept. These are all hopefully descriptions of what
  are current practices, simply making them more explicit.
 
  The biggest innovation is the introduction of a Zope Framework
  Steering Group as a new entity that will be the steward for the
  development of this framework. The steering group's primary aim is to
  facilitate developers in the community so that they can continue to
  maintain and develop the framework so that it is useful to all of us.

 I'm pretty sure a steering group and a rebranding of existing software is
 not going to make us more effective.  Here's what I believe would make us
 more effective:

 - encouraging radical change for experimentation purposes, releasing folks
 from various constraints (backwards compatibility, style policing,
 historical ownership)

No, I really disagree with that. In my opinion. To my mind, the problems of 
Zope 3 do not come from too few radical ideas but from the fact, that many 
components are simply not yet finished and documented.

Building something new is for sure interesting, experimenting can and will be 
enlightening, but what we need is a very stable base.

 - discourage the contribution of stop energy (discourage
   the utterances of don't, stop, this is wrong,
   stop talking about this).

People like me, who build long-term projects, need to rely on a continuous 
development process. What I really don't want, is to overwork my whole code 
every half year in order to be able to upgrade to the current Zope 3 release.

I very much appreciate some sandbox-idea, where people can branch and 
experiment. But I think we miss so often the point, that Zope 3 technology is 
hard for newcomers (maybe different with Grok): The newbie (or, let's say the 
PHP-Junkie) is confronted with entirely new concepts:

- buildout (KGS)
- component architecture
- object database

... and much more. And there is no clear entry point to learn all that, so the 
user is really overwhelmed. And later on he may realize that various features 
are still absent in Zope 3 (e.g. session management via URLs etc.), or, what 
also happens quite often - he just does not find what he needs as some 
functionality is in some unknown lovely/z3c/zc/other package.

I think a key elelement in a project that decides over success/failure is the 
growth of its user base. So my suggestion is to really look closely what can 
be done in this area instead on focussing on radical architecture changes. 

Martijn's document, which tries to clear things up, is a good start in this 
area, I think.

Best Regards,
Hermann

-- 
herm...@qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Hanno Schlichting
Martijn Faassen wrote:
 The main innovations in concepts are the name Zope Framework to
 distinguish it from the Zope 3 application server and the
 core/extra concept. These are all hopefully descriptions of what
 are current practices, simply making them more explicit.

From what I read we do agree on this in general. The terms of what
packages are in the core are not fully fledged out, but this can easily
be done.

 The biggest innovation is the introduction of a Zope Framework
 Steering Group as a new entity that will be the steward for the
 development of this framework. The steering group's primary aim is to
 facilitate developers in the community so that they can continue to
 maintain and develop the framework so that it is useful to all of us.

The introduction of any kind of group equipped with whatever power seems
to be controversial.

I'll try to share a bit of how we approached this issue in the Plone
community.

Before Plone 2.5 we had no organized group of whatever kind and
overloaded the release manager with all concerns. People recognized that
more process distributed over multiple shoulders was required.

What we introduced is our Framework Team. It is in its very inception a
release team. It is focused on figuring out how to make a next release
of whatever crazy innovations happened in the community and bundle it up
as a consistent story. It serves for one release and is focused on it.
While you get some power of making decisions for the next release, your
powers are limited and have a natural end. You also get some boring and
tedious tasks to do as part of your job. This for naturally avoids to
have people on the team, who just talk but never deliver.

What our framework team does not do, is to care about long term strategy
nor guiding the community at large into one direction. Long term
strategy planning is done on the unorganized basis of some people caring
about it and doing the work required to push things into those
directions. Once those things have stabilized, the framework team can
pick them up and try to get them into the next release.

In order to provide guidance to the community, we have played another
mind trick to let people not feel like they are lead. We have made the
Plone Fondation be relevant, but not interface with the actual
development of the project in any real way. We then elected natural good
leaders into serving as the Foundation Board. As part of their role,
they do not possess any kind of actual power to decide anything in the
development process. They have however been recognized by the community
as leaders and been elected. This official community recognition alone
makes sure they are listened to in the community.

Hanno

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Hermann Himmelbauer
Am Montag 02 März 2009 18:49:43 schrieb Adam GROSZER:
 Hello,

 I think we need some sort of stering group (or person(s)).
 Without rules and decisions to follow we're going to end up like headless
 chicken running around in the kitchen. Noone knows the direction.

Exactly. And if we look at other projects, we always recognize some well known 
key persons, who have leader roles. For instance, SQLAlchemy has Michael 
Bayer, Linux has Linus, Python has Guido and so on. That does not mean that 
these key person(s) dictate the way the development goes, but 
consideres/embraces ideas and leads in one direction, where everyone follows.

My impression (from an external perspective) is that Zope Corporation did just 
that for Zope 2/3, but nowadays tries to give this role to the community. 
That's bad as this leaves an empty void, which is currently somehow filled 
out by some key persons, which are extremely capable, but don't have a leader 
role.

Best Regards,
Hermann

-- 
herm...@qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Hermann Himmelbauer
Am Montag 02 März 2009 19:34:11 schrieb Tres Seaver:
 Adam GROSZER wrote:
  I think we need some sort of stering group (or person(s)).
  Without rules and decisions to follow we're going to end up like headless
  chicken running around in the kitchen. Noone knows the direction.
 
  Yes sometimes radical changes are good. We're also carrying a lot of old
  baggage around with Zope3.
  It is lurking around the corner. Like Shane's zope.pipeline, repoze
  stuff,  etc.
  BUT at the same we have projects that have to be kept running (and
  migrated, possibly smoothly)
 
  Keeping our packages together at least with a KGS is a must in my
  opinion. Unless you want yourself to find a working set between the
  permutations of all required packages versions.
  Someone releases a new package version and your project just break the
  next day. That's a nightmare.

 Maybe we need to create something more like self-organizing
 mini-communities around the various packages (or maybe sets).  E.g., I

Isn't that the scenario we currently have? I already see some grouping around 
zope packages, Grok, z3c packages and others. But of course, these groups 
must work together, which will be difficult unless there's something that 
concentrates/coordinates the group's effort to form something bigger.

Best Regards,
Hermann

-- 
herm...@qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Roger Ineichen
Hi

 Betreff: Re: [Zope-dev] the Zope Framework project

[...]

  Grok and Repoze are in part *workarounds* for the 
 deficiencies in this 
  community. For Grok I'm very sure it's a workaround, as I had quite 
  something to do with it and this was explicit in my mind. It's not
  *only* a workaround, but it's definitely a community hack, too.
 
 I don't agree one bit it's workaround for deficiencies in the 
 community. It's workarounds for deficiencies Zope3. And the 
 community has fixed them.

You can also call this anticipation the oposit of participation

But I know it's much more productive to impelement a new framework
then to convince other developer to change something in existing
zope. And sometimes it has to happen.  We also did this in several
z3c packages.

The good thing right now is that we have different experiences and
can merge the good concepts back to the zope core or offer 
different implementations solving similar problems in different
ways.

The big questions now is, do we like to merge this good things
back to the zope core or do we like to stay with different
packages because we can't find an agreement what we like
to do.

Regards
Roger Ineichen

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Lennart Regebro
On Tue, Mar 3, 2009 at 12:53, Hermann Himmelbauer du...@qwer.tk wrote:
 My impression (from an external perspective) is that Zope Corporation did just
 that for Zope 2/3, but nowadays tries to give this role to the community.

No, I don't think we ever tried that. I think we should.

-- 
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Hermann Himmelbauer
Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro:
 On Tue, Mar 3, 2009 at 00:16, Martijn Faassen faas...@startifact.com 
wrote:
  Who is going to make that decision to encourage this? Allow this? You?
  Me? Who? Right now, *nobody* is making such decisions and nobody can
  properly get away with saying they allow it. Leadership is a way to get
  out of it.

 I think open source in general has shown two things:

 1. Communities can mostly take decisions without having official
 authorities to do so. This is hyper democratic.
 2. When they can't, usually committees can't either. In those cases
 somebody with a deciding vote is needed. This isn't democratic at all,
 but efficient.

Exactly. And that's what we currently don't have.

  +1, though a simple discouraging of utterance can't accomplish it by
  itself. What you need is active leadership that encourages such
  experimentation.

 I don't know about that. I agree with you that there hasn't been
 active leadership for a while. But look what has happened without this
 active leadership.
 * We have two cool new Zope 3 based frameworks. One which throws out
 the whole concept of ZCML for doing configuration by radical code
 introspection, and as a result making the Zope Framework immensely
 more accessible. And another one which experiments with revamping the
 way Zope publishes things, and a related effort of rewriting the whole
 publisher. Both frameworks have during these experimentation reached
 big audiences and gained widespread if still experimental acceptance
 in the community.

True - but to me it seems that this happened because someone took leadership 
in this scenario. 

 * Zope 2 has been eggified.
 * Buildout has totally massacred all other forms of deployment of Zope
 projects.

All that is true and very positive, but what has not happened and maybe never 
will that way, is the aggregation of all those Zope 3 efforts, documentation, 
website and the like. And that is something very important in order to 
attract a broader user base.

  Who decides to kill something off?

 If it doesn't get maintained, is dead. I guess you want somebody to
 make it official. I'm not sure it's necessary in a component based
 reality. With Zope 2 eggified for example, ZClasses gets a separate
 module, and it lives as long as somebody maintains it. It's then just
 a matter of deciding if it should be a part of the release or not,
 which the release manager(s) decide.

That's fine for one thing: Newbies don't know which packages are maintained 
and which are not. They find themselves confronted with a bunch of packages 
and don't know what they should use and what not. Example: zope.formlib vs. 
z3c.form.
For instance, I decided to use lovely.remotetask - but I recognized that the 
last commit is quite some time ago and don't really know if it's actively 
used/maintained.

  Who decides we should have a documentation website for a widely used
  component.

 Those who writes the documentation in question. :)

In some way, that's already done - nearly every package has some doctest, 
which does often cover the package specifics very well. However, I remember 
the days I looked at z3c.form: I recognized that I needed to get to know the 
following other packages:

- interfaces/adapters
- z3c.pagelet
- z3c.template
- (and quite some more)

This was very cumbersome.

  * who reminds us of necessary tasks and directions we're going into?
  Sometimes the community collectively decides on moving forward.
  Sometimes it doesn't. Are we really maintaining our issue tracker well,
  say?

 No, but then a person should get some sort of responsibility for that.
 Note: A person. Not a committee. A committee means a bunch of people
 are responsible, which is the same thing as saying that nobody is.

Yes, that's probably true. So either this steering group is a person or has 
some person who decides.

Best Regards,
Hermann

-- 
herm...@qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Lennart Regebro
On Tue, Mar 3, 2009 at 13:04, Roger Ineichen d...@projekt01.ch wrote:
 You can also call this anticipation the oposit of participation

:)

 The big questions now is, do we like to merge this good things
 back to the zope core or do we like to stay with different
 packages because we can't find an agreement what we like
 to do.

Just to be completely clear: I do absolutely think we should merge as
much goodness back as possible. I also agree with everything Martijn
Faassen said. Except, I do not think a steering group is necessary to
achieve these goals, and that in fact there is a significant risk that
is ends up hindering them.

I thought I could organize freedom. How Scandinavian of me --Björk: Hunter.

-- 
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Hermann Himmelbauer
Am Dienstag 03 März 2009 08:19:37 schrieb Lennart Regebro:
 On Tue, Mar 3, 2009 at 01:51, Martijn Faassen faas...@startifact.com 
wrote:
  Can you stop using the word committee? I didn't use it. A committee is
  a bunch of people who has regular meetings, behind closed doors, to make
  decisions. That's not what the Steering Group is designed to be.
  I'm talking about a group of people who act as if they're responsible,
  not your mythical committee. We should be able to find a bunch of people
  with a sense of responsibility, right?

 Yes. But I don't think making them a steering group is going to help.

Hmmm, I have the slight feeling that your opinions are not that far away. 
Maybe both of you should define what this steer group exactly is.

Best Regards,
Hermann

-- 
herm...@qwer.tk
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martijn Pieters
I find this thread quite ironic.

Martijn Faassen recognizes a problem, namely that there is no
direction in Zope development. Instead, when ideas are put forth lots
of people put in their oar with +1s and -1s and stop energy and cheer
leading one direction or another. In the end the ideas either get
pushed through by determined contributors or (more often) they die.

The irony is that the proposed solution, organized leadership, is
going to suffer the same fate as the aforementioned ideas. Everyone is
putting in their oar, +1s and -1s are flying right, left and centre,
and this idea is either going to die, or Martijn will have to push it
through and implement it. No one else seems enthusiastic enough to
make this happen outright, there is no clear direction.

So to me, the least this thread does is to prove that the flagged
problem does exist. And so far I haven't heard any better ideas than
what Martijn is proposing (no, leaving the status quo, deny there is a
problem and steer by majority is not a counter proposal in my view).
It may be that the idea needs some tweaking, but that's just details.

Would it be possible to focus this discussion around clearer lines?
Create counter proposals if you have to, discuss things on their
merits, but if you cannot add more than a vague +1 and -1, please
refrain.

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Lennart Regebro
On Tue, Mar 3, 2009 at 13:33, Hermann Himmelbauer du...@qwer.tk wrote:
 Hmmm, I have the slight feeling that your opinions are not that far away.

Of course not. This is, as aways, just a question of loudly agreeing.

-- 
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martin Aspeli
Martijn Pieters wrote:

 Would it be possible to focus this discussion around clearer lines?
 Create counter proposals if you have to, discuss things on their
 merits, but if you cannot add more than a vague +1 and -1, please
 refrain.

I think that would be easier if we had a shorter proposal. I suspect a 
lot of people only read bits of it, leading to some of the present 
confusion.

Martin

-- 
Author of `Professional Plone Development`, a book for developers who
want to work with Plone. See http://martinaspeli.net/plone-book

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Gary Poster

On Mar 3, 2009, at 7:35 AM, Martijn Pieters wrote:

...

 And so far I haven't heard any better ideas than
 what Martijn is proposing (no, leaving the status quo, deny there is a
 problem and steer by majority is not a counter proposal in my view).
 It may be that the idea needs some tweaking, but that's just details.

 Would it be possible to focus this discussion around clearer lines?
 Create counter proposals if you have to

...

I'm surprised my proposal didn't generate any replies, and can only  
assume that it is because it created the silence of everyone quietly  
saying Whaaa? :-)

My mild counter proposal was this.

- The ZF formally institutes an easy way for people to start Zope  
projects

- Hopefully, Martijn F. starts something like the project he described

- Hopefully, people follow it.

In other words, I suppose, Just Do It.

I don't think Martijn, nor anyone else who has been part of the  
community long enough to be on the ZF, needs the entire community to  
bless his idea to try to move forward--they need just an absence of a  
veto for the use of the chosen name, as I proposed more concretely in  
the original email.

I think that incorporates some of the more laissez-faire advocates are  
arguing for: someone else can also start their own counter project, if  
desired.  Maybe they won't, but they can.  And this freedom could  
allow us to escape the need to feel that everyone has to agree about  
this.

Beyond that, I didn't say my other smaller thought, which was that I  
think the KGS should ideally be looser and more flexible than what  
Martijn described.  If you have a project that wants in on the KGS,  
great, you can add it.  Institute a nightly KGS for an upcoming  
release (and maybe the most recent release).  It stays around forever  
at a specific URL.  Include only the projects whose tests pass in the  
nightly KGS.  Have a list elsewhere of the ones for which the tests  
fail.  If the tests don't pass for some period of time, apparently the  
maintainers and users don't exist or don't care, and they get taken  
off the list to be tested.  The Zope Framework team leader then  
decides some time to make a release, so people might shuffle around  
versions more than usual, but it's just another KGS.

Gary




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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Paul Everitt
On 3/2/09 10:13 PM, Martin Aspeli wrote:
 We recognised that there was a problem in trying to make sure we
 represented the interests of various stakeholders, and that we needed
 someone to think big picture in terms of what technologies we adopted
 and how we used them.

Just to be clear, I believe the Plone framework team has specifically 
disavowed management of Plone's strategy.  Meaning, they approve PLIPs 
on a release-to-release basis.  They don't make edicts like replace 
Archetypes.

This was the vacuum that the strategic planning summit advertised 
itself as addressing.

I think this clarification is informative to Martijn's discussion.

--Paul

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Paul Everitt
On 3/2/09 6:36 PM, Martijn Faassen wrote:
 Hi there,

 To people who are suggesting we don't need a steering group nor a name
 for the Zope Framework, please answer the following questions:

 * how will the community make hard decisions where lots of people
 disagree? What is the mechanism for making hard decisions? Don't say Jim
 makes them because as you may have noticed Jim *hasn't* been making so
 many of those in recent times. We need to solve this problem.

Ultimately I think I agree with Chris's position.  I think the days are 
past when we could commit to the success of an overarching Uberthing, be 
it a macroframework, platform, or app server.  Rather than commit your 
reserves in a desperate attempt to win the battle, you withdraw to avoid 
losing your whole army.

That notwithstanding, if Zope is still the goal, I endorse Martijn's 
proposal.  Like Gary said, it's admirable that he's taking a shot at 
this and we should bite our tongues on quibbling.

In the past we've seen things like let's unify Zope by merging the 
Zope2 and Zope3 mailing lists get shot down by a couple of loud no 
votes.  Loud no's have grown paralyzing.  If Martijn's proposal gets 
traction, then perhaps we have a way around them.

--Paul


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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Andreas Jung
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03.03.2009 14:45 Uhr, Paul Everitt wrote:

 
 In the past we've seen things like let's unify Zope by merging the 
 Zope2 and Zope3 mailing lists get shot down by a couple of loud no 
 votes.  Loud no's have grown paralyzing.  

This topic is still on the agenda and it all depends on who says no
and how one says no and why one says no.

Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkmtNWkACgkQCJIWIbr9KYzTFQCcDlRtNXiPW+0o4W2is6DW64Nm
aRIAn3UcnHq0L2tWyFEW59c9XZGYYjtr
=YGZL
-END PGP SIGNATURE-
begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX Ltd.  Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany
email;internet:i...@zopyx.com
title:CEO
tel;work:+49-7071-793376
tel;fax:+49-7071-7936840
tel;home:+49-7071-793257
x-mozilla-html:FALSE
url:www.zopyx.com
version:2.1
end:vcard

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Kent Tenney
On Wed, Mar 4, 2009 at 6:24 AM, Hermann Himmelbauer du...@qwer.tk wrote:
 Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro:
 On Tue, Mar 3, 2009 at 00:16, Martijn Faassen faas...@startifact.com
 wrote:
  Who is going to make that decision to encourage this? Allow this? You?
  Me? Who? Right now, *nobody* is making such decisions and nobody can
  properly get away with saying they allow it. Leadership is a way to get
  out of it.

 I think open source in general has shown two things:

 1. Communities can mostly take decisions without having official
 authorities to do so. This is hyper democratic.
 2. When they can't, usually committees can't either. In those cases
 somebody with a deciding vote is needed. This isn't democratic at all,
 but efficient.

 Exactly. And that's what we currently don't have.

  +1, though a simple discouraging of utterance can't accomplish it by
  itself. What you need is active leadership that encourages such
  experimentation.

 I don't know about that. I agree with you that there hasn't been
 active leadership for a while. But look what has happened without this
 active leadership.
 * We have two cool new Zope 3 based frameworks. One which throws out
 the whole concept of ZCML for doing configuration by radical code
 introspection, and as a result making the Zope Framework immensely
 more accessible. And another one which experiments with revamping the
 way Zope publishes things, and a related effort of rewriting the whole
 publisher. Both frameworks have during these experimentation reached
 big audiences and gained widespread if still experimental acceptance
 in the community.

 True - but to me it seems that this happened because someone took leadership
 in this scenario.

 * Zope 2 has been eggified.
 * Buildout has totally massacred all other forms of deployment of Zope
 projects.

 All that is true and very positive, but what has not happened and maybe never
 will that way, is the aggregation of all those Zope 3 efforts, documentation,
 website and the like. And that is something very important in order to
 attract a broader user base.

  Who decides to kill something off?

 If it doesn't get maintained, is dead. I guess you want somebody to
 make it official. I'm not sure it's necessary in a component based
 reality. With Zope 2 eggified for example, ZClasses gets a separate
 module, and it lives as long as somebody maintains it. It's then just
 a matter of deciding if it should be a part of the release or not,
 which the release manager(s) decide.

 That's fine for one thing: Newbies don't know which packages are maintained
 and which are not. They find themselves confronted with a bunch of packages
 and don't know what they should use and what not. Example: zope.formlib vs.
 z3c.form.
 For instance, I decided to use lovely.remotetask - but I recognized that the
 last commit is quite some time ago and don't really know if it's actively
 used/maintained.

I'll chime in as a newbie.

It seems many of the comments preferring ad-hoc to structure
come from we know what we are doing, we can take care of ourselves

I think Zope has the goal of attracting new users, and the proposal
has potential to make Zope more inviting to the uninitiated.

Zope is very diffuse, making it a challenge to grasp. I know I would benefit
from any initiative which sought to provide an overview role.

Thanks,
Kent

  Who decides we should have a documentation website for a widely used
  component.

 Those who writes the documentation in question. :)

 In some way, that's already done - nearly every package has some doctest,
 which does often cover the package specifics very well. However, I remember
 the days I looked at z3c.form: I recognized that I needed to get to know the
 following other packages:

 - interfaces/adapters
 - z3c.pagelet
 - z3c.template
 - (and quite some more)

 This was very cumbersome.

  * who reminds us of necessary tasks and directions we're going into?
  Sometimes the community collectively decides on moving forward.
  Sometimes it doesn't. Are we really maintaining our issue tracker well,
  say?

 No, but then a person should get some sort of responsibility for that.
 Note: A person. Not a committee. A committee means a bunch of people
 are responsible, which is the same thing as saying that nobody is.

 Yes, that's probably true. So either this steering group is a person or has
 some person who decides.

 Best Regards,
 Hermann

 --
 herm...@qwer.tk
 GPG key ID: 299893C7 (on keyservers)
 FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
 ___
 - Show quoted text -
 Zope-Dev maillist  -  zope-...@zope.org
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )

___
Zope-Dev maillist  -  Zope-Dev@zope.org

Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Andreas Jung
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 03.03.2009 15:37 Uhr, Kent Tenney wrote:
 On Wed, Mar 4, 2009 at 6:24 AM, Hermann Himmelbauer du...@qwer.tk wrote:
 Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro:
 On Tue, Mar 3, 2009 at 00:16, Martijn Faassen faas...@startifact.com
 wrote:
 Who is going to make that decision to encourage this? Allow this? You?
 Me? Who? Right now, *nobody* is making such decisions and nobody can
 properly get away with saying they allow it. Leadership is a way to get
 out of it.
 I think open source in general has shown two things:

 1. Communities can mostly take decisions without having official
 authorities to do so. This is hyper democratic.
 2. When they can't, usually committees can't either. In those cases
 somebody with a deciding vote is needed. This isn't democratic at all,
 but efficient.
 Exactly. And that's what we currently don't have.

 +1, though a simple discouraging of utterance can't accomplish it by
 itself. What you need is active leadership that encourages such
 experimentation.
 I don't know about that. I agree with you that there hasn't been
 active leadership for a while. But look what has happened without this
 active leadership.
 * We have two cool new Zope 3 based frameworks. One which throws out
 the whole concept of ZCML for doing configuration by radical code
 introspection, and as a result making the Zope Framework immensely
 more accessible. And another one which experiments with revamping the
 way Zope publishes things, and a related effort of rewriting the whole
 publisher. Both frameworks have during these experimentation reached
 big audiences and gained widespread if still experimental acceptance
 in the community.
 True - but to me it seems that this happened because someone took leadership
 in this scenario.

 * Zope 2 has been eggified.
 * Buildout has totally massacred all other forms of deployment of Zope
 projects.
 All that is true and very positive, but what has not happened and maybe never
 will that way, is the aggregation of all those Zope 3 efforts, documentation,
 website and the like. And that is something very important in order to
 attract a broader user base.

 Who decides to kill something off?
 If it doesn't get maintained, is dead. I guess you want somebody to
 make it official. I'm not sure it's necessary in a component based
 reality. With Zope 2 eggified for example, ZClasses gets a separate
 module, and it lives as long as somebody maintains it. It's then just
 a matter of deciding if it should be a part of the release or not,
 which the release manager(s) decide.
 That's fine for one thing: Newbies don't know which packages are maintained
 and which are not. They find themselves confronted with a bunch of packages
 and don't know what they should use and what not. Example: zope.formlib vs.
 z3c.form.
 For instance, I decided to use lovely.remotetask - but I recognized that the
 last commit is quite some time ago and don't really know if it's actively
 used/maintained.
 
 I'll chime in as a newbie.
 
 It seems many of the comments preferring ad-hoc to structure
 come from we know what we are doing, we can take care of ourselves
 
 I think Zope has the goal of attracting new users, and the proposal
 has potential to make Zope more inviting to the uninitiated.
 
 Zope is very diffuse, making it a challenge to grasp. I know I would benefit
 from any initiative which sought to provide an overview role.
 


I started up with something for zope2.zope.org in order to bring
sort out the various things a bit:

http://zope2.zopyx.de/about-zope-2/the-zope-eco-system

Andreas
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkmtQfsACgkQCJIWIbr9KYw35wCgjXRDehJnSK44ztKrSLa5iizk
uUwAoMTQpj+0tSbI3NA5zYEgHLrFe4zY
=y1Df
-END PGP SIGNATURE-
begin:vcard
fn:Andreas Jung
n:Jung;Andreas
org:ZOPYX Ltd.  Co. KG
adr;quoted-printable:;;Charlottenstr. 37/1;T=C3=BCbingen;;72070;Germany
email;internet:i...@zopyx.com
title:CEO
tel;work:+49-7071-793376
tel;fax:+49-7071-7936840
tel;home:+49-7071-793257
x-mozilla-html:FALSE
url:www.zopyx.com
version:2.1
end:vcard

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Paul Everitt
On 3/3/09 9:37 AM, Kent Tenney wrote:
 I'll chime in as a newbie.

 It seems many of the comments preferring ad-hoc to structure
 come from we know what we are doing, we can take care of ourselves

 I think Zope has the goal of attracting new users, and the proposal
 has potential to make Zope more inviting to the uninitiated.

 Zope is very diffuse, making it a challenge to grasp. I know I would benefit
 from any initiative which sought to provide an overview role.

I'm not sure that's a goal of this proposal.  The word Zope will 
continue to have its previous series of semi-competing meanings.  The 
word will now also be attached to Framework, which will be the emphasis.

As I read it, regarding the diffusion, asking the stakeholders in the 
existing meanings of the word to yield is not part of the proposal. 
(Thankfully, as that is hopeless.)

The focus, though, will be on greatest-common-factor of the shared 
meaning.  Not a solution to diffusion, but an improvement.

--Paul

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Kent Tenney
On Wed, Mar 4, 2009 at 8:43 AM, Andreas Jung li...@zopyx.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 - Show quoted text -
 On 03.03.2009 15:37 Uhr, Kent Tenney wrote:
 On Wed, Mar 4, 2009 at 6:24 AM, Hermann Himmelbauer du...@qwer.tk wrote:
 Am Dienstag 03 März 2009 00:48:38 schrieb Lennart Regebro:
 On Tue, Mar 3, 2009 at 00:16, Martijn Faassen faas...@startifact.com
 wrote:
 Who is going to make that decision to encourage this? Allow this? You?
 Me? Who? Right now, *nobody* is making such decisions and nobody can
 properly get away with saying they allow it. Leadership is a way to get
 out of it.
 I think open source in general has shown two things:

 1. Communities can mostly take decisions without having official
 authorities to do so. This is hyper democratic.
 2. When they can't, usually committees can't either. In those cases
 somebody with a deciding vote is needed. This isn't democratic at all,
 but efficient.
 Exactly. And that's what we currently don't have.

 +1, though a simple discouraging of utterance can't accomplish it by
 itself. What you need is active leadership that encourages such
 experimentation.
 I don't know about that. I agree with you that there hasn't been
 active leadership for a while. But look what has happened without this
 active leadership.
 * We have two cool new Zope 3 based frameworks. One which throws out
 the whole concept of ZCML for doing configuration by radical code
 introspection, and as a result making the Zope Framework immensely
 more accessible. And another one which experiments with revamping the
 way Zope publishes things, and a related effort of rewriting the whole
 publisher. Both frameworks have during these experimentation reached
 big audiences and gained widespread if still experimental acceptance
 in the community.
 True - but to me it seems that this happened because someone took leadership
 in this scenario.

 * Zope 2 has been eggified.
 * Buildout has totally massacred all other forms of deployment of Zope
 projects.
 All that is true and very positive, but what has not happened and maybe 
 never
 will that way, is the aggregation of all those Zope 3 efforts, 
 documentation,
 website and the like. And that is something very important in order to
 attract a broader user base.

 Who decides to kill something off?
 If it doesn't get maintained, is dead. I guess you want somebody to
 make it official. I'm not sure it's necessary in a component based
 reality. With Zope 2 eggified for example, ZClasses gets a separate
 module, and it lives as long as somebody maintains it. It's then just
 a matter of deciding if it should be a part of the release or not,
 which the release manager(s) decide.
 That's fine for one thing: Newbies don't know which packages are maintained
 and which are not. They find themselves confronted with a bunch of packages
 and don't know what they should use and what not. Example: zope.formlib vs.
 z3c.form.
 For instance, I decided to use lovely.remotetask - but I recognized that the
 last commit is quite some time ago and don't really know if it's actively
 used/maintained.

 I'll chime in as a newbie.

 It seems many of the comments preferring ad-hoc to structure
 come from we know what we are doing, we can take care of ourselves

 I think Zope has the goal of attracting new users, and the proposal
 has potential to make Zope more inviting to the uninitiated.

 Zope is very diffuse, making it a challenge to grasp. I know I would benefit
 from any initiative which sought to provide an overview role.



 I started up with something for zope2.zope.org in order to bring
 sort out the various things a bit:

 http://zope2.zopyx.de/about-zope-2/the-zope-eco-system

That's very useful, and seems to describe the theory of the Zope world.
In theory, theory and practice are the same, in practice they are not.

My post was prompted by the mention of knowing which of several
similar components is preferred, deprecated, abandoned.

Maybe this doesn't fall within the proposal, but it strikes me as
an element of 'steering'.

I think that watching exchanges between a steering entity and the dev community
would be a good vantage point for getting a picture of the Zope landscape.

Thanks,
Kent


 Andreas
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1.4.9 (Darwin)
 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

 iEYEARECAAYFAkmtQfsACgkQCJIWIbr9KYw35wCgjXRDehJnSK44ztKrSLa5iizk
 uUwAoMTQpj+0tSbI3NA5zYEgHLrFe4zY
 =y1Df
 -END PGP SIGNATURE-

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Stephan Richter
On Monday 02 March 2009, Chris Withers wrote:
 Adam GROSZER wrote:
  Someone releases a new package version and your project just break the
  next day. That's a nightmare.

 That shouldn't happen with individual package releases where releases
 are done sensibly.

Let me tell you from experience: Before the KGS we had exactely this problem. 
No carefully crafted release can male up for that. And if a single package 
pins versions generically, then you stall development. We also had that 
ha[[en before the KGS came around. Both reasons actually promted my to do the 
KGS in the first place.

In general, and not specific to you Chris, I think that unless you have 
managed a large set of packages, you should shut up and listen.

Regards,
Stephan
-- 
Stephan Richter
Web Software Design, Development and Training
Google me. Zope Stephan Richter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Aspeli wrote:
 Tres Seaver wrote:

snip

 - - How many need *all* of Zope3, including the ZMI?  I'm betting that
   set is much smaller than either of the others?
 
 Probably none. So having better dependencies would obviously be good. I 
 think you still need a KGS of sorts, but you don't need to depend on 
 *all* of it. :)

I'm sure that the set is bigger than that.  However, I want to identify
the critical subset the *everybody* needs, and ensure that we prioritize
steering efforts there:  the other packages can mostly just be left in
the hands of the disjoint groups that need them.

 - - Of the first set, what is the likelihood that different projects
   will have conflicting goals about the direction of one or more
   packages?

 Given the likelihood that a monolithic Zope 3.5 release is not
 interesting to lots of the folks who both develop and consume its
 packages, how much coordination is going to be possible (or even useful)
 around the idea of another release?
 
 Maybe we could identify some vectors down the dependency graph that we 
 *do* care about. If we analysed our projects (Plone, and a bunch of 
 add-on products, for instance), we could probably manage to maintain 
 KGS' that say if you want the container interfaces, these packages are 
 known to work together.

I suggested one such vector (zope.interface, zope.component).  Another
one is the packages which Zope2 (really) needs.


 Maybe we need to create something more like self-organizing
 mini-communities around the various packages (or maybe sets).
 
 Heh... right. ;-)
 
  E.g., I
 would bet that almost everyone active on this list has a stake in
 zope.interface, zope.component, and their dependencies.  Note that *two*
 of the remaining dependencies (zope.deferredimport, zope.deprecation)
 are only there to deal with BBB isssues:  maybe they should go?
 
 Why? They're tiny, and BBB is good. No piece of framework code can be 
 taken seriously if it pretends that people are not going to need 
 backwards compatibility.

Some BBB may be worth keeping:  I have argued before, however, that the
specific BBB strategy which requires those three packages is not a big
success:   rather than proxying all modules with deprecations, for
instance, I would rather just leave the BBB imports in place *forever*,
without emitting warnings.

 Another, zope.proxy, is a blocker for using the packages on non-CPython
 platforms:  should it go?  If we consider those packages *in isolation*,
 as things potentially useful outside any larger framework, the answers
 to those questions might be different.
 
 True.
 
 I'm not so sure that any other package is going to be as widely
 interesting.
 
 I can think of a few: the container stuff, browser views and pages, page 
 template files, for example.

We already have successful forks for a number of those.

  I also think that having the *whole* Zope community do
 oversight oversee on the rest is less useful than having the folks with
 skin in the game for a particular package steer it.  I am unlikely to
 care much about anything in the Z3 ZMI, for instance, or about a number
 of other packages in our various namespaces:  I could do my job better,
 *and* keep from interfering in others' interests (e.g., the stop
 energy Chris mentioned), if we separated out the various areas of concerns.
 
 True. However, someone still needs to think about whether these things 
 are pulling in the same direction, or becoming incompatible with one 
 another.

Note that divergence may be an acceptable outcome, here, especially if
we adopt the pattern that fundamental disagreements on the direction of
a shared package can be resolved by the amicable divorce of a fork.



Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJrU4N+gerLs4ltQ4RAuFaAKC2eBkntSauZvi0qWm5wgAvuwVD+QCgxIa8
y8wKdscbD9+f4bfyq+42yfM=
=71WM
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Stephan Richter
On Tuesday 03 March 2009, Martijn Pieters wrote:
 The irony is that the proposed solution, organized leadership, is
 going to suffer the same fate as the aforementioned ideas. Everyone is
 putting in their oar, +1s and -1s are flying right, left and centre,
 and this idea is either going to die, or Martijn will have to push it
 through and implement it. No one else seems enthusiastic enough to
 make this happen outright, there is no clear direction.

I had the same sentiment while reading the thread, which is why I am mostly 
staying out of it.

Just in case it is not clear from my previous responses, I agree with 
Martijn's analysis and I am in favor of Martijns proposal and will help him 
as much as I can to get it implemented. I will gladly work on the proposed 
KGS split, keep doing Zope Framework and Zope 3 App server releases, and 
serve on the steering group.

We got to try something and I think this is a good and honest attempt.

Regards,
Stephan
-- 
Stephan Richter
Web Software Design, Development and Training
Google me. Zope Stephan Richter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stephan Richter wrote:
 On Monday 02 March 2009, Chris Withers wrote:
 Adam GROSZER wrote:
 Someone releases a new package version and your project just break the
 next day. That's a nightmare.
 That shouldn't happen with individual package releases where releases
 are done sensibly.
 
 Let me tell you from experience: Before the KGS we had exactely this problem. 
 No carefully crafted release can male up for that. And if a single package 
 pins versions generically, then you stall development. We also had that 
 ha[[en before the KGS came around. Both reasons actually promted my to do the 
 KGS in the first place.
 
 In general, and not specific to you Chris, I think that unless you have 
 managed a large set of packages, you should shut up and listen.

Stephan, I *have* managed a large set, and I'm *certain* that the KGS is
useful for many cases:  it just doesn't work for me for any large
production application:  I don't want to rely on the iffy availability
of eggs from PyPI, for instance, which means that running a separate,
per-project index is my only recourse anyway.  Once you are running your
own index, it's contents *are* a KGS, just not one managed using the
'versions.cfg' machinery.

That said, I do appreciate the work you have done and are doing to make
the KGS useful for others.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJrU/N+gerLs4ltQ4RAhhjAKCXFz/UWoahvRiBkWYy7oWT7+2wZgCfdZ0h
Nwc71oEYwqV1Jm0liFofTUA=
=7Y6k
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martin Aspeli wrote:
 Martijn Faassen wrote:
 
 What is going to make us more effective is:

 * a recognition of current reality, i.e. the Zope Framework is not the 
 same as the Zope 3 application server and it serves a far wider audience.

 * leadership
 
 I really couldn't agree more. There's unfortunately a bit of a 
 leadership vacuum in the Zope community.
 
 I think Tres and Chris are suggesting we focus leadership around 
 individual packages or sets of packages, and Martijn is suggesting we 
 have something a bit broader focusing on all of Zope. I think the two 
 are not necessarily mutually exclusive. And I'd take any leadership over 
 none at all.
 
 Plone, by the way, had a similar problem, and solved it by creating the 
 framework team. This is a rolling body of people who are responsible 
 for putting out calls for and reviewing improvements proposals. They 
 basically report to the release manager, who makes the final call. The 
 release manager is nominated by the framework team, confirmed by the 
 Plone Foundation, and given a small stipend for his troubles.

Funny you should pick them as your example.  I've seen members of that
team *actively deny* that the team has any role in setting technical
direction for Plone (which is ironic, given that what they actually do
is to review and approvie PEPs, as well as choosing the release manager).


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJrVLl+gerLs4ltQ4RAvlfAJ9+fN/QKeP0rKPYAYWfIgRxIamMGACguQEi
WFITE1Q+ICLT4MMhquvcWc0=
=KyEB
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martijn Faassen
Hey,

Tres Seaver wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Martin Aspeli wrote:
 Tres Seaver wrote:
 
 snip
 
 - - How many need *all* of Zope3, including the ZMI?  I'm betting that
   set is much smaller than either of the others?
 Probably none. So having better dependencies would obviously be good. I 
 think you still need a KGS of sorts, but you don't need to depend on 
 *all* of it. :)
 
 I'm sure that the set is bigger than that.  However, I want to identify
 the critical subset the *everybody* needs, and ensure that we prioritize
 steering efforts there:  the other packages can mostly just be left in
 the hands of the disjoint groups that need them.

That critical subset is very small, and it's zope.interface, which 
Twisted also needs, and only needs.

We can't define the framework by what everybody needs. We can define it 
by what lots of people need. The people with less buy-in into this 
framework will have to care just about the smaller bits of course, but 
the developers as a whole will need to coordinate a larger chunk.

Surrounding that chunk we'll have broader projects that care about even 
bigger chunks, definitely. My goal with the Zope Framework is to 
identify at least one chunk shared between the Zope 3 app server, Zope 2 
and Grok. Other projects use less of it, and I think it's in our 
interests to cut it down to size, but it'll never be cut down to the 
size of zope.interface.

I realize that this is only an approximation of the messy reality, but 
we need an approximation of reality we can all understand to be able to 
communicate about it and work together.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martijn Faassen
Chris Withers wrote:
 Adam GROSZER wrote:
 Someone releases a new package version and your project just break the
 next day. That's a nightmare.
 
 That shouldn't happen with individual package releases where releases 
 are done sensibly.
 (ie: if you're going to do a big backwards-incompatible release, let 
 people know. If you rely on a package, put in some sensible version 
 constraints in your setup.py, if your *project* (rather than your 
 packages) is paranoid (and it should be!) then lock the versions you use 
 down in something project-specific like a buildout.cfg, if you use buildout.

The community can give suggestions about locking down. this is not some 
kind of fancy theory but something that has worked for Zope 3 and Grok 
since late 2007.

One of the things wrong with the zope-dev community is that we way too 
heavily in favor of the here's a giant toolbox, just figure it out 
attitude in the name of ultimate flexibility. Instead we have to think 
about ways to figure out things *for* people so they don't have to do a 
lot of duplicate work.

We should of course still support the giant toolbox use case. I'm just 
saying we should do *more* than that, too.

Regards,

Martijn


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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Stephan Richter
On Tuesday 03 March 2009, Lennart Regebro wrote:
 On Tue, Mar 3, 2009 at 09:21, Martin Aspeli optilude+li...@gmail.com 
wrote:
  If anything, we started out with too little process and found there were
  gaps we had to plug.

 Ah. Now, THIS I like. Let's focus on this: Start out with as little
 process and as few officialisms as possible. And I don't see that a
 steering group is as little as possible. If it turns out to be
 necessary, we add it then.

Martijn is asserting (correctly in my opinion) that we tried the no leader 
approach for a while and failed. We are now discussing the necessary steps to 
resolve the problem. Martijn's solution is a steering group.

Regards,
Stephan
-- 
Stephan Richter
Web Software Design, Development and Training
Google me. Zope Stephan Richter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Stephan Richter
On Tuesday 03 March 2009, Tres Seaver wrote:
 Stephan, I *have* managed a large set, and I'm *certain* that the KGS is
 useful for many cases:  it just doesn't work for me for any large
 production application:  I don't want to rely on the iffy availability
 of eggs from PyPI, for instance, which means that running a separate,
 per-project index is my only recourse anyway.  Once you are running your
 own index, it's contents *are* a KGS, just not one managed using the
 'versions.cfg' machinery.

Who says that you cannot use your own index with the KGS? Do you think I use 
the official PyPI location for production? We use two approaches at Keas:

(1) Use a PyPI proxy server that caches all needed packages locally.

(2) Use zc.sourcerelease so that all packages are part of the big source TAR 
ball.

Both approaches work just fine and we are still using the KGS for our version 
pinning. So here is an example of a typical buildout.cfg that we have:

[buildout]
extends = versions-3.4.0.cfg
versions = versions
extensions=lovely.buildouthttp
find-links = http://eggs.gokeas.com/eggs

[versions]
keas.kmi = 0.3.1
lxml = 2.1.2
mechanize = 0.1.8
MySQL-python = 1.2.2
python-dateutil = 1.4.1
RelStorage = 1.1.1
setuptools = 0.6c9
z3c.datagenerator = 0.0.3
z3c.form =
z3c.formjs =
z3c.menu.ready2go =
z3c.rest = 0.2.5
z3c.traverser = 0.2.3
z3c.versionedresource = 0.4.0
zc.testbrowser =
zope.annotation = 3.4.1
zope.app.appsetup = 3.8.0
zope.app.container = 3.7.0
zope.container = 3.7.0
zope.app.locales = 3.4.5
zope.app.publisher = 3.5.0
zope.i18n = 3.5.0
zope.publisher = 3.5.4
zope.security = 3.5.2 # Updated secure function list for Python 2.5
zope.sendmail = 3.5.0
zope.server = 3.5.0
zope.testing = 3.5.5
simplejson = 1.9.1
hurry.query =
gocept.registration =
lovely.session =

Regards,
Stephan
-- 
Stephan Richter
Web Software Design, Development and Training
Google me. Zope Stephan Richter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Stephan Richter
On Tuesday 03 March 2009, Gary Poster wrote:
 My mild counter proposal was this.

 - The ZF formally institutes an easy way for people to start Zope  
 projects

 - Hopefully, Martijn F. starts something like the project he described

 - Hopefully, people follow it.

 In other words, I suppose, Just Do It.

Actually Martijn tried to be better than that. :-) Instead of just forming a 
steering group (which I would interpret as a Zope project) and announcing it 
to the community, he asked for feedback first. :-)

I probably agree he should have just done it by gathering the various release 
managers. BTW, in one of my original responses, I proposed to Martijn that 
the steering group should be mostly the release managers plus one or two 
strong developers so that the group reaches an odd number.

 Beyond that, I didn't say my other smaller thought, which was that I  
 think the KGS should ideally be looser and more flexible than what  
 Martijn described.  If you have a project that wants in on the KGS,  
 great, you can add it.

That is the case right now and I think a steering group would be pretty open 
to additions.

However, I think Martijn made a much more important point. What he wants, if I 
understood him correctly, is more of an organization around a hierarchy of 
KGSs. The reason for this is that Zope/Plone, grok, and Zope 3 AS all share a 
common core and maybe a coreplus set. Then each sub-project maintains a KGS 
on top of that with their specific extensions.

(1) This will make interoperability much easier, since I could potentially use 
grok X.Y in Zope 2.Z without worrying about version conflicts. 

(2) If the steering group contains all of the release managers, then releases 
can be synced effectively.

 Institute a nightly KGS for an upcoming   
 release (and maybe the most recent release).

We do have this system today.

http://zope3.afpy.org/buildbot/waterfall

 It stays around forever   
 at a specific URL.  Include only the projects whose tests pass in the  
 nightly KGS.  Have a list elsewhere of the ones for which the tests  
 fail.  If the tests don't pass for some period of time, apparently the  
 maintainers and users don't exist or don't care, and they get taken  
 off the list to be tested.

That statement is a massive over-simplification of what's going on. ;-) There 
are several problems:

(1) Tests that pass in isolation might not pass in a complete run. This might 
be due to this or another packages incomplete teardown. (Several people spent 
weeks getting this right for the 3.4 KGS.)

(2) A new release of one package might break 5 others. Who is responsible for 
updating the 5 breaking packages. The author that just released the new 
package or the ones from the 5 others? What if those other packages do not 
have clear, single maintainers (e.g. zope.*)?

I am not making up these cases. They are real and they exist today. The idea 
that one package has 1 or more concrete and devoted authors is simply not 
real in the Zope world of 200+ packages.

 The Zope Framework team leader then   
 decides some time to make a release, so people might shuffle around  
 versions more than usual, but it's just another KGS.

Yep, this is basically what happens today. For example, at Keas we use 
different versions (even trunk) of at least 20 packages. The point is that 
people have a stable point to start with. I think that would not change.

Regards,
Stephan
-- 
Stephan Richter
Web Software Design, Development and Training
Google me. Zope Stephan Richter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martijn Faassen
Hi there,

Martin Aspeli wrote:
[snip]
 I think Martijn is trying to address something that Zope has lacked for 
 a while. I don't think it'll solve all of the world's problems, nor do I 
 think that Martijn things so, but it will make some things - things like 
 this very debate - a bit easier and more productive.

Thanks very much Martin for putting all of this to words so well. Yes, 
exactly!

+100

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martijn Faassen
Christian Theune wrote:
 On Tue, 2009-03-03 at 02:35 +0100, Martijn Faassen wrote:
 * leadership could help sustain efforts like we want the Zope Framework 
 to run on Jython and make detailed decisions based on this. Nobody 
 right now can really decide on this.
 
 Anecdote: Our current Jython story (due to last GSOC) is having lots of
 conditional imports sprinkled all over the code base with an 'if
 sys.platform == java'. For some reason there was no discussion about
 that and we even didn't get enough stop-energy in my POV. ;)

Yeah, that was a seriously disfunctional Summer of Code project. In that 
case I did encourage communication very much from our end. Those 
checkins were some form unilateral week after the deadline rescue 
effort on the student's part so that he'd get paid. Whether he got away 
with it I don't know, as the PSF was in charge of that project in the end.

This shows that even if you have people on top of things (I saw the 
danger signals in this project *way* ahead of time) it still can go 
wrong. :)

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martijn Faassen
Hi there,

Martin Aspeli wrote:
[snip]
 You and I had a discussion a while back about forking the zope.component 
 ZCML directives, and how it would've been better to work within the 
 boundaries of the Zope packages so that everyone who wanted to lose the 
 zope.security dependency could benefit, rather than fork this and all 
 other configuration that depends on the core ZCML directives. The main 
 reason you had for creating your own package, was the lack of momentum 
 (and/or stop energy) encountered when trying to do this in the Zope 
 world. If there was someone who could both consider BFG's needs in a 
 more objective light, and have the power to actually do something rather 
 than just bicker, then maybe we could've gone a different route on that 
 one. With more and more dependency untangling happening, I am pretty 
 sure this same situation is going to come up again.

Yes, this is a very good example of why Chris should be in favor of 
leadership for the Zope Framework. The Grok project would've appreciated 
such improvements right there in zope.component too.

When I brought up the issue of trying to improve zope.component 
recently, I got a lot of divergent feedback and nothing happened. It'd 
be nice if instead such energy instead resulted in a concrete set of 
actions.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martijn Faassen
Hi there,

Martin Aspeli wrote:
[snip]
 I'm not sure Plone's model fits Zope perfectly, but certainly there are 
 some lessons to be learned. We also have some of processes and 
 documentation already in place, having made a few mistakes along the way.

Definitely, I'm very interested in seeing whether we can't adopt much of 
this model for Zope.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martijn Faassen
Hi there,

Lennart Regebro wrote:
 1. Areas that need somebody responsible should get one. We need
 somebody to bug people about bugs in the bug tracker. That should be
 one person, for example. Responsibilities need to be well defined and
 individual. There isn't anybody called Someone here, so if Someone has
 to do it, that doesn't get done.

Who defines these responsibilities and hands them out? Who reminds 
people of bits of the project that could use a responsible person to 
take charge?

I'm asking this as I've taken this role for the Grok project, and 
sometimes my reminding results in volunteers taking responsibility for a 
bit of the project, whether it's code or documentation or management. 
Without someone who identifies these responsibilities, there's far less 
chance of people taking them.

 2. To get things done release-wise, I think it would be good to have a
 release-team for each release. And that would reasonable be different
 teams for Zope2 and Zope 3, and possibly even for The  Zope Framework,
 obviously most likely with personnel overlaps.

Are you talking about a team like the Plone Framework team that guides 
development leading *up* to a release (and including it), or are you 
talking about a team of people who set up the KGS, write release notes 
and release packages to PyPI?

 3. To steer, and keep the community on track, I think regular meetings
 of people in real life will beat any steering group, all hands down.
 This would best happen at the same time as a conference, and either
 the Plone conference or PyCon or Europython.

Whoever shows up will have the say and people not there will just have 
to put up with it? I think that works to a certain extent in sprints, 
but we are an internet based open source project and we should have ways 
to make progress while distributed.

Who is doing to take care about such decisions being executed when we're 
back online again after a meeting? Is anyone going to keep track of 
decisions made and remind people to finish up on efforts started?

 I think this will give us enough steering. We aren't as many people as
 for example Plone or Python. Maybe, if we get everybody on track, we
 will be, and then we'll have to rethink. But currently the people
 involved, and the people that need to be steered are so few we can
 fit them all into one room at a time. And then I do not see why would
 would need a steering group.

I don't agree that we have such a small group. It's also a question 
about whether we really *want* this to be a small group.

I also don't think this is a sound mechanism in the long run. People are 
going to inevitably drop out from our community and we need fresh blood, 
also for fresh ideas and energy. If the only decisions are going to be 
made in real life meetings, there'll be little chance new people will 
get involved, as they'd not show up to such meetings.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martijn Faassen
Hi there,

Lennart Regebro wrote:
[snip]
 No. The steering group should not have backroom discussions. They should
 act as open as possible. I think of it as a catalyst.
 
 The operative here is *should*. Compare that to *will*. These are
 different words. What the steering group *should* do and what they
 *will* do is not the same thing.

Yes, and you're asserting it won't even though it'll be founded with 
that exact intent. You may be right of course, though I don't think so.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martijn Faassen
Hi there,

Lennart Regebro wrote:
[snip]
 As much as I prefer discussing with people in real life, there is the
 notion of no backroom conversations WRT to driving development of an
 open source project.
 
 OK. *Cough*. You and Martijn wrote this proposal. And you asked
 Stephan about it. You did backroom conversations.

I wrote the proposal based on conversations I had with Christian and 
also Jim, and Christian and several others gave input.

Backroom work will happen (conversations and decisions both). But it 
cannot be the only thing that drives the open source project.

  Aren't we now saying that to avoid excluding some people, we should
  exclude all but a steering group?  :-)

You have a very different perspective on a Steering Group. It's not a 
mechanism for exclusion but for *inclusion*. The steering group should 
care about the different interests in our community and actively balance 
them and consult them, and channel existing energies allowing them to 
result in something instead of dissipate.

Of course you seem to say this all depends on the people in the steering 
group and that in practice this won't happen. This is something we'll 
need to try to find out, right?

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martijn Faassen
Paul Everitt wrote:
 On 3/2/09 10:13 PM, Martin Aspeli wrote:
 We recognised that there was a problem in trying to make sure we
 represented the interests of various stakeholders, and that we needed
 someone to think big picture in terms of what technologies we adopted
 and how we used them.
 
 Just to be clear, I believe the Plone framework team has specifically 
 disavowed management of Plone's strategy.  Meaning, they approve PLIPs 
 on a release-to-release basis.  They don't make edicts like replace 
 Archetypes.
 
 This was the vacuum that the strategic planning summit advertised 
 itself as addressing.
 
 I think this clarification is informative to Martijn's discussion.

That's interesting indeed.

It's hard to know whether Plone's method of a strategic planning 
summit is working on the long term as you only had one as far as I 
know. (though I did hear positive news about it). I do have the 
impression the framework team strategy works reasonably well; it's been 
operating for about 2 releases now?

So you have one mechanism to set long term directions (and I think 
another one, namely Alexander Limi), and another to execute these long 
term directions and make smaller decisions in the light of them.

In reality of course a lot of micro decisions can result in a long term 
direction, so there's a gray area there.

For the Zope Framework I think it's more important to get the day to day 
decision making working in our community than it is to do the long term 
setting of directions and planning. We do have some form of long term 
direction emerging that we can recognize often enough (though we can do 
a lot better still). The core problem in my mind is the day to day 
decision making and channeling of energies.

I myself am inclined, for the Zope Framework, to start with the day to 
day team. I think it can deduce at least some long term directions from 
the community on the mailing list and usage in practice (also by 
consultation). We could amend such a process with a strategic planning 
summit construction, later.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martijn Faassen wrote:
 Hi there,
 
 Tres Seaver wrote:
 [snip]
 Stephan, I *have* managed a large set, and I'm *certain* that the KGS is
 useful for many cases:  it just doesn't work for me for any large
 production application:  I don't want to rely on the iffy availability
 of eggs from PyPI, for instance, which means that running a separate,
 per-project index is my only recourse anyway.  Once you are running your
 own index, it's contents *are* a KGS, just not one managed using the
 'versions.cfg' machinery.

 That said, I do appreciate the work you have done and are doing to make
 the KGS useful for others.
 
 Distinguish KGS the concept (a list of locked down versions as 
 suggestions to users of the framework) from KGS the implementation.
 
 Let's agree on the *concept* of a locked down list of versions that's 
 maintained by the community, or in fact more than one such list.

Acknowledging the idea that we might have more than one removes the
sting for me.

 If people want to diverge in the implementation, fine. Different 
 implementations have different advantages during development and deployment.

Yup, or for different styles of projects.  As a *personal* example:
*every* time I try to short-cut the process of setting up a
project-specific index representing the KGS *for that project,* I end up
getting burned by something.  At this point, I don't even think about
skipping the index setup, any more than I would skip setting up a VCS
repository or mailing lists for the project.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJrWeH+gerLs4ltQ4RAoB+AKCL7Hypan2VGvmdQc1XvEMLk/0uPQCeJr1r
xXJnto/QQdlLcKozkid74M8=
=1g4r
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stephan Richter wrote:
 On Tuesday 03 March 2009, Tres Seaver wrote:
 Stephan, I *have* managed a large set, and I'm *certain* that the KGS is
 useful for many cases:  it just doesn't work for me for any large
 production application:  I don't want to rely on the iffy availability
 of eggs from PyPI, for instance, which means that running a separate,
 per-project index is my only recourse anyway.  Once you are running your
 own index, it's contents *are* a KGS, just not one managed using the
 'versions.cfg' machinery.
 
 Who says that you cannot use your own index with the KGS? Do you think I use 
 the official PyPI location for production? We use two approaches at Keas:

If I'm running my own project-specific index, it *is* the KGS for that
project:  I don't need to manage versions anyplace else.

 (1) Use a PyPI proxy server that caches all needed packages locally.

Not an option:  I don't let new pacakges, or new versions, into my index
 without reviewing them first.  Typically, this means adding the egg to
my sandbox (e.g., via easy_install, or a develop-egg), verifying that it
works with the other pacakges, has reasonable tests and docs, and does
what I need.  Once I'm done with that review, I copy the sdist to my
project index, and update the dependencies and / or buildout config to
pull it in.

 (2) Use zc.sourcerelease so that all packages are part of the big source TAR 
 ball.

I don't need the big tarball, because I have an index:  I can just
enumerate the eggs I need (e.g., in 'install_requires' or in
buildout.cfg) without any versioning at all, and trust that the index
will supply the blessed versions.



Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJrWjU+gerLs4ltQ4RApviAJ9Ul8m8FXzbYV9YK2Mt2ofNs2SfhQCfWLCt
E9CK+vzQnGQG7djluyL8cew=
=PcE6
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martijn Faassen
Hey Gary,

[panarchist approach where we have people starting groups that could 
compete for attention]

I agree that it should be relatively easy to start Zope projects under 
the Zope umbrella.

I agree that such projects could compete for attention and may the best 
one win.

I think this is what's more or less already happening anyway, and I 
think it's great and it makes me appreciative of open source and Zope's 
component oriented culture that makes it possible.

We can't just fork everything and branch off into our direction 
everywhere however; these projects will share a common codebase.

This common codebase needs to be managed and have a direction, taking as 
inputs the needs of the projects using them.

Gary Poster wrote:
 Moreover, if you are willing to step up and declare that you are  
 starting something called the Zope Framework that manages a known  
 good set of code, and you hope other projects and people join in and  
 help, that makes sense to me.  

The open source mantra: those who take responsibility get responsibility

I agree very much with that.

It might be we are able to establish a framework team without 
elections by just picking out the bunch of people who are interested in 
this. Of course if we have a significant fraction of our community who 
disagrees with the authority to make decisions for larger changes in 
these components, we still have a problem. Two diverging branches of the 
same package doesn't seem to be a maintainable situation; at some point 
someone is going to make a release with a single version number.

That's why I don't think I or anyone else can just do it without 
reaching a bit of wider consensus first. I think we have a transition 
problem to get from where we are now, where everybody and nobody is 
recognized, to a generally recognized group with some authority to make 
decisions where needed and provide guidance that should be taken into 
account.

  With what I've seen on the Grok list,
  you can do a great job as a project leader, generally being positive,
  open, and motivating.

Thanks! I have my flaws, but I try to be aware of them. :)

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martijn Faassen
Hey,

Stephan Richter wrote:
[snip]
 Actually Martijn tried to be better than that. :-) Instead of just forming a 
 steering group (which I would interpret as a Zope project) and announcing it 
 to the community, he asked for feedback first. :-)

Thanks. :)

 I probably agree he should have just done it by gathering the various release 
 managers. BTW, in one of my original responses, I proposed to Martijn that 
 the steering group should be mostly the release managers plus one or two 
 strong developers so that the group reaches an odd number.

I'm not convinced such a group could provide the kind of leadership I'm 
looking for. It'd like something a bit more agile.

 Beyond that, I didn't say my other smaller thought, which was that I  
 think the KGS should ideally be looser and more flexible than what  
 Martijn described.  If you have a project that wants in on the KGS,  
 great, you can add it.
 
 That is the case right now and I think a steering group would be pretty open 
 to additions.
 
 However, I think Martijn made a much more important point. What he wants, if 
 I 
 understood him correctly, is more of an organization around a hierarchy of 
 KGSs. The reason for this is that Zope/Plone, grok, and Zope 3 AS all share a 
 common core and maybe a coreplus set. Then each sub-project maintains a KGS 
 on top of that with their specific extensions.

Yes, I think eventually we will end up with a hierarchy of KGSes. I 
think we still need to delineate what a Steering Group or Framework Team 
actually has authority over, so that would define the Zope Framework. I 
think we should start with something quite inclusive there. One of the 
goals of the project would be to whittle it down to something smaller 
and more comprehensible. Which in turn might make space for wholesale 
replacement with newer libraries.

Anyway, what is the Zope Framework is determined organically and changes 
slowly over time.

 (1) This will make interoperability much easier, since I could potentially 
 use 
 grok X.Y in Zope 2.Z without worrying about version conflicts. 

I don't think it'll ever be perfect. Grok 1.0x for instance looks like 
it needs a newer version of zope.publisher than is in the Zope 3.4 KGS 
in order to function.

But the *more* similar these lists are, the better. This common ground 
brings us community.

[snip]
 (1) Tests that pass in isolation might not pass in a complete run.

And vice versa! We spent quite a bit of time to make tests work in 
isolation and have compattest infrastructure for it now.

 This might 
 be due to this or another packages incomplete teardown. (Several people spent 
 weeks getting this right for the 3.4 KGS.)
 
 (2) A new release of one package might break 5 others. Who is responsible for 
 updating the 5 breaking packages. The author that just released the new 
 package or the ones from the 5 others? What if those other packages do not 
 have clear, single maintainers (e.g. zope.*)?
 
 I am not making up these cases. They are real and they exist today. The idea 
 that one package has 1 or more concrete and devoted authors is simply not 
 real in the Zope world of 200+ packages.

Definitely. Changes in one package have repercussions in a huge amount 
of other packages. When we did dependency refactoring we'd need to reach 
out to many other packages to update *their* dependencies. Sometimes we 
couldn't even get the tests to run properly in the original package 
before doing so, as otherwise the wrong pre-refactored package would be 
imported from. :)

On the other hand we should of course recognize that some of these 
packages do work in isolation, and move towards a dependency structure 
and code organization that creates more such work by themselves 
packages. That's what the dependency refactoring project is all about.

We need a balance of a good integrated experience and a good stand-alone 
experience.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Simon Michael
Boy, there's no point in trying to outrun this thread, I'd better just 
jump in here. Martin I think you said that very well and I'm convinced.
I appreciate and generally support Martijn's proposal. When in doubt,
I'd be in favour of emulating what's been shown to work in the Plone 
community - eg lightweight per-release teams. I guess a responsive, 
transparent steering group with slower turnover can also be useful, though.

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Martijn Faassen wrote:
 Paul Everitt wrote:
 On 3/2/09 10:13 PM, Martin Aspeli wrote:
 We recognised that there was a problem in trying to make sure we
 represented the interests of various stakeholders, and that we needed
 someone to think big picture in terms of what technologies we adopted
 and how we used them.
 Just to be clear, I believe the Plone framework team has specifically 
 disavowed management of Plone's strategy.  Meaning, they approve PLIPs 
 on a release-to-release basis.  They don't make edicts like replace 
 Archetypes.

 This was the vacuum that the strategic planning summit advertised 
 itself as addressing.

 I think this clarification is informative to Martijn's discussion.
 
 That's interesting indeed.
 
 It's hard to know whether Plone's method of a strategic planning 
 summit is working on the long term as you only had one as far as I 
 know.

Different participants will report differently about the success, no
doubt.  One unexpected outcome (for some) was classifying the
decisions taken at the PSPS as advisory, just talk, etc:  having
no force in governing the more tactical decisions.

 (though I did hear positive news about it). I do have the 
 impression the framework team strategy works reasonably well; it's been 
 operating for about 2 releases now?

It works as a way of sharing the load with the release manager.  Because
its members don't feel empowered to make longer-term decisions, I don't
think it quite fits the model you have proposed for a steering group.

 So you have one mechanism to set long term directions (and I think 
 another one, namely Alexander Limi), and another to execute these long 
 term directions and make smaller decisions in the light of them.

In effect, Hanno Schlicting is doing the long-term direction setting
as the Plone4 release manager:  Limi is basically cheering him on.

 In reality of course a lot of micro decisions can result in a long term 
 direction, so there's a gray area there.
 
 For the Zope Framework I think it's more important to get the day to day 
 decision making working in our community than it is to do the long term 
 setting of directions and planning. We do have some form of long term 
 direction emerging that we can recognize often enough (though we can do 
 a lot better still). The core problem in my mind is the day to day 
 decision making and channeling of energies.

Here is where I think we differ:  I can't imagine the group you are
sketching out having much of *any* impact on day-to-day stuff.  In
particular, I don't believe that a BDFL (whether an individual or a
group) channels energies:  mostly, the BDFL serves as a court of
final appeal when the developers can't reach consensus.

 I myself am inclined, for the Zope Framework, to start with the day to 
 day team. I think it can deduce at least some long term directions from 
 the community on the mailing list and usage in practice (also by 
 consultation). We could amend such a process with a strategic planning 
 summit construction, later.

If the team you are talking about is going to manage a root KGS, or
something, from which Zope2, Zope3, Grok, etc. derive their own
versions, then it seems to me that success lies in keeping that KGS
smaller than larger, and focused mostly on the libraryin bits.
Expanding the core KGS later will be lots easier than shrinking it.


Tres.
- --
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFJrXI/+gerLs4ltQ4RAvf1AKCpRxuSfU6pOzhv5GNCwoOioZwmCwCgsXK/
M7L/DTDqiGyu/lhdBw56e2s=
=vnGh
-END PGP SIGNATURE-
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martijn Faassen
Hi there,

Chris McDonough wrote:
 Martijn Faassen wrote:
 Martin Aspeli wrote:
 [snip]
 You and I had a discussion a while back about forking the zope.component 
 ZCML directives, and how it would've been better to work within the 
 boundaries of the Zope packages so that everyone who wanted to lose the 
 zope.security dependency could benefit, rather than fork this and all 
 other configuration that depends on the core ZCML directives. 
 
 As I remember it, you scolded me about doing it, then when I did it anyway, it
 worked its way over to the Grok list, where any alternate idea other than a
 plain fork died on the vine.  That's what I figured was going to happen, so 
 I'm
 glad I actually took action.

Huh? We need a refactored zope.component for the Grok project as well. 
Why did it die on the vine? Perhaps if someone had been integrating 
these experiences and requirements properly on zope-dev it'd have 
transformed into positive improvements in zope.component itself by now.

[snip]
 Frankly, I don't care that I had to create alternative ZCML directives.  This
 was, and is, and always will have been, the right thing to do.  In fact, the
 only thing preventing Grok or anyone else from using the stuff created out of
 that effort wholesale (repoze.zcml) is the *brand*. 

That's incorrect. We already have an implementation of alternate 
directive (aka grokkers) to register the zope.component components in 
grokcore.component, and have had them for much longer than you did.

Adding a *third* way to configure components, i.e. repoze.zcml, to the 
mix is hardly going to improve matters for Grok. It's useless anyway as 
we need to support the zope.component[ZCML] way anyway for ZCML, and 
support grokcore.component for code that does it the Grok way.

I'd rather have one underlying action API that did the minimal but right 
thing in zope.component that grokcore.component and repoze.zcml and the 
Zope Framework (with its additional requirements for security) can all 
build on.

Switching over to repoze.zcml would only gain Grok *more* code and a 
harder to comprehend situation.

And you think it's all due to the brand...

 I don't care about
 Zope-the-brand anymore, I just care about Zope-the-technologies.  Why would 
 the
 fact that this more reasonable set of directives is not named Zope anymore
 matter?  What about that whole situation was not a win?

I already spelled out the above on the grok-dev mailing list before, but 
you didn't seem to pick up on my explanation.

 When I brought up the issue of trying to improve zope.component 
 recently, I got a lot of divergent feedback and nothing happened. It'd 
 be nice if instead such energy instead resulted in a concrete set of 
 actions.
 
 I didn't participate because I had already scratched that particular itch.  I
 created something that *everyone* can use; it might not be named Zope, so be 
 it.

I pointed out above why it'd be not very useful for Grok to use it. In 
fact you created something that is redundant if you use the rest of the 
Zope Framework as well (or even just zope.component[zcml]). It isn't 
something that *everybody* can use just like that.

Forking is one way to solve the problem and forget about it, if you 
don't care about compatibility with the Zope Framework. That's fine. 
It's something you have the freedom to do of course and undoubtedly you 
are much happier with it. It's also unfortunate for me, as your 
improvements are not making in into the shared component.

So while the problem is solved for you, it isn't solved for me. Grok has 
different goals concerning compatibility with the Zope Framework, and 
therefore more interest in improving the underlying framework itself.

These are different philosophies. You with your philosophy should have 
no problem with me trying to improve the framework experience though, as 
you can go off on your own anyway and cooperate on bits of it whenever 
you want. So I find it frustrating to hear you say no so much now.

It's fine if you don't care about the Zope brand anymore, but I'm 
still allowed to care about it, right?

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Martijn Faassen
Tres Seaver wrote:
[snip]
 (though I did hear positive news about it). I do have the 
 impression the framework team strategy works reasonably well; it's been 
 operating for about 2 releases now?

 It works as a way of sharing the load with the release manager.  Because
 its members don't feel empowered to make longer-term decisions, I don't
 think it quite fits the model you have proposed for a steering group.

Okay, that's interesting. Undoubtedly some ideas about long term 
direction sneak into a framework team to guide them with decision 
making, but it's not exactly the same model indeed.

 So you have one mechanism to set long term directions (and I think 
 another one, namely Alexander Limi), and another to execute these long 
 term directions and make smaller decisions in the light of them.
 
 In effect, Hanno Schlicting is doing the long-term direction setting
 as the Plone4 release manager:  Limi is basically cheering him on.

Ah, so Plone currently has long term direction as they think 2 releases 
ahead of just one?

I guess my proposed Steering Group would take on some of the aspects of 
both. I think you could set up a Steering Group per release with a bit 
more mandate to cover long term directions than perhaps the Plone group 
has. There'll be continuity as some of the membership will carry on to 
the next release typically.

 In reality of course a lot of micro decisions can result in a long term 
 direction, so there's a gray area there.

 For the Zope Framework I think it's more important to get the day to day 
 decision making working in our community than it is to do the long term 
 setting of directions and planning. We do have some form of long term 
 direction emerging that we can recognize often enough (though we can do 
 a lot better still). The core problem in my mind is the day to day 
 decision making and channeling of energies.
 
 Here is where I think we differ:  I can't imagine the group you are
 sketching out having much of *any* impact on day-to-day stuff.  In
 particular, I don't believe that a BDFL (whether an individual or a
 group) channels energies:  mostly, the BDFL serves as a court of
 final appeal when the developers can't reach consensus.

Okay, I guess we do differ here. I think a leader can provide 
encouragement and stimulate people into action, point out interesting 
outstanding tasks, and make sure that people who are motivated actually 
get grip on improving the project and don't get discouraged. Of course 
all these things only happen *some* of the time. It's hardly magic. But 
it does contribute in my experience.

 I myself am inclined, for the Zope Framework, to start with the day to 
 day team. I think it can deduce at least some long term directions from 
 the community on the mailing list and usage in practice (also by 
 consultation). We could amend such a process with a strategic planning 
 summit construction, later.
 
 If the team you are talking about is going to manage a root KGS, or
 something, from which Zope2, Zope3, Grok, etc. derive their own
 versions, then it seems to me that success lies in keeping that KGS
 smaller than larger, and focused mostly on the libraryin bits.
 Expanding the core KGS later will be lots easier than shrinking it.

I agree the end product should be smaller rather than larger and more 
library-like.

But it should also be concerned with turning a larger set of libraries 
into better libraries. Imagine we had defined the KGS to contain zope.* 
and not zope.app.* back in december 2008. It wouldn't have had a 
container implementation, which I think is an interesting piece of 
shared technology. If we did it today we'd have had zope.container. 
That's why I think it should start inclusive and then focus heavily on 
turning it into a better set of libraries.

In my mind such a turn it into a better collection of libraries is one 
of the most important long-term activities for the framework developers. 
I think that's something everybody can be on board about. In the end 
it's a tree of packages where people should be able to participate at 
any node, but I do think we need to keep an overview of the tree as well.

Regards,

Martijn

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Matthew Wilkes

On 3 Mar 2009, at 18:25, Martijn Faassen wrote:

 Ah, so Plone currently has long term direction as they think 2  
 releases
 ahead of just one?

Plone 4 discussions are happening around now, there are demos of  
suggested concepts and people generally working on the codebase.   
Plone 5 is a long way off, but we have some ideas, for example Hanno  
has already suggested it should target Python 3.x.  2 major releases  
in the Plone world is about 3/4 years.

Matt
(Proud Plone 4 Framework team member, ftr)

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


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Lennart Regebro
On Tue, Mar 3, 2009 at 19:09, Tres Seaver tsea...@palladion.com wrote:
 Different participants will report differently about the success, no
 doubt.  One unexpected outcome (for some) was classifying the
 decisions taken at the PSPS as advisory, just talk, etc:  having
 no force in governing the more tactical decisions.

I don't remember us actually doing any tactical decisions. There was
discussions, and to a large part consensus about these, but not actual
decisions. The end result of the PSPS was a bunch of actions, entered
into the bugtracker, and people assigned to them. These were sometime
connected to tactical decisions, but not decisions per se.

I may misremember, but in any case, this to me seems (in retrospect)
as a good idea, as complaints at that time was raised that it wasn't
inclusive enough, which would have been a problem if it really was a
decision making meeting. Instead it functioned as a way to get the
contributors focused and if not on the same page then at least in the
same book, and get energy into the group. As such, I thought it was a
success. And fun. And I learnt a cool way to run meetings. :)


I do think that this, together with day-to-day release teams is a good
working solution we should try for Zope too.

-- 
Lennart Regebro: Pythonista, Barista, Notsotrista.
http://regebro.wordpress.com/
+33 661 58 14 64
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Chris McDonough
Martijn Faassen wrote:
 Hi there,
 
 Chris McDonough wrote:
 Martijn Faassen wrote:
 Martin Aspeli wrote:
 [snip]
 You and I had a discussion a while back about forking the zope.component 
 ZCML directives, and how it would've been better to work within the 
 boundaries of the Zope packages so that everyone who wanted to lose the 
 zope.security dependency could benefit, rather than fork this and all 
 other configuration that depends on the core ZCML directives. 
 As I remember it, you scolded me about doing it, then when I did it anyway, 
 it
 worked its way over to the Grok list, where any alternate idea other than a
 plain fork died on the vine.  That's what I figured was going to happen, so 
 I'm
 glad I actually took action.
 
 Huh? 

Sorry, the you above in you scolded was Martin Aspeli, not Faassen.

 We need a refactored zope.component for the Grok project as well. 
 Why did it die on the vine? Perhaps if someone had been integrating 
 these experiences and requirements properly on zope-dev it'd have 
 transformed into positive improvements in zope.component itself by now.

AFACIT, you (meaning Faassen) wanted to focus on lower-hanging fruit at the
time: http://mail.zope.org/pipermail/grok-dev/2008-December/006946.html  (which
I believe was totally reasonable).

 [snip]
 Frankly, I don't care that I had to create alternative ZCML directives.  This
 was, and is, and always will have been, the right thing to do.  In fact, the
 only thing preventing Grok or anyone else from using the stuff created out of
 that effort wholesale (repoze.zcml) is the *brand*. 
 
 That's incorrect. We already have an implementation of alternate 
 directive (aka grokkers) to register the zope.component components in 
 grokcore.component, and have had them for much longer than you did.
 
 Adding a *third* way to configure components, i.e. repoze.zcml, to the 
 mix is hardly going to improve matters for Grok. It's useless anyway as 
 we need to support the zope.component[ZCML] way anyway for ZCML, and 
 support grokcore.component for code that does it the Grok way.

I also mentioned or anyone else above; the point is just to reduce
inappropriate dependencies.  Inappropriate dependencies still remain in
zope.component's implementation of these ZCML directives.  These inappropriate
dependencies are shed when you want ZCML and you use repoze.zcml.  Fine, Grok
may not need it because it just doesn't care about ZCML at all; but other people
who want to use ZCML without the other kitchen sinkness do.

 I'd rather have one underlying action API that did the minimal but right 
 thing in zope.component that grokcore.component and repoze.zcml and the 
 Zope Framework (with its additional requirements for security) can all 
 build on.

Why does it *have* to be in zope.component?  What magic does this name imply?

 Switching over to repoze.zcml would only gain Grok *more* code and a 
 harder to comprehend situation.

Maybe *Grok* doesn't need it, but given that an application needs some ZCML to
kick off the loading of components, and given that this ZCML needs to include
one of the utility, adapter or subscriber directives, *eventually* you
could ditch zope.security, zope.location, zope.publisher, zope.traversing,
zope.i18n, and pytz by using repoze.zcml directives instead of the ones built in
to zope.component.

Here's an example of a non-Zope application that might make use of such a
package:  http://plope.com/Members/chrism/pluginizing_an_app

 And you think it's all due to the brand...

Yes!  Someone who *wants* to use basic ZCML directives but doesn't want
zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and
pytz can *already* use repoze.zcml; the only thing they don't get here is the 
brand.

Why should we punish the folks who are already using the zope.component
directives with security in them by changing them in order to service some goal
of fidelity with brand?  Who cares what it's called?

 I don't care about
 Zope-the-brand anymore, I just care about Zope-the-technologies.  Why would 
 the
 fact that this more reasonable set of directives is not named Zope anymore
 matter?  What about that whole situation was not a win?
 
 I already spelled out the above on the grok-dev mailing list before, but 
 you didn't seem to pick up on my explanation.

I guess not.

 When I brought up the issue of trying to improve zope.component 
 recently, I got a lot of divergent feedback and nothing happened. It'd 
 be nice if instead such energy instead resulted in a concrete set of 
 actions.
 I didn't participate because I had already scratched that particular itch.  I
 created something that *everyone* can use; it might not be named Zope, so be 
 it.
 
 I pointed out above why it'd be not very useful for Grok to use it. In 
 fact you created something that is redundant if you use the rest of the 
 Zope Framework as well (or even just zope.component[zcml]). It isn't 
 something that *everybody* can use just like that.

Re: [Zope-dev] the Zope Framework project

2009-03-03 Thread Paul Everitt
On 3/3/09 2:42 PM, Chris McDonough wrote:
 Martijn Faassen wrote:
 And you think it's all due to the brand...

 Yes!  Someone who *wants* to use basic ZCML directives but doesn't want
 zope.security, zope.location, zope.publisher, zope.traversing, zope.i18n, and
 pytz can *already* use repoze.zcml; the only thing they don't get here is the 
 brand.

If we change the word brand to megaframework, things might become 
clearer.

Grok makes framework decisions based on getting value from the Zope 3 
platform. So what if our configuration language sucks in zope.location 
and pytz, we needed it anyway in our megaframework!  This view likely 
represents the (indeterminately sized) population of Zope insiders.

Repoze doesn't have fidelity to the Zope 3 megaframework as its goal. 
I asked for a configuration parser and you sucked in a security model, 
WTF!!  As such, Repoze probably wants something more like 
Zope-the-library than Zope-the-megaframework.  This view likely 
represents the (indeterminately sized) population of Zope skeptics.

Which group wins when there's a tie in the Zope Framework?  It will be 
interesting to see.

I think there's also a point about the brand related to how diluted 
the word Zope has become, but that is a second point to the 
megaframework/platform discussion.

--Paul

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


  1   2   >