On Sun, May 2, 2010 at 10:52 PM, Martijn Faassen faas...@startifact.com wrote:
Hi there,
Of course what applies to Hanno should apply to others making releases
of packages maintained by the Zope Toolkit project as well. I think the
ZTK leadership should figure out some kind of guidelines for
Lennart Regebro wrote:
I thought it was painless already, but maybe I was wrong. :)
It's very nice to be able to do a full release by just typing
'fullrelease' and saying 'yes' a number of times. The tool made a
convert out of me, and I know others who also were pleased by how much
it sped
Vincent Fretin wrote:
For the tool, I think I did it already. I modified one of Hanno's
script some times ago:
cd zopetoolkit/trunk
bin/buildout -c checknew.cfg
bin/python checknew.py
Cool! This tool should be documented if it isn't already.
Why is this in a separate .cfg unlike the other
Hanno Schlichting wrote:
Good evening :)
If you have a specific issue with me, you might contact me in private.
But with your follow-ups this turned into a more general issue.
No, I think this needs to be public as the ZTK is a public project that
I care about. And you're not playing your
On 5/3/10 12:20 , Martijn Faassen wrote:
Hanno Schlichting wrote:
Good evening :)
If you have a specific issue with me, you might contact me in private.
But with your follow-ups this turned into a more general issue.
No, I think this needs to be public as the ZTK is a public project that
I
Hi there,
Hanno Schlichting wrote:
I expect us to define the process around package releases and updating
the ZTK. It's not entirely clear to me who should and who is allowed
to update the ZTK definition. We'll figure things out and once we have
I'll stick to the rules.
My few cents:
I
On 5/3/10 12:34 , Martijn Faassen wrote:
Hi there,
Hanno Schlichting wrote:
I expect us to define the process around package releases and updating
the ZTK. It's not entirely clear to me who should and who is allowed
to update the ZTK definition. We'll figure things out and once we have
I'll
Wichert Akkerman wrote:
Can we please not rehash an old discussion or make this personal? This
has all been discussed too often already.
As far as I know, I've *never* discussed this fork on this list, but I
might be wrong; feel free to dig the archives. But that doesn't matter:
the fork is
Wichert Akkerman wrote:
I suggest that we wait impatiently for the ZTK steering committee to
come up with a useful policy instead of trying to do their work when
none of us volunteered for the task.
I don't understand your suggestion. Could you rephrase it?
I'm a ZTK user, and I'm
On 5/3/10 12:52 , Martijn Faassen wrote:
Wichert Akkerman wrote:
I suggest that we wait impatiently for the ZTK steering committee to
come up with a useful policy instead of trying to do their work when
none of us volunteered for the task.
I don't understand your suggestion. Could you
Martijn Faassen wrote:
[snip]
Why is this in a separate .cfg unlike the other tools that come with the
ZTK? Unless creating this extra script is very expensive, I think it
makes sense to generate it in 'bin' along with the rest of the scripts.
To expand on that, it'd be nice if it were also
Wichert Akkerman wrote:
On 5/3/10 12:51 , Martijn Faassen wrote:
Wichert Akkerman wrote:
Can we please not rehash an old discussion or make this personal? This
has all been discussed too often already.
As far as I know, I've *never* discussed this fork on this list, but I
might be wrong;
On 5/3/10 13:07 , Martijn Faassen wrote:
Wichert Akkerman wrote:
On 5/3/10 12:51 , Martijn Faassen wrote:
Wichert Akkerman wrote:
Can we please not rehash an old discussion or make this personal? This
has all been discussed too often already.
As far as I know, I've *never* discussed this
Wichert Akkerman wrote:
On 5/3/10 12:52 , Martijn Faassen wrote:
Wichert Akkerman wrote:
I suggest that we wait impatiently for the ZTK steering committee to
come up with a useful policy instead of trying to do their work when
none of us volunteered for the task.
I don't understand your
Wichert Akkerman wrote:
Sorry, my mistake. I meant the ZTK release manage group, not the now
defunct ZTK steering group,
If it's defunct someone better update the documentation.
Regards,
Martijn
___
Zope-Dev maillist - Zope-Dev@zope.org
On Mon, May 3, 2010 at 3:46 PM, Martijn Faassen faas...@startifact.com wrote:
Lennart Regebro wrote:
I thought it was painless already, but maybe I was wrong. :)
It's very nice to be able to do a full release by just typing
'fullrelease' and saying 'yes' a number of times. The tool made a
Summary of messages to the zope-tests list.
Period Sun May 2 12:00:00 2010 UTC to Mon May 3 12:00:00 2010 UTC.
There were 16 messages: 6 from Zope Tests, 9 from ccomb at free.fr, 1 from ct
at gocept.com.
Test failures
-
Subject: FAILED: Repository policy check found errors in 670
Hi there,
Because my suggestions (besides the fork issue) as a ZTK
user/contributor were scattered through the thread, here's a handy summary:
* please construct guidelines for updating the ZTK when making a release
of a package that's managed by the ZTK project. It's useful people
test
On Mon, May 3, 2010 at 13:22, Martijn Faassen faas...@startifact.com wrote:
Wichert Akkerman wrote:
Sorry, my mistake. I meant the ZTK release manage group, not the now
defunct ZTK steering group,
Well, if it's defunct or not is up to the members of the steering
group. The steering group
Hi Martijn,
On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen faas...@startifact.com wrote:
Because my suggestions (besides the fork issue) as a ZTK
user/contributor were scattered through the thread, here's a handy summary:
Thank you very much for your suggestions. I'm sure the release team
Lennart Regebro wrote:
On Mon, May 3, 2010 at 13:22, Martijn Faassen faas...@startifact.com wrote:
Wichert Akkerman wrote:
Sorry, my mistake. I meant the ZTK release manage group, not the now
defunct ZTK steering group,
Well, if it's defunct or not is up to the members of the steering
Hanno Schlichting wrote:
Hi Martijn,
On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen faas...@startifact.com
wrote:
Because my suggestions (besides the fork issue) as a ZTK
user/contributor were scattered through the thread, here's a handy summary:
Thank you very much for your
On 5/3/10 15:41 , Martijn Faassen wrote:
Lennart Regebro wrote:
On Mon, May 3, 2010 at 13:22, Martijn Faassenfaas...@startifact.com wrote:
Wichert Akkerman wrote:
Sorry, my mistake. I meant the ZTK release manage group, not the now
defunct ZTK steering group,
Well, if it's defunct or not
On 2010-05-03, Wichert Akkerman wich...@wiggy.net wrote:
On 5/3/10 15:41 , Martijn Faassen wrote:
Lennart Regebro wrote:
On Mon, May 3, 2010 at 13:22, Martijn Faassenfaas...@startifact.com
wrote:
Wichert Akkerman wrote:
If we're going to make cheap shots: that's still a lot faster than the
On Mon, May 3, 2010 at 15:41, Martijn Faassen faas...@startifact.com wrote:
Well, I'm disappointed in the zope documentation process then. Work faster!
:)
If you don't inform people about this release manager team thingy, you
can't rightly expect people like me to care about it.
Heh.
Lennart Regebro wrote:
On Mon, May 3, 2010 at 15:41, Martijn Faassen faas...@startifact.com wrote:
Well, I'm disappointed in the zope documentation process then. Work faster!
:)
If you don't inform people about this release manager team thingy, you
can't rightly expect people like me to
On Mon, May 3, 2010 at 17:30, Martijn Faassen faas...@startifact.com wrote:
Answers like read the mailing list archives and we're working on it
are legitimate sometimes. But they're also all too easily the answers of
a bureaucracy that's stalling things as bureaucracies do. They're not
very
Hi there,
On Mon, May 3, 2010 at 6:06 PM, Lennart Regebro rege...@gmail.com wrote:
I don't know anything about the fork, but my view of the fork is that
of Hanno wants a fork, Hanno can have a fork, as long as he doesn't
try to poke anyones eye out with it. If it's a stupid waste of time,
On 4 May 2010 00:09, Martijn Faassen faas...@startifact.com wrote:
Hanno is making releases of packages in the ZTK. So it's not just
Hanno's waste of time; it's mine too. That's where I was coming from
when this discussion started. It didn't help that the action of making
the fork really hurt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hanno Schlichting wrote:
Hi Martijn,
On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen faas...@startifact.com
wrote:
Because my suggestions (besides the fork issue) as a ZTK
user/contributor were scattered through the
On Mon, May 3, 2010 at 18:09, Martijn Faassen faas...@startifact.com wrote:
Hanno is making releases of packages in the ZTK. So it's not just
Hanno's waste of time; it's mine too.
Obviously he shouldn't hurt the main ZTK in any way. That would be a
problem (even if i missed this incident
Hi there,
On Mon, May 3, 2010 at 7:48 PM, Lennart Regebro rege...@gmail.com wrote:
On Mon, May 3, 2010 at 18:09, Martijn Faassen faas...@startifact.com wrote:
Hanno is making releases of packages in the ZTK. So it's not just
Hanno's waste of time; it's mine too.
Obviously he shouldn't hurt
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Test failures
-
Subject: FAILED: Repository policy check found errors in 670 projects
From: ct at gocept.com
Date: Sun May 2 21:17:48 EDT 2010
URL: http://mail.zope.org/pipermail/zope-tests/2010-May/014232.html
Expected
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
On Mon, May 3, 2010 at 7:48 PM, Lennart Regebro rege...@gmail.com wrote:
On Mon, May 3, 2010 at 18:09, Martijn Faassen faas...@startifact.com wrote:
Hanno is making releases of packages in the ZTK. So it's not just
Hanno's
Hi there,
Tres Seaver wrote:
One issue with insta-updates to ztk.cfg is that ongoing development of a
package can be in real tension with the needs of ZTK consumers for
stability in the package set.
Since there are no ZTK releases Grok and BlueBream gain stability by
pinning to a
Am 03.05.2010, 19:59 Uhr, schrieb Martijn Faassen faas...@startifact.com:
I haven't seen a plausible reason why the fork should be necessary. It
just uses some updated versions of packages (mostly bugfix releases)
that would have been updated in the ZTK as well if people had bothered
to
Hey,
Tres Seaver wrote:
[snip]
I expect to see Zope2 trunk move to using the ZTK versions list quite
soon: more than that, I'm willing to to the work to see that it happens
(verifying that everything passes / works with the change), and give
Hanno the patch to make it so, assuming he doesn't
Am 03.05.2010, 20:06 Uhr, schrieb Hanno Schlichting ha...@hannosch.eu:
Hhm. I'm inclined to drop 2.4 support here. Using a zope.testing that
tries to be compatible all the way from 2.4 to 3.1 is quite a bit of a
stretch.
+1
Python 2.4 itself is on life-support only*. I know it's an abrupt
On Mon, May 3, 2010 at 20:13, Martijn Faassen faas...@startifact.com wrote:
Since there are no ZTK releases Grok and BlueBream gain stability by
pinning to a particular revision of ztk.cfg (and moving it forward when
needed). Zope 2 could easily do the same. If more is needed, then a
branch or
On Mon, May 3, 2010 at 20:02, Tres Seaver tsea...@palladion.com wrote:
At least the first one is due to doctests not exposing an '__file__' in
their faux-module globals under 2.4. We might need to add Lennart's
monkeypatch under 2.4, or else drop 2.4 support altogether.
Well, I don't want a
Charlie Clark wrote:
FWIW this is a very poor
strategy to win people over to your point of view.
I'm not trying to win over people to my point of view. I tried that last
year, but people just forked when they couldn't work it out with me.
I've learned that rash actions without consideration
Lennart Regebro wrote:
On Mon, May 3, 2010 at 20:13, Martijn Faassen faas...@startifact.com wrote:
Since there are no ZTK releases Grok and BlueBream gain stability by
pinning to a particular revision of ztk.cfg (and moving it forward when
needed). Zope 2 could easily do the same. If more is
On Mon, May 3, 2010 at 9:56 PM, Martijn Faassen faas...@startifact.com wrote:
Last december Hanno made progress on the ZTK's dependency structure,
removing a lot of dependencies on packages. In his enthusiasm, he
unilaterally just removed all those suddenly-unneeded (by him!) packages
from the
On Mon, May 3, 2010 at 21:57, Martijn Faassen faas...@startifact.com wrote:
I think the list needs to commit to something
If it needs to commit to what packages are included, then there is no
reason to call it an alpha, and also, we can't do it now. So then the
status persists with the users of
Vincent Fretin a écrit :
On Sun, May 2, 2010 at 10:52 PM, Martijn Faassen faas...@startifact.com
wrote:
Hi there,
Of course what applies to Hanno should apply to others making releases
of packages maintained by the Zope Toolkit project as well. I think the
ZTK leadership should figure out
Hi there,
On Mon, May 3, 2010 at 10:26 PM, Hanno Schlichting ha...@hannosch.eu wrote:
On Mon, May 3, 2010 at 9:56 PM, Martijn Faassen faas...@startifact.com
wrote:
Last december Hanno made progress on the ZTK's dependency structure,
removing a lot of dependencies on packages. In his
Thanks for these suggestions. This is *exactly* what we (the ztk release team)
need.
Are there other recommendations from other people?
Martijn Faassen a écrit :
Hi there,
Because my suggestions (besides the fork issue) as a ZTK
user/contributor were scattered through the thread, here's a
Hanno Schlichting a écrit :
On Mon, May 3, 2010 at 8:02 PM, Tres Seaver tsea...@palladion.com wrote:
Breakage in the following packages, but only on Python 2.4, and only in
doctests:
- - zope.browserpage
- - zope.viewlet
- - zope.contentprovider
- - zope.deferredimport
At least the first
On Tue, May 4, 2010 at 12:41 AM, Christophe Combelles cc...@free.fr wrote:
Hanno Schlichting a écrit :
Hhm. I'm inclined to drop 2.4 support here. Using a zope.testing that
tries to be compatible all the way from 2.4 to 3.1 is quite a bit of a
stretch.
Unless I missed something, the ZTK was
Hey,
Christophe Combelles wrote:
Thanks for these suggestions. This is *exactly* what we (the ztk
release team) need.
How wonderfully diplomatic and constructive, my compliments! The
release team (you, Hanno and JW) look good to me.
* please let these guidelines not block most updates by
Hi again,
One more suggestion I can make is a way to get an integrated changelog
for lists of packages such as the ZTK. Right now it's hard to track what
kind of changes there have been in the ZTK as a whole; you have to go
through all packages. If there were a way to generate a unified
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hanno Schlichting wrote:
On Mon, May 3, 2010 at 9:56 PM, Martijn Faassen faas...@startifact.com
wrote:
Last december Hanno made progress on the ZTK's dependency structure,
removing a lot of dependencies on packages. In his enthusiasm, he
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christophe Combelles wrote:
Hanno Schlichting a écrit :
On Mon, May 3, 2010 at 8:02 PM, Tres Seaver tsea...@palladion.com wrote:
Breakage in the following packages, but only on Python 2.4, and only in
doctests:
- - zope.browserpage
- -
On Tue, May 4, 2010 at 4:24 AM, Hanno Schlichting ha...@hannosch.eu wrote:
Dropping Python 2.4 supports makes most sense to me at this stage.
Zope2/Plone only support Python 2.6 for any modern version.
I don't know what BlueBream and Grok want to support, but would guess
they aim for Python
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
Log message for revision 111904:
Group versions by the 'sets' to which they correspond.
Changed:
U Zope/trunk/versions.cfg
-=-
Modified: Zope/trunk/versions.cfg
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Tres Seaver wrote:
Tres Seaver wrote:
Log message for revision 111904:
Group versions by the 'sets' to which they correspond.
Changed:
U Zope/trunk/versions.cfg
-=-
Modified: Zope/trunk/versions.cfg
56 matches
Mail list logo
