Hey JW,
Jan-Wijbrand Kolman wrote:
I'm spending some time on making zc.recipe.zope3instance run properly on
Windows. There're at least two issues to sort out:
1) Usually(?) Zope-3 is installed using the *.msi installer on Windows.
The recipe should look in the "Scripts" sub directory of th
Hey Christian,
[using launchpad fo rmore than just bug tracking]
I'm assuming silence from everybody is permission. :)
Regards,
Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mai
Chris Withers wrote:
Does anyone have any experience of using zope.testing outside of Zope?
Yes, I do. It's really easy with buildout, actually.
I use zope.testing.doctest for the Twiddler tests and I'd like to use
zope.testing.testrunner for running the tests in a "plain python"
environment
Rocky Burt wrote:
On Wed, 2006-20-12 at 12:52 +0100, Martijn Faassen wrote:
http://genshi.edgewall.org
Inspired by Kid (in turn among others inspired by ZPT), the main
template language of TurboGears, written by the people who also created
Trac, and it seems to be getting traction
Jim Washington wrote:
Martijn Faassen wrote:
http://genshi.edgewall.org
Inspired by Kid (in turn among others inspired by ZPT), the main
template language of TurboGears, written by the people who also
created Trac, and it seems to be getting traction. TurboGears among
others is going to
Christian Theune wrote:
Hi,
I've updated the spring cleaning proposal with the suggestions (and
additional votes from people posting in this thread).
I think it's a good idea to let anything that has any vote *against*
removing from the core stay in the core for now (unless someone goes
insa
Roger Ineichen wrote:
Hi Martijn
Subject: [Zope3-dev] Re: [SpringCleaning07]
By the way, I'm quite interested in seeing whether we can
integrate Genshi into Zope 3 and Grok as a templating
language. It has some interesting ways to do things, and
there's quite a bit of momentum behind it.
Jim Fulton wrote:
Martijn Faassen wrote:
[snip zope.interface missing]
Hm, so it was checked by setup. Dang. Well, we could hack around this
in various ways, but it wouldn't be fun.
Yes, it appears it was checked by setup.py. In my experience the
diversity of special setup.py's
Stephan Richter wrote:
[snip]
Overall, I think the first step would be to agree on a common set of UI
patterns.
From what you say below I don't think we'll be able to do that very
soon. :) I think we should agree to disagree for now and just see
whoever gets to an admin UI first (or best).
Jim Fulton wrote:
Martijn Faassen wrote:
Jim Fulton wrote:
[snip]
I'm not certain that we're actively supporting either server.
But *in practice* we're supporting the Twisted integration, as that's
the only one that people use now, right?
Wrong. Use != support.
[sn
Hey,
Tres Seaver wrote:
Jim Fulton wrote:
[snip]
If we find that WSGI is inferior to the Zope 2 server, then I certainly
think that abandoning our various Zope 3 efforts is a reasonable
alternative, although unattractive, since I'm not aware of anyone
actively maintaining the Zope 2 server. I
Jim Fulton wrote:
Chris Withers wrote:
Jim Fulton wrote:
[snip]
I find it impossible to believe that others don't have such
mission-critical requirements.
Maybe they hand off the hard bits too Apache?
Excellent suggestion, Chris, thank you!
Some of them do, I'm sure.
Could we?
Sure,
Sidnei da Silva wrote:
Anyone played with Nuxeo's 'funkload'? That's probably one of the most
interesting stress/benchmark tools out there. There are other
non-Python options too, like 'JMeter' (I believe that's the name) and
Microsoft Web Capacity Analisys Tool (free download I believe).
There
Hey,
Jim Fulton wrote:
[snip]
I'm not certain that we're actively supporting either server.
But *in practice* we're supporting the Twisted integration, as that's
the only one that people use now, right? We may not be actually capable
or willing to offer such support, but since everybody use
Stephan Richter wrote:
On Tuesday 19 December 2006 06:16, Roger Ineichen wrote:
Here is a list of candidates for removal (please verify!):
zope.dependencytool
-1, it is used by people to find dependencies in their packages. It is not
referenced anywhere in the code, because it is a standalone
Chris Withers <[EMAIL PROTECTED]> wrote:
> Martijn Faassen wrote:
>> class TemplateView(grok.View):
>> template = unassociated
>> module_info = module_info_
> I'm not sure. Debugging becomes a nightmare with generated classe
Tres Seaver <[EMAIL PROTECTED]> wrote:
[snip]
> Shouldn't the dependency information in the eggs-to-test be sufficient
> for that?
That's what I was going to say. The egg should normally just list its
own dependencies in setup.py and buildout will handle this just fine.
Regards,
Martijn
__
Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
[Chris]
>> That said, I can live with most of the crap, but these dynamically
>> generated classes... wtf? why? why did that? why are they still breathing?!
>
> *sigh* I don't know who came up with the idea, and I don't really care
> as I don'
Jim Fulton <[EMAIL PROTECTED]> wrote:
> On Dec 2, 2006, at 4:30 AM, Chris Withers wrote:
>
>> I remember Shane asking this a while ago and seem to remember the
>> answer was "no", but I'm hoping that's changed.
>>
>> Is it possible to have a Zope 3 instance that has no zodb backing
>> at all?
whit <[EMAIL PROTECTED]> wrote:
> Martijn Faassen wrote:
[snip]
> cool! awesome to see integration efforts like this!
>
> is there any difference using cherrypy's wsgi server vs. say
> paste.httpserver?
Probably not except of course in the performance characteristics
Hey,
I've recently written a few blog entries that may be of interest here
too. First an introduction about the Grok project:
http://faassen.n--tree.net/blog/view/weblog/2006/11/09/0
Next, what I wrote tonight, which is about my experiments with Grok,
Zope 3, WSGI and CherryPy:
http://faas
Christian Theune wrote:
Hi,
Martijn Faassen wrote:
originally we intended to do a Zope 3.3.1 release in November to get
virtually bug free.
I didn't see any momentum on this. How about a bug day?
I'm supposed to be the release manager for this too. I was hoping
someone else would
Martin Aspeli wrote:
Martijn Faassen wrote:
Oh, I disagree. It's much nicer to be able to be able to start with
adapting classes, and introduce interfaces later, where necessary. Often
they're not. In fact it's already possible to adapt classes and register
views for cla
Christian Theune wrote:
originally we intended to do a Zope 3.3.1 release in November to get
virtually bug free.
I didn't see any momentum on this. How about a bug day?
I'm supposed to be the release manager for this too. I was hoping
someone else would volunteer but of course I already comm
Chris Withers wrote:
Jim Fulton wrote:
I think it is a fine idea. That's why it has been supported for
a long time. You can register adapters and views (which, of course
are adapters) for classes as well as interfaces.
Hmm, just to be clear:
class A: pass
class B(A): pass
x = ISometh
Martin Aspeli wrote:
Chris Withers wrote:
I find myself often having to define pure marker interfaces for each
class that I define, purely so I can register adapters for objects of
that class.
Why does your class not have a (non-marker) interface in the first place?
The use of interfaces as
Paul Winkler wrote:
On Tue, Oct 31, 2006 at 07:54:41PM +0100, Martijn Faassen wrote:
I'm happy to see you do this. I can't make it to that PyCon, unfortunately.
As to representing other people's opinion:
Talk about Grok. Better yet, show Grok code. By that time, we should be
q
Jim Fulton wrote:
Benji York wrote:
Titus Brown is putting together a web framework panel for the next
PyCon: http://us.pycon.org/TX2007/WebFrameworksPanel.
I just stuck my name on this. :)
If someone else wants badly to do this, I'm willing to yield.
In any case, I'd like to represent some o
Adam Groszer wrote:
Hello,
I built Z3.2.2 on win32, but after installing the result and creating
an instance it fails.
I don't have a clou where and what to look for.
C:\zopeinst>bin\runzope
Error: 'formatter' is not a known key name
(line 103 in file:/C|/zopeinst/etc/zope.conf)
For help,
Carlos de la Guardia wrote:
On 9/29/06, Jim Fulton <[EMAIL PROTECTED]> wrote:
Thanks for the input. I wonder if anyone wants to volunteer to
spearhead a track prototype for zope.org? One of the things I like
about Launchpad is that I don't have to do any work. If someone is
willing to step f
Lennart Regebro wrote:
[snip]
I've never used Roundup.
[Lennart describes his experiences with JIRA]
I've used roundup for some years. In our install some metadata like
'milestone' and such are missing, but I believe those can be added. It's
pretty nice. It has very deep integration with emai
Marius Gedminas wrote:
On Fri, Sep 29, 2006 at 09:52:34AM -0400, Jim Fulton wrote:
Thanks for the input. I wonder if anyone wants to volunteer to
spearhead a track prototype for zope.org? One of the things I like
about Launchpad is that I don't have to do any work. If someone is
willing to s
Martijn Faassen wrote:
Sidnei da Silva wrote:
On Sun, Oct 01, 2006 at 09:38:21AM -0400, Jim Fulton wrote:
| | Here are some quick Trac questions. My impression is that track
projects
| need to be set up as separate applications and that separate projects
| can't be set up through the we
Sidnei da Silva wrote:
On Sun, Oct 01, 2006 at 09:38:21AM -0400, Jim Fulton wrote:
|
| Here are some quick Trac questions. My impression is that track projects
| need to be set up as separate applications and that separate projects
| can't be set up through the web. Is this right?
All of that
Carlos de la Guardia wrote:
On 9/29/06, Jim Fulton <[EMAIL PROTECTED]> wrote:
Thanks for the input. I wonder if anyone wants to volunteer to
spearhead a track prototype for zope.org? One of the things I like
about Launchpad is that I don't have to do any work. If someone is
willing to step f
Jim Fulton wrote:
Thanks for the input. I wonder if anyone wants to volunteer to
spearhead a track prototype for zope.org? One of the things I like
about Launchpad is that I don't have to do any work. If someone is
willing to step forward and commit to a Trac implementation, I'm happy
to try
Benji York wrote:
Martijn Faassen wrote:
Again, I'll repeat that I think we should *not* trying to support two
Python versions at the same time. Whether something works on a later
version of Python is beside the point; it's about whether we
officially make sure. I do not believe we
Baiju M wrote:
On 9/29/06, Baiju M <[EMAIL PROTECTED]> wrote:
On 9/29/06, Martijn Faassen <[EMAIL PROTECTED]> wrote:
> It's going to be a significant investment of work to make sure
> everything works with Python 2.5. Either someone credible steps up,
> convinces us,
Baiju M wrote:
On 9/29/06, Martijn Faassen <[EMAIL PROTECTED]> wrote:
It's going to be a significant investment of work to make sure
everything works with Python 2.5. Either someone credible steps up,
convinces us, and does the work, and we all move over to Python 2.5. If
they don&
Jeff Shell wrote:
On 9/28/06, Martijn Faassen <[EMAIL PROTECTED]> wrote:
Jim Fulton wrote:
Baiju M wrote:
Hi, What is the target Python version for Zope 3.4, is it
Python 2.5?
That's a good question. I fear it will take a fair bit of work
to get to it and, frankly for me there
Jeff Shell wrote:
On 9/28/06, Philipp von Weitershausen <[EMAIL PROTECTED]> wrote:
Christian Theune wrote:
> Morning,
>
> Baiju M wrote:
>> Hi,
>> What is the target Python version for Zope 3.4, is it Python 2.5?
>
> Right now it's still Python 2.4, as Zope 3.4 is scheduled for next
year,
>
Dieter Maurer wrote:
Philipp von Weitershausen wrote at 2006-9-28 11:22 +0200:
...
The last time this was discussed with Jim, the idea was to try to use
Zope 3's security proxy approach in Zope 2 for Python Script security
- Jim and I had some ideas I need to dredge up from the back of my
mind.
Jim Fulton wrote:
Baiju M wrote:
Hi,
What is the target Python version for Zope 3.4, is it Python 2.5?
That's a good question. I fear it will take a fair bit of work to
get to it and, frankly for me there are higher priorities.
I think we'd be okay in not supporting Python 2.5 yet for thi
Philipp von Weitershausen wrote:
Christian Theune wrote:
Morning,
Baiju M wrote:
Hi,
What is the target Python version for Zope 3.4, is it Python 2.5?
Right now it's still Python 2.4, as Zope 3.4 is scheduled for next year,
we should consider using Python 2.5 though.
We should definitely
Benji York wrote:
Martijn Faassen wrote:
Benji York wrote:
Martijn Faassen wrote:
I also consider it very important that we have at least a *list* on
zope.org of zope 3 projects. :)
I'd suggest something that links back to PyPi, like the TurboGears
GogBin: http://www.turbogear
Baiju M wrote:
On 9/22/06, Jim Fulton <[EMAIL PROTECTED]> wrote:
Finally, I'm experimenting with using launchpad for bugs:
https://launchpad.net/products/zc.buildout/+bugs
and feature requests:
https://features.launchpad.net/products/zc.buildout/
So far this is working OK. I haven't r
Benji York wrote:
Martijn Faassen wrote:
I also consider it very important that we have at least a *list* on
zope.org of zope 3 projects. :)
I'd suggest something that links back to PyPi, like the TurboGears
GogBin: http://www.turbogears.org/cogbin/
Yes, that may be enough for many o
Jim Fulton wrote:
On Sep 22, 2006, at 12:52 PM, Martijn Faassen wrote:
While I'm happy with the way this works now as it's agile, I am also
hoping that eventually we can move away from the cheeseshop as the
prime documentation site of a project; it's not ideally suited for t
Jim Fulton wrote:
On Sep 22, 2006, at 1:31 PM, Stephan Richter wrote:
On Friday 22 September 2006 12:52, Martijn Faassen wrote:
I hope we can move to a pattern where projects gain a homepage somewhere
on zope.org, including doctests and some other information, and the
cheeseshop is used for
Baiju M wrote:
On 9/22/06, Jim Fulton <[EMAIL PROTECTED]> wrote:
Finally, I'm experimenting with using launchpad for bugs:
https://launchpad.net/products/zc.buildout/+bugs
and feature requests:
https://features.launchpad.net/products/zc.buildout/
So far this is working OK. I haven't r
Hi there,
Since the advent of the 'Framework :: Zope3' trove classifier, I've
started uploading a bunch of zc.* packages to the cheeseshop. I've only
done minimal work on the setup.py by the way - volunteers are welcome to
do more documentation including after the example of zc.buildout.
To
Gary Poster wrote:
[snip]
Also, for these, we're taking the tack of "We're not ashamed of calling
it 1.0" rather than the 0.x "Oh, when will I reach perfection"
approach.
Good point. I'll be a bit more aggressive with 1.0 in the future.
Regards,
Martijn
Jim Fulton wrote:
On Sep 22, 2006, at 11:47 AM, Martijn Faassen wrote:
I am about to do a new egg release of zc.catalog and will be putting
out other eggs as well (to the cheeseshop as we now have our own
category there).
I notice in the SVN that there have been quite a few changes to
Hi there,
I am about to do a new egg release of zc.catalog and will be putting out
other eggs as well (to the cheeseshop as we now have our own category
there).
I notice in the SVN that there have been quite a few changes to
zc.catalog. We do not have any CHANGES.txt or such, so it's very ha
Jim Fulton wrote:
On Sep 21, 2006, at 11:31 AM, Stephan Richter wrote:
[snip]
This has been proposed and approved, but implementation has been
delayed due to missing XPath features.
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZCMLEnhancements
I have a feeling that xp
Stephan Richter wrote:
On Tuesday 19 September 2006 07:39, Martijn Faassen wrote:
I figured I'd let everyone here know that we'll be using the Python
distutils SIG mailing list for discussions on buildout itself in the
future. (Jim asked there and got a yes)
How is the traffic on
Hi there,
I figured I'd let everyone here know that we'll be using the Python
distutils SIG mailing list for discussions on buildout itself in the
future. (Jim asked there and got a yes)
I think that's the distutils SIG mailing list a great place to engage
non-Zope developers as well, and bu
Hey,
Philipp von Weitershausen wrote:
[snip]
Thoughts?
I don't have time for a discussion right now as I'm off to Germany soon.
The one thought that strikes me is that these release management notes,
when finalized, should be in some clear, findable, well-known and
maintained location. Othe
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
Hi there,
I understand that the 3.3.0 release is coming out next week.
As the 3.3.1 release manager volunteer, I ask everybody to do the
following:
If you find a bug in Zope 3, please try fixing it in Zope 3.3 branch
first,
No
Hi there,
I understand that the 3.3.0 release is coming out next week.
As the 3.3.1 release manager volunteer, I ask everybody to do the following:
If you find a bug in Zope 3, please try fixing it in Zope 3.3 branch
first, and then forward port it to trunk. The goal here to make sure we
fix
Hey,
Jim Fulton wrote:
[snip]
I would go further. I would not unfreeze the trunk until until we've
cleaned up all open bugs, either by fixing them or rejecting them.
-1
Why, do you think we should allow old bugs to languish forever?
I think this would be a bad thing to do after every rel
Benji York wrote:
Martijn Faassen wrote:
[snip]
What do you think about a 9 month release cycle?
If we can't manage a 6 month cycle, 9 months is the longest release
cycle I think is acceptable.
Agreed. I'd like to avoid longer than 9 months too.
Personally I think we should ju
Jim Fulton wrote:
On Sep 12, 2006, at 8:40 AM, Martijn Faassen wrote:
[snip]
One problem we have is getting things to be tested. It hardly
motivates people to test for and report bugs if their reports
don't affect he release. I think we have a serious problem that
needs to be addresse
Hey,
[posting this to zope3-dev too so the discussion thread there is
somewhat intact]
Jim Fulton wrote:
On Sep 12, 2006, at 8:32 AM, Daniel Nouri wrote:
While using buildout in our recent project[1] we have discovered that
some recipe's `install` method is being run although neither the
Andreas Jung wrote:
--On 12. September 2006 13:06:05 +0200 Martijn Faassen
<[EMAIL PROTECTED]> wrote:
Andreas Jung wrote:
--On 12. September 2006 12:28:10 +0200 Martijn Faassen
<[EMAIL PROTECTED]> wrote:
[snip]
Anyway, if the main thing holding up *this* release is bugfixes,
Jim Fulton wrote:
On Sep 12, 2006, at 5:25 AM, Martijn Faassen wrote:
[snip]
Anyway, if the Gnome project can do time-based releases *on the date*
we should be able to do it too.
Maybe they have more volunteers.
Yes. They also have a *lot* more to release. Their release story is also
Philipp von Weitershausen wrote:
Martijn Faassen wrote:
That doesn't mean we should postpone a final release over and over
again, just because we don't have the resources. In fact, because we
don't have the resources, we should release a final anyway and catch
up with bugs i
Andreas Jung wrote:
--On 12. September 2006 12:28:10 +0200 Martijn Faassen
<[EMAIL PROTECTED]> wrote:
[snip]
Anyway, if the main thing holding up *this* release is bugfixes, doing a
new release in 3 months shouldn't be a problem, as after all, we've
already fixed those bugs
Andreas Jung wrote:
since we are three month late with the current releas, it would make
sense to reschedule Zope 2.11/3.4 for July (or was it June) next yr?!
Is the reasoning here that since a release cycle has taken 9 months, so
should the next? I'm not convinced expanding the release cycle i
Philipp von Weitershausen wrote:
[snip]
Anyway, if the Gnome project can do time-based releases *on the date*
we should be able to do it too.
I bet the Gnome project has members who are actually paid to do this
kind of release management, though.
They probably have more resources than we ha
Philipp von Weitershausen wrote:
Christian Theune wrote:
what's the status on the release? We should have an RC and maybe a
release in one or two weeks.
Yup. We will be making an RC this week.
Great! I started a discussion on What Went Wrong (tm) in Christian's
roadmap thread. I'd be happy
Hi there,
Thanks for doing this work, Christian. I'm in favor of going for Zope
3.4 on a timely basis.
Concerning the delay of Zope 3.3, I think we should consider whether
we're not too perfectionistic.
On the one hand core developers seem to be happy to use the trunk for
development proje
yuppie wrote:
[snip]
Overall, I would really like to find a person for each release being
responsible for backporting bug fixes. It would be a relatively easy
way to contribute to Zope 3.
IMHO maintaining the current stable branch should be the responsibility
of all developers - if you fix a
yuppie wrote:
[snip]
I volunteer to backport some fixes I'm missing in Zope 3.2, but that's
no general solution for keeping the current stable branch maintained.
I think you bring up a very good point. Of course this also implies new
Zope 2 release which include bugfix releases of Zope 3.2. It
Martijn Faassen wrote:
Chris Withers wrote:
Lennart Regebro wrote:
I agree. And as long as you move from one version to the next, it's
not a problems, since we have BBB-code.
I'm sorry, I don't buy this. BBB code goes away, that means you have
to deal with the churn at some
Chris Withers wrote:
Lennart Regebro wrote:
I agree. And as long as you move from one version to the next, it's
not a problems, since we have BBB-code.
I'm sorry, I don't buy this. BBB code goes away, that means you have to
deal with the churn at some point. It's the churn that's the problem
Christian Theune wrote:
this is a rant. I don't want to be destructive or disruptive, but I feel
like I need to turn this up right now.
Let's start with something positive: I love Zope 3. I do. I know it
almost since the beginning and I see how it works out.
But to be honest, I too often get t
Fred Drake wrote:
On 8/25/06, Michael Kerrin <[EMAIL PROTECTED]> wrote:
What name should I use, I have seen a lot of talk on this but never
really followed any of the threads to the end. If you say use X I
will. I don't want to start another thread on this.
I think the name is fine. There ar
Hi there,
I just noticed the existence of zope.etree. Besides a minor comment on
its use of 'zope' as the namespace package, which I believe is generally
reserved for core components, I have the following more conceptual comment:
There are currently three implementations of the ElementTree AP
Lennart Regebro wrote:
On 8/25/06, Martijn Faassen <[EMAIL PROTECTED]> wrote:
I actually think it would be *nice*, if not at all essential, to have a
common namespace for community work. For such a common namespace "z3c"
is a bit unwieldier than something like "zor
Hey,
I think the fix has some steps in it:
* first, delegate everything to a IErrorReportingUtility and let it log
to SiteError as well. The SiteError logging policy is not operative anymore.
* it turns out the current IErrorReportingUtility does have some form of
filtering policy - it filte
Stephan Richter wrote:
[snip]
Also, z3c
does not try to be the holy grail of community work. It is just another
namespace and I think this should be accepted.
I actually think it would be *nice*, if not at all essential, to have a
common namespace for community work. For such a common namesp
Benji York wrote:
Stephan's ZSCP proposal suggests using the package name "z3c" for
"community" packages. IOW, packages that aren't part of a larger
collection like lovely.*, zc.*, etc.. There are currently several z3c
packages in existence.
The zope3.org packages currently use the package
Gary Poster wrote:
Zope Corporation is happy to announce a number of newly open-sourced
packages. All are in use, in development, or both.
[snip long list]
Awesome! And thanks for this announcement! And here Infrae's with only 3
hurry packages last year - I feel totally inadequate. :)
Echoi
Hi there,
See the following proposal:
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ErrorReportingUnification
To be determined is whether we want to keep the rules currently in place
for the SiteError log and apply them to the error reporting utility as
well, or remove them
Philipp von Weitershausen wrote:
[snip]
I'm +1 too, but I'm against naming this category Zope 3. I would just
call it Zope.
+1
Regards,
Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archi
Christian Theune wrote:
Martijn Faassen wrote:
Hi there,
I was making the assumption that any error that shows up in the error
reporting utility in the ZMI is also copied to the SiteError log
(typically STDOUT in a standard Zope 3 configuration), and vice versa.
This assumption is true in
Hey,
Replying to myself: if people feel like digging into things, there are
some issues that contain some context:
http://www.zope.org/Collectors/Zope3-dev/686/collector_issue_contents
I also ran into this independenly in this issue, so it contains lots of
contents on this:
http://www.zope
Hi there,
I was making the assumption that any error that shows up in the error
reporting utility in the ZMI is also copied to the SiteError log
(typically STDOUT in a standard Zope 3 configuration), and vice versa.
This assumption is true in Zope 2, where in the error_log object you can
actu
Tres Seaver wrote:
Martijn Faassen wrote:
[snip]
If the GPL is one of those included licenses, the whole package falls
under the provisions of the GPL, not just the dependencies. This is what
the GPL requires.
I'd prefer to have somebody at the foundation pay for advice on this: I
Gary Poster wrote:
[removed Checkins mailing list--maybe we can choose one list or the other?]
On Aug 16, 2006, at 10:03 AM, Martijn Faassen wrote:
And at this moment in time, Zope Corporation as far as I understand is
not bound by the same contributor's agreement we are. It&#x
Andreas Jung wrote:
--On 16. August 2006 15:42:41 +0200 Martijn Faassen <[EMAIL PROTECTED]>
wrote:
Anyway, nothing is said about dependency on GPL-ed code. That's a
different debate. It's strictly not against rules, but it does mean one
expectation is broken: one might wan
Stephan Richter wrote:
On Wednesday 16 August 2006 09:18, Benji York wrote:
That's seems to me to be an over-simplification, but I'd like to hear
what the ZF board has to say on the issue.
The ZF board should not deal with development decisions. This was my main
concern about the ZF from the
Stephan Richter wrote:
On Wednesday 16 August 2006 09:34, Benji York wrote:
BTW, zope.html, which as checked in by Gary yesterday, also contains
FCKEditor, which is LGPL. By your criteria this also should not be.
The LGPL is different than the GPL.
No, it is not when talking about this reposi
Stephan Richter wrote:
On Wednesday 16 August 2006 09:42, Martijn Faassen wrote:
Anyway, nothing is said about dependency on GPL-ed code. That's a
different debate. It's strictly not against rules, but it does mean one
expectation is broken: one might want to expect that all c
Stephan Richter wrote:
[snip]
Anything you build on top of lovely.rating can be ZPL, since
schooltool.requirement is used as a library that is not extended.
I do not understand how "is used as a library that is not extended"
affects matters? Using a GPL-ed component as a library without extend
Benji York wrote:
Stephan Richter wrote:
[snip]
In fact, the repository has many components checked in that have other
licenses including the GPL. As long as it is clearly marked and
documented, there is no problem.
That's seems to me to be an over-simplification, but I'd like to hear
what
Philipp von Weitershausen wrote:
[snip]
I'm sorely tempted to do this for 3.3.
-1
-1 too
Regards,
Martijn
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Benji York wrote:
Jim Fulton wrote:
I suggest that, for 3.4, we get rid of the PAU prefix option and
provide a generation evolution script that, for PAUs with non-empty
prefixes, just prepends their prefixes to their plugin prefixes and
clears their prefixes. I'm sorely tempted to do this
Jim Fulton wrote:
On Jul 11, 2006, at 8:05 AM, Patrick Gerken wrote:
...
As a non committer I would like to note that it was easy for me to
search if somebody already submitted a bug I found, and submit a new
patch, it was also trivial to add the for the bugfix and the test. The
only thing whic
201 - 300 of 596 matches
Mail list logo
