Benji York benji at zope.com writes:
Florent Xicluna wrote:
I am working on a 'light' version of Zope
You may want to contribute toward eggifying Zope 3 for the next
release. Once Z3 is sufficiently broken into individual components,
projects can use as few (or many) as they need.
On 9/12/06, Florent Xicluna [EMAIL PROTECTED] wrote:
Benji York benji at zope.com writes:
Florent Xicluna wrote:
I am working on a 'light' version of Zope
You may want to contribute toward eggifying Zope 3 for the next
release. Once Z3 is sufficiently broken into individual components,
Hello Jim,
As I think it further, even if I would implement the exception and so
transitions, there might still be a chance that an activity does not
have a valid outgoing transition. These transitions can also have
conditions.
Still I have to read through the WFMC specifications.
Monday,
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
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
Martijn Faassen wrote:
Thanks for doing this work, Christian. I'm in favor of going for Zope
3.4 on a timely basis.
I wouldn't mind that.
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
Hi all,
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?! If we want
to stick with the half-yr cycles, we need to schedule the next release
for around March/April next yr. Thoughts?
Andreas
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
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
--On 12. September 2006 12:28:10 +0200 Martijn Faassen [EMAIL PROTECTED]
wrote:
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
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 this time around. :)
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 in, well, bugfix
Martijn Faassen wrote:
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
On 9/12/06, Martijn Faassen [EMAIL PROTECTED] wrote:
What about a policy where we fix bugs until the release date, and then
on the release date, we actually release? Any bugs that are still in it
are going to go with it.
I totally agree. My feeling is that the x.x.0 release this time will
be
--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, doing a
new release in 3 months
On Sep 12, 2006, at 5:25 AM, Martijn Faassen wrote:
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
On Sep 12, 2006, at 5:47 AM, Andreas Jung wrote:
Hi all,
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?! If
we want to stick with the half-yr cycles, we need to schedule the
next release
for
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,
doing a
new
On Sep 12, 2006, at 8:40 AM, Martijn Faassen wrote:
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
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
Hi,
Jim Fulton wrote:
On Sep 12, 2006, at 8:40 AM, Martijn Faassen wrote:
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.
On Sep 12, 2006, at 8:58 AM, Christian Theune wrote:
...
Ack. One thing that bothers me (and it's totally possible that I'm
missing some documentation from zope.org) is that the overall process
isn't well documented, so it's hard for me (and probably other people)
to jump in and do stuff.
Um.
On Sep 12, 2006, at 9:03 AM, Martijn Faassen wrote:
...
The 'svn update' usecase is the reason we could think of why
install is always called, even if recipe and buildout config hasn't
changed.
Right now the install method can be called in a number of different
cases:
a) when the part
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 addressed. I
Hi,
Jim Fulton wrote:
On Sep 12, 2006, at 8:58 AM, Christian Theune wrote:
...
Ack. One thing that bothers me (and it's totally possible that I'm
missing some documentation from zope.org) is that the overall process
isn't well documented, so it's hard for me (and probably other people)
to
On Sep 12, 2006, at 8:57 AM, Jim Fulton wrote:
I still think our quality standards for a release have been too
high. Getting people to fix more bugs is good, sure, but perhaps
we should separate this at least somewhat from the release itself.
Sorry, I agree very much. I'd be willing
On Sep 12, 2006, at 9:17 AM, Christian Theune wrote:
Then your idea of perfection and mine are far apart. Letting bugs
languish for months or even years is not acceptable. Ignoreing bugs
reported during beta testing, when we get too little testing to begin
with is unacceptable.
I agree on
On Sep 12, 2006, at 9:50 AM, Martijn Faassen wrote:
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
Jim Fulton wrote:
Sometimes it feels to me that when Stephan or you prioritize a bug that
you have a rough understanding of the solution,
You are mistaken. Stephan should speak up on his criteria, but I have
the impression that it is guilty until proven innocent. That is, I
think he marks
On Sep 12, 2006, at 9:53 AM, Christian Theune wrote:
Hi,
Jim Fulton wrote:
On Sep 12, 2006, at 8:58 AM, Christian Theune wrote:
...
Ack. One thing that bothers me (and it's totally possible that I'm
missing some documentation from zope.org) is that the overall
process
isn't well
On Sep 12, 2006, at 10:33 AM, Christian Theune wrote:
- I think we want a release manager.
You're a genius! I'll just snap my fingers.
What happened after you snapped? :)
You became the release manager. Welcome aboard!
Does the application of irony indicate that we (I) should get over
I'm assuming that the branch is stable and ready. I only ask because
a fix was just checked in. If I need to wait, please let me know asap.
Jim
--
Jim Fulton mailto:[EMAIL PROTECTED]Python
Powered!
CTO (540) 361-1714
Hi,
Jim Fulton wrote:
On Sep 12, 2006, at 10:33 AM, Christian Theune wrote:
- I think we want a release manager.
You're a genius! I'll just snap my fingers.
What happened after you snapped? :)
You became the release manager. Welcome aboard!
Can I make you my assistant? Do I get free
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 just release
Hooray!
Jim Fulton wrote:
I'm assuming that the branch is stable and ready. I only ask because a
fix was just checked in. If I need to wait, please let me know asap.
I think there is nothing going on that can't wait until after the release.
I also wanted to state something that I verified
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
On Sep 12, 2006, at 11:05 AM, Christian Theune wrote:
Hooray!
Jim Fulton wrote:
I'm assuming that the branch is stable and ready. I only ask
because a
fix was just checked in. If I need to wait, please let me know asap.
I think there is nothing going on that can't wait until after the
Hi again,
Christian Theune wrote:
Hi,
Jim Fulton wrote:
On Sep 12, 2006, at 11:05 AM, Christian Theune wrote:
Hooray!
Jim Fulton wrote:
I'm assuming that the branch is stable and ready. I only ask because a
fix was just checked in. If I need to wait, please let me know asap.
I think
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
On Sep 12, 2006, at 11:56 AM, Martijn Faassen wrote:
Hi there,
I understand that the 3.3.0 release is coming out next week.
Hopefully, that depends depends on how the release candidate goes.
As the 3.3.1 release manager volunteer,
Yay!
I ask everybody to do the following:
If you find
Hi.
At Tue, 12 Sep 2006 17:43:27 +0200,
Christian Theune wrote:
Then this is a small reminder to Yusei, that the 3.3 branch has been
tagged for RC candidate and only *very critical* changes are allowed to
go there until we do the release.
Oups, Sorry I missed the announcement.
I'll be more
Hanno Schlichting wrote:
What do you think about a 9 month release cycle?
Based on the Plone experience I think this is a good compromise, between
release often and stable releases.
The Plone experience as I see it is that we get some measure of
contribution fatigue.
Take Plone 2.5 and
Benji York wrote:
Personally I think we should just release the trunk every six months
(with a list of known bugs) and that be it. (I'm speaking of Zope 3
here, I don't know enough about the dynamics of the Zope 2 ecosystem to
comment there.)
What good could that possibly do?
For the
Hanno Schlichting wrote at 2006-9-11 23:06 +0200:
...
You got it backwards ;) I only forward-port any changes from older
branches to the more recent ones, but never do any backports. The reason
I do this is because before this, Plone developers tended to only fix a
bug on the trunk or the latest
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, please fix it in Zope 3.2 first. As
Hanno Schlichting wrote at 2006-9-11 23:18 +0200:
...
Yes. We don't have a Hanno for Zope 3.
And even if there would be someone willing to do this job, a good
understanding of most of the internals would be a prerequisite, as
merging something which you do not understand is indeed potentially
Hi,
I had an interesting comment from Chris McDonough on a variation how to
handle the RC.
Instead of blocking changes to the maintenance branch, we could create a
temporary RC branch that only the release manager allows checkins to. In
this scenario, the maintenance branch stays open for
On Tuesday 12 September 2006 10:13, Jim Fulton wrote:
Sometimes it feels to me that when Stephan or you prioritize a bug
that
you have a rough understanding of the solution,
You are mistaken. Stephan should speak up on his criteria, but I
have the impression that it is guilty until
On Sep 12, 2006, at 10:50 AM, Christian Theune wrote:
Hi,
Jim Fulton wrote:
On Sep 12, 2006, at 10:33 AM, Christian Theune wrote:
- I think we want a release manager.
You're a genius! I'll just snap my fingers.
What happened after you snapped? :)
You became the release manager.
Jim Fulton wrote:
On Sep 12, 2006, at 10:50 AM, Christian Theune wrote:
Jim Fulton wrote:
On Sep 12, 2006, at 10:33 AM, Christian Theune wrote:
- I think we want a release manager.
You're a genius! I'll just snap my fingers.
What happened after you snapped? :)
You became the release
Martijn Faassen wrote at 2006-9-12 11:25 +0200:
...
On the one hand core developers seem to be happy to use the trunk for
development projects, and on the other hand we demand a lot of work
doing bugfixes in a release, up to the point where we delay the release
itself.
core developers
Martijn Faassen wrote:
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
Martijn Faassen wrote at 2006-9-12 14:44 +0200:
...
The current CHANGES.txt from the trunk just lists one new feature (added
by myself). That's does not deserve a major release.
It's the nature of time-based releases, though. If nobody does anything
in 6 months, does that mean we won't have a
The Zope 3 development team is proud to announce Zope 3.3.0 rc1.
Zope 3 is the next major Zope release and has been written from scratch
based on the latest software design patterns and the experiences of Zope 2.
Cleanup of the Zope 3 packages has continued to ensure a flexible and
scalable
On Sep 12, 2006, at 1:24 PM, Christian Theune wrote:
Jim Fulton wrote:
On Sep 12, 2006, at 10:50 AM, Christian Theune wrote:
Jim Fulton wrote:
On Sep 12, 2006, at 10:33 AM, Christian Theune wrote:
- I think we want a release manager.
You're a genius! I'll just snap my fingers.
What
Hi there,
Jim Fulton wrote:
I know. So Martijn and I both stepped forward a small bit on this. So we
need some conflict resolution. :)
Let Martijn do 3.3.1. Why don't you do 3.4.
Actually dividing that job up to different people, maybe on a kind of
rotation, sounds like a good plan. What do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
TAHARA Yusei wrote:
Hi.
At Tue, 12 Sep 2006 17:43:27 +0200,
Christian Theune wrote:
Then this is a small reminder to Yusei, that the 3.3 branch has been
tagged for RC candidate and only *very critical* changes are allowed to
go there until we
Hi.
Martijn Faassen wrote:
Andreas Jung wrote:
--On 12. September 2006 13:06:05 +0200 Martijn Faassen
[EMAIL PROTECTED] wrote:
Another point with this whole half-yr release cycle: we're going to
confuse
more and more professional users about which Zope version to use for
what.
I've
Martijn Faassen wrote:
Andreas Jung wrote:
Another point with this whole half-yr release cycle: we're going to confuse
more and more professional users about which Zope version to use for what.
I've heard from my major customer but also from other ppl. IN December
we would have *three*
--On 12. September 2006 16:55:31 +0200 Martijn Faassen [EMAIL PROTECTED]
wrote:
Personally I think we should just release the trunk every six months
(with a list of known bugs) and that be it. (I'm speaking of Zope 3
here, I don't know enough about the dynamics of the Zope 2 ecosystem to
Andreas Jung wrote:
I am thinking since one hour about how to reply to Benji's proposal. It's
not much acceptable. Major release have to be planned to a certain degree
and must be tested (as good as we can) - means we must have alpha and beta
releases.
I wasn't proposing we do away with
61 matches
Mail list logo
