Martin Aspeli wrote:
[snip]
Why can't it just be
getUtility(ISession)
?
Because the internals won't let you. As I said in my reply, a Session is
not quite like a local utility. Trying to pigeonhole it that way isn't
easy. It'd need some clever component wizardry to make sessions be
created
Hi,
This post refers to Philipp's guide for `Maintaining software in the Zope
software repository` [1].
I noticed that I kept getting confused about maintaining CHANGES.txt entries
when merging bug fixes around, looked around a bit and thought I'd share my
findings.
First, I think we have a term
Some clarifications:
On Wed, Jun 18, 2008 at 12:09:27PM +0200, Christian Theune wrote:
>
> - The first section marks the next released (as specified in [1]).
Easier to read:
The first section is the 'next release' section which refers to a currently
unreleased version.
> - A change on a branch
Summary of messages to the zope-tests list.
Period Tue Jun 17 11:00:00 2008 UTC to Wed Jun 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: Tue Jun 17 21:00:36 EDT 2008
URL: http://m
On Jun 18, 2008, at 12:09 , Christian Theune wrote:
- A change on a branch is recorded in the next unreleased section.
(Merges of
the same fix over multiple branches are not recorded in different
places on
the other branches.)
This results in the following properties for the CHANGES.txt:
Christian Theune a écrit :
Hi,
This post refers to Philipp's guide for `Maintaining software in the Zope
software repository` [1].
I noticed that I kept getting confused about maintaining CHANGES.txt entries
when merging bug fixes around, looked around a bit and thought I'd share my
findings.
Hi,
On Wed, Jun 18, 2008 at 01:11:46PM +0200, Jens Vagelpohl wrote:
> Just for clarification, does this imaginary scenario describe what you
> mean?
>
> - I am fixing a problem in the 1.2-branch of my Foobar product and note
> the fix in CHANGES.txt on the 1.2-branch
>
> - I merge the fix to
Hi,
On Wed, Jun 18, 2008 at 01:23:20PM +0200, Christophe Combelles wrote:
> Hi Christian,
>
> let's take a real package as an example (on which I recently did some merges)
>
> CHANGES.txt on the trunk:
> http://svn.zope.org/zope.app.container/trunk/CHANGES.txt?rev=87370
>
> CHANGES.txt on the 3.5
On Jun 18, 2008, at 14:32 , Christian Theune wrote:
Hi,
On Wed, Jun 18, 2008 at 01:11:46PM +0200, Jens Vagelpohl wrote:
Just for clarification, does this imaginary scenario describe what
you
mean?
- I am fixing a problem in the 1.2-branch of my Foobar product and
note
the fix in CHANGES
On Jun 18, 2008, at 15:07 , Christian Theune wrote:
On Wed, Jun 18, 2008 at 02:48:22PM +0200, Jens Vagelpohl wrote:
So in essence it sounds like changes will be noted in CHANGES.txt for
*all* those branches and the trunk that they're applied to, and the
only
difference is the version numbers
On Wed, Jun 18, 2008 at 02:48:22PM +0200, Jens Vagelpohl wrote:
> So in essence it sounds like changes will be noted in CHANGES.txt for
> *all* those branches and the trunk that they're applied to, and the only
> difference is the version numbers showing in each CHANGES.txt file, with
> the tru
Christian Theune a écrit :
Hi,
On Wed, Jun 18, 2008 at 01:23:20PM +0200, Christophe Combelles wrote:
Hi Christian,
let's take a real package as an example (on which I recently did some merges)
CHANGES.txt on the trunk:
http://svn.zope.org/zope.app.container/trunk/CHANGES.txt?rev=87370
CHANGE
On Wed, Jun 18, 2008 at 10:21 AM, Christophe Combelles <[EMAIL PROTECTED]>
wrote:
> The risk is that people will think the bug is fixed in 3.6.0 and not in the
> 3.5 branch.
That's a general documentation risk, and I don't think anyone else has
come up with a better way to deal with this. If you
On Wed, Jun 18, 2008 at 11:20:17AM -0400, Fred Drake wrote:
> On Wed, Jun 18, 2008 at 10:21 AM, Christophe Combelles <[EMAIL PROTECTED]>
> wrote:
> > The risk is that people will think the bug is fixed in 3.6.0 and not in the
> > 3.5 branch.
>
> That's a general documentation risk, and I don't th
On Wed, Jun 18, 2008 at 04:21:08PM +0200, Christophe Combelles wrote:
> Something like this?
> http://svn.zope.org/zope.app.container/trunk/CHANGES.txt?rev=87519
Yup.
--
Christian Theune · [EMAIL PROTECTED]
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com
Hi!
Christian Theune wrote:
On Wed, Jun 18, 2008 at 11:20:17AM -0400, Fred Drake wrote:
On Wed, Jun 18, 2008 at 10:21 AM, Christophe Combelles <[EMAIL PROTECTED]>
wrote:
The risk is that people will think the bug is fixed in 3.6.0 and not in the
3.5 branch.
That's a general documentation ri
On Jun 18, 2008, at 19:00 , yuppie wrote:
Why do we maintain a CHANGES.txt file? Who reads it and why?
The audience I have in mind are users of released versions. They
read CHANGES.txt to figure out what's new in a release.
Let's take Zope 2 as an example:
Most people will currently use ve
Jens Vagelpohl wrote:
On Jun 18, 2008, at 19:00 , yuppie wrote:
Why do we maintain a CHANGES.txt file? Who reads it and why?
The audience I have in mind are users of released versions. They read
CHANGES.txt to figure out what's new in a release.
Let's take Zope 2 as an example:
Most people
On Wed, Jun 18, 2008 at 1:27 PM, yuppie <[EMAIL PROTECTED]> wrote:
> Sorry. I was referring to the current Zope 2 (and CMF) policy:
>
> "Note that you don't need to note the fix in the CHANGES.txt on the trunk if
> you don't want to. At the time a new feature release is made, we merge the
> items i
On Jun 18, 2008, at 19:27 , yuppie wrote:
That's not the only audience. I as a developer consult CHANGES.txt
to (hopefully) find *all* changes on the respective branch or on
the trunk that have flowed into it until now.
Can't developers use the subversion history?
It's much quicker to loo
On Jun 18, 2008, at 19:32 , Fred Drake wrote:
On Wed, Jun 18, 2008 at 1:27 PM, yuppie <[EMAIL PROTECTED]>
wrote:
Sorry. I was referring to the current Zope 2 (and CMF) policy:
"Note that you don't need to note the fix in the CHANGES.txt on the
trunk if
you don't want to. At the time a new
Hi!
Jens Vagelpohl wrote:
On Jun 18, 2008, at 19:27 , yuppie wrote:
That's not the only audience. I as a developer consult CHANGES.txt to
(hopefully) find *all* changes on the respective branch or on the
trunk that have flowed into it until now.
Can't developers use the subversion history?
Currently views are registered as components providing
zope.interface.Interface; this is unfortunate since other kinds of
components may use the same specification, namely (context, request).
An example of this is ``IAbsoluteURL``; it clashes with the resources view*.
In the words of Christian
Hi there,
Malthe Borch wrote:
[snip]
I suggest we then register views as components providing
``zope.component.IView``; browser views should provide
``zope.publisher.interfaces.browser.IBrowserView``.
I think this would improve things, and thanks for bringing this up.
There's one major probl
Hi there,
Christian Theune wrote:
[snip]
This results in the following properties for the CHANGES.txt:
- The trunk will contain sections for feature releases (e.g. 1.0, 1.1, ..) but
not bugfix releases (e.g. 1.0.2).
- Bug fixes will appear once in the feature release of the trunk (e.g. 1.1)
Martijn Faassen wrote:
There's one major problem that I see. What's the backwards compatibility
story? I'm sure there are a lot of cases in lots of code where people
look up views with a getMultiAdapter, and if we started registering
views differently, wouldn't that code break? How to we get fr
On Jun 18, 2008, at 1:44 PM, Malthe Borch wrote:
Martijn Faassen wrote:
There's one major problem that I see. What's the backwards
compatibility story? I'm sure there are a lot of cases in lots of
code where people look up views with a getMultiAdapter, and if we
started registering views
Hi,
On Wed, Jun 18, 2008 at 10:31:30PM +0200, Malthe Borch wrote:
> Currently views are registered as components providing
> zope.interface.Interface; this is unfortunate since other kinds of
> components may use the same specification, namely (context, request).
>
> An example of this is ``IA
On Wed, Jun 18, 2008 at 10:38:51PM +0200, Martijn Faassen wrote:
> And then I add a feature 'Kwack' or fix a bug 'Dag', where do I add
> them? To the top of the sections or to the bottom? I've noticed people
> do different things there, which sometimes leads to confusion (I might
> look at th
Christian Theune wrote:
I don't think zope.component wants to know about views. The interface should
be in a package that already knows about views.
I agree it's an inappropriate location, however, zope.component *does*
define an ``IView`` interface as it is (zope.component.bbb.interfaces).
Hi there,
On Wed, Jun 18, 2008 at 11:02 PM, Christian Theune <[EMAIL PROTECTED]> wrote:
[snip]
> I do not consider stuff within a version do be ordered by a given criterion,
> except maybe readability, so during development I tend to add stuff to the
> top, because it's easier to reach. Sometimes
On Jun 18, 2008, at 5:03 PM, Malthe Borch wrote:
Christian Theune wrote:
I don't think zope.component wants to know about views. The
interface should
be in a package that already knows about views.
I agree it's an inappropriate location, however, zope.component
*does* define an ``IView``
On Jun 18, 2008, at 4:31 PM, Malthe Borch wrote:
Currently views are registered as components providing
zope.interface.Interface; this is unfortunate since other kinds of
components may use the same specification, namely (context, request).
Right. This is a historical accident that I would
Jim Fulton wrote:
On Jun 18, 2008, at 4:31 PM, Malthe Borch wrote:
Currently views are registered as components providing
zope.interface.Interface; this is unfortunate since other kinds of
components may use the same specification, namely (context, request).
Right. This is a historical acci
Malthe Borch wrote:
Currently views are registered as components providing
zope.interface.Interface; this is unfortunate since other kinds of
components may use the same specification, namely (context, request).
An example of this is ``IAbsoluteURL``; it clashes with the resources
view*.
In
35 matches
Mail list logo
