[Zope-dev] Zope 3.4 final schedule?
Hi, I asked already six weeks ago about the schedule for the final 3.4 release and got no reply so far. So once again the same question...how is in charge for doing the 3.4 release? Thanks, Andreas pgp51ZKZkiEQk.pgp Description: 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] Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.
On Apr 18, 2008, at 12:47 PM, Stephan Richter wrote: On Friday 18 April 2008, Jim Fulton wrote: Because of ExtJS licensing issues, we should not check anything into the repository that builds on or requires ExtJS in any way. I assume you got lawyer advice; No. can you elaborate with a few more sentences why? I could, but I'd rather not. I suggest reading: http://mjg59.livejournal.com/84586.html if you haven't already. Jim -- Jim Fulton Zope Corporation ___ 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] Re: Proposal: Merge philikon-aq branch into Zope trunk
Martin Aspeli wrote: Hanno Schlichting wrote: Philipp von Weitershausen wrote: Hanno Schlichting wrote: Merging it into Zope trunk will get it into the Zope 2.12 release which is at this point not scheduled yet, but is unlikely to get a release before early 2009. This should give us plenty of time to test. This sounds good. Here's another idea, though: In accordance with "release early and often", how about scheduling the 2.12 release shortly after the 2.11 one? So the only "new" thing in 2.12 would be the philikon-aq branch (it would still ship with the same Zope 3 libraries as 2.11, etc.). I suspect we want to do something about the eggification story of Zope 2 for Zope 2.12 as well. Figuring out the approach and documenting it might take some additional time. I don't see that releasing another Zope 2.13 shortly after 2.12 makes a lot of sense. Why don't we get started on that, too, then? I think eggification of Zope 2 is relatively easy, and most of the necessary R&D has already been done. In fact, a lot of the eggs exist already. I wonder if Philipp would be amenable to writing a proposal on this, and get Chris McDonough's input. IMO, a Zope2 egg release should depend on the following packages: - 'ZODB3' (already packaged) - 'transaction' (depended on by newer ZODBs) - 'ZConfig' (also depended on by newer ZODBs) - 'StructuredText' (should be broken out into its own egg) - 'docutils' (should use existing egg) - 'mechanize' (should use existing egg) - 'pytz' (should use existing egg) - all zope.* packages (properly pinned) that zope2 depends on The actual top-level egg that depends on these things would contain all the other packages depended on by Zope 2 (e.g. DateTime, Missing, Products/*, Acquisition, ExtensionClass, ZPublisher, ZServer, etc). We might call it 'zope2libs'. What needs to get worked out is the ability to share headers between ZODB and this package so things can compile properly. - 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] Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.
On Friday 18 April 2008, Jim Fulton wrote: > Because of ExtJS licensing issues, we should not check anything into > the repository that builds on or requires ExtJS in any way. I assume you got lawyer advice; can you elaborate with a few more sentences why? (I did read their license stuff last night and also the relevant sections of the LGPL.) 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 )
[Zope-dev] Re: Proposal: Merge philikon-aq branch into Zope trunk
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Philipp von Weitershausen wrote:
> Tres Seaver wrote:
>>> The second problem that might arise, is that the implicit assumption
>>> that every object inside Zope 2 inherits from Acquisition base classes
>>> no longer holds. Code that relies on the various aq_* attributes to be
>>> there need to be adjusted to use the Acquisition methods instead.
>> The major downside here is that restricted code doesn't have access to
>> the required functions ('aq_inner', 'aq_parent', 'aq_acquire'), and
>> hence use the attributes. ('aq_base' should not be allowewd at all, as
>> it strips away security context).
>>
>> There are probably thousands (or even tens of thousands) of templates
>> and scripts "in the wild" which use these attributes. I don't think we
>> can break them in a single release: we need to deprecate them first
>> (with suitalbe logging output), and maybe even provide
>> '__parent__'-aware workarounds / fallbacks in their implementations.
>
> Here's the deal:
>
> * Instances of (subclasses of) Acquisition.Implicit and .Explicit still
> have those aq_* attributes. So basically all content objects still have
> them, no change there.
>
> * Five's BrowserView class doesn't inherit from Acquisition.Explicit
> anymore, but we've provided the aq_* attributes for backward
> compatibility. So if a template does view/aq_parent, it will still work
> (we have tests for this). We haven't set an expiry date for this BBB,
> nor are we logging a warning. We probably should, though, if we
> eventually want to phase out Five's BrowserView class.
>
>
> So, off the line there's no backward-compatibility problem. Now if
> people decide to implement their content objects without Acquisition
> (which they now can), then it's their problem if their templates still
> do obj/aq_*. This can be alleviated with a mix-in that Five has, which
> makes classes regain the aq_* attributes. Not sure if we want to make
> this public in any way, currently it's basically used for BrowserView
> and ViewletBase.
I realized after I sent it that BBB was "automatic" for the content
objects, making only views a possible issue: I'm glad to learn that the
views have the attributes available. I would recommend a "perpetual
deprecation" for the view BBB (log the warning with a note of the
recommended change, but don't indicate a removal release).
In any case, given the clarification, +1 to the merge.
Tres.
- --
===
Tres Seaver +1 540-429-0999 [EMAIL PROTECTED]
Palladion Software "Excellence by Design"http://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iD8DBQFICKz6+gerLs4ltQ4RAqI9AJ9wWjhsca8iljbeb8z77eHMHgBv/gCdHfa4
SkkZqvDRAxPLPicSQM8ZCPQ=
=o+xz
-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] Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.
On Apr 18, 2008, at 4:28 AM, Baiju M wrote: Paul Carduner wrote: Log message for revision 85449: creating a branch to see what I can do about extjs integration. I found Jim removing two of his extjs related libraries from svn due to license issues (r85246, r85248). Please make sure that there is no license issue for your work committed to svn. Since extjs is released under LGPL, I guess you can release the library in a similar license, but only ZPL licensed thing can be committed to our svn :( Because of ExtJS licensing issues, we should not check anything into the repository that builds on or requires ExtJS in any way. Jim -- Jim Fulton Zope Corporation ___ 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] Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.
On Apr 18, 2008, at 14:09 , Stephan Richter wrote: On Friday 18 April 2008, Wichert Akkerman wrote: There is still an ongoing debate about that even - the extjs authors basically only want to offer LGPL to you if you meet certain criteria but won't allow you to redistribute it with just standard LGPL licensing. I just researched this a little bit and can see why there is controversy. However, I cannot see why I cannot check code in that does something with extjs, because I might have paid for a license, but still want to contribute my code under ZPL. Since I am not modifying the library in any way, I do not even have to make the code LGPL. Are you a lawyer? No? Thought so ;-) jens ___ 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] Re: Proposal: Merge philikon-aq branch into Zope trunk
Tres Seaver wrote:
[snip]
The second problem that might arise, is that the implicit assumption
that every object inside Zope 2 inherits from Acquisition base classes
no longer holds. Code that relies on the various aq_* attributes to be
there need to be adjusted to use the Acquisition methods instead.
The major downside here is that restricted code doesn't have access to
the required functions ('aq_inner', 'aq_parent', 'aq_acquire'), and
hence use the attributes. ('aq_base' should not be allowewd at all, as
it strips away security context).
There are probably thousands (or even tens of thousands) of templates
and scripts "in the wild" which use these attributes. I don't think we
can break them in a single release: we need to deprecate them first
(with suitalbe logging output), and maybe even provide
'__parent__'-aware workarounds / fallbacks in their implementations.
I'm trying to understand what is proposed that would break them. All
existing content objects will continue to use acquisition. Only things
like Five views will stop using acquisition and switch to a __parent__
pointer. I doubt there are that many scripts that rely on getting a
.aq_parent, say, on a Five view. There will be view code that relies on
this, so I imagine we expect that should be rewritten to use the
functions instead, but not scripts.
If we were to change OFS so that it'd start using __parent__ then I can
see where you're coming from, but I don't think anyone's proposing that?
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] Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.
On Friday 18 April 2008, Wichert Akkerman wrote: > There is still an ongoing debate about that even - the extjs authors > basically only want to offer LGPL to you if you meet certain criteria > but won't allow you to redistribute it with just standard LGPL > licensing. I just researched this a little bit and can see why there is controversy. However, I cannot see why I cannot check code in that does something with extjs, because I might have paid for a license, but still want to contribute my code under ZPL. Since I am not modifying the library in any way, I do not even have to make the code LGPL. 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] Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.
Previously Baiju M wrote: > Since extjs is released under LGPL, I guess you can release the library in a > similar license, but only ZPL licensed thing can be committed to our svn :( There is still an ongoing debate about that even - the extjs authors basically only want to offer LGPL to you if you meet certain criteria but won't allow you to redistribute it with just standard LGPL licensing. That and the fact that extjs produces insane html (11 nested divs for a simple table...) was reason for me to not use it. Wichert. -- Wichert Akkerman <[EMAIL PROTECTED]>It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ 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] Zope Tests: 5 OK
Summary of messages to the zope-tests list. Period Thu Apr 17 11:00:00 2008 UTC to Fri Apr 18 11:00:00 2008 UTC. There were 5 messages: 5 from Zope Tests. Tests passed OK --- Subject: OK : Zope-2.8 Python-2.3.6 : Linux From: Zope Tests Date: Thu Apr 17 21:00:05 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009420.html Subject: OK : Zope-2.9 Python-2.4.4 : Linux From: Zope Tests Date: Thu Apr 17 21:01:35 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009421.html Subject: OK : Zope-2.10 Python-2.4.4 : Linux From: Zope Tests Date: Thu Apr 17 21:03:05 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009422.html Subject: OK : Zope-2.11 Python-2.4.4 : Linux From: Zope Tests Date: Thu Apr 17 21:04:36 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009423.html Subject: OK : Zope-trunk Python-2.4.4 : Linux From: Zope Tests Date: Thu Apr 17 21:06:06 EDT 2008 URL: http://mail.zope.org/pipermail/zope-tests/2008-April/009424.html ___ 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] Re: Proposal: Merge philikon-aq branch into Zope trunk
Tres Seaver wrote:
The second problem that might arise, is that the implicit assumption
that every object inside Zope 2 inherits from Acquisition base classes
no longer holds. Code that relies on the various aq_* attributes to be
there need to be adjusted to use the Acquisition methods instead.
The major downside here is that restricted code doesn't have access to
the required functions ('aq_inner', 'aq_parent', 'aq_acquire'), and
hence use the attributes. ('aq_base' should not be allowewd at all, as
it strips away security context).
There are probably thousands (or even tens of thousands) of templates
and scripts "in the wild" which use these attributes. I don't think we
can break them in a single release: we need to deprecate them first
(with suitalbe logging output), and maybe even provide
'__parent__'-aware workarounds / fallbacks in their implementations.
Here's the deal:
* Instances of (subclasses of) Acquisition.Implicit and .Explicit still
have those aq_* attributes. So basically all content objects still have
them, no change there.
* Five's BrowserView class doesn't inherit from Acquisition.Explicit
anymore, but we've provided the aq_* attributes for backward
compatibility. So if a template does view/aq_parent, it will still work
(we have tests for this). We haven't set an expiry date for this BBB,
nor are we logging a warning. We probably should, though, if we
eventually want to phase out Five's BrowserView class.
So, off the line there's no backward-compatibility problem. Now if
people decide to implement their content objects without Acquisition
(which they now can), then it's their problem if their templates still
do obj/aq_*. This can be alleviated with a mix-in that Five has, which
makes classes regain the aq_* attributes. Not sure if we want to make
this public in any way, currently it's basically used for BrowserView
and ViewletBase.
___
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] Re: [Checkins] SVN: z3c.formjs/branches/pcardune-extjs/ creating a branch to see what I can do about extjs integration.
Paul Carduner wrote: Log message for revision 85449: creating a branch to see what I can do about extjs integration. I found Jim removing two of his extjs related libraries from svn due to license issues (r85246, r85248). Please make sure that there is no license issue for your work committed to svn. Since extjs is released under LGPL, I guess you can release the library in a similar license, but only ZPL licensed thing can be committed to our svn :( /me wonder what will become a library and application from the pont of view of LGPL and Javascript. Regards, Baiju M P.S: CCed to zope-dev to see if there is any other opinion. ___ 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 )
