Re: [Zope-dev] Re: Zope 2.9 goals

2005-06-20 Thread Martijn Faassen

Lennart Regebro wrote:

OK, so becuase of the tomembased release schedule, let's not dicuss
what goes in 2.9. let's discuss what features we found most
urgent/desirable, so we can start working on that, like now.


I think it's fine to discuss what we want to be in Zope 2.9. This way we 
can plan for it to actually be there.


We just should realize that if nobody does the work in time, it won't 
actually be in there, but that should only get the pressure up. The hope 
is that a time-based schedule will actually speed up feature 
development, not slow it down.


But you're right, work should start soon. This is also why I started the 
discussion now.


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: Zope 2.9 goals

2005-06-20 Thread Chris McDonough
As I mentioned before, I'd like to see Christian's blob work make it
into 2.9.  So that's one feature. ;-)

On Mon, 2005-06-20 at 09:55 +0200, Martijn Faassen wrote:
 Lennart Regebro wrote:
  OK, so becuase of the tomembased release schedule, let's not dicuss
  what goes in 2.9. let's discuss what features we found most
  urgent/desirable, so we can start working on that, like now.
 
 I think it's fine to discuss what we want to be in Zope 2.9. This way we 
 can plan for it to actually be there.
 
 We just should realize that if nobody does the work in time, it won't 
 actually be in there, but that should only get the pressure up. The hope 
 is that a time-based schedule will actually speed up feature 
 development, not slow it down.
 
 But you're right, work should start soon. This is also why I started the 
 discussion now.
 
 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 )
 

___
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: Zope 2.9 goals

2005-06-19 Thread Lennart Regebro
OK, so becuase of the tomembased release schedule, let's not dicuss
what goes in 2.9. let's discuss what features we found most
urgent/desirable, so we can start working on that, like now.
___
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: Zope 2.9 goals

2005-06-19 Thread Andreas Jung



--On 19. Juni 2005 11:35:32 +0200 Lennart Regebro [EMAIL PROTECTED] wrote:


OK, so becuase of the tomembased release schedule, let's not dicuss
what goes in 2.9. let's discuss what features we found most
urgent/desirable, so we can start working on that, like now.


Propose something :-)

-aj




pgp3DpDmVWBU8.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: Zope 2.9 goals

2005-06-18 Thread Martijn Faassen

Jim Fulton wrote:

Martijn Faassen wrote:

[snip]
This definitely gets me worried about coordinating everybody. We need 
very good planning to pull this off, something we haven't shown in 
previous Zope 2 or Zope 3 release processes. Perhaps a little ambitious?



Actually, I think that time-based releases make planning fairly easy.

There *will absolutely* be a Zope (23) feature freeze and beta release
November 1 (or sooner if we think that this leaves too little time for
a beta cycle).

There *will* be a final release in December, come hell or high water.

If you think this is to ambitious, then lets move the freeze/beta up
to give us more time for bug fixes, say October 1?


No, I think the time period for freezes is okay, and you're right, if we 
take this approach and take care not to destabilize close to the freeze, 
it should be possible. I'll just stop worrying for now. :)


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: Zope 2.9 goals

2005-06-17 Thread Jim Fulton

Max M wrote:

Jim Fulton wrote:



Further, we will coordinate the releases.  Essentially, *Zope*
is switching to a new release schedule. Zope will be released every 6 
months
and the releases will be in two parts, a Zope 2 part that includes the 
current

Zope 3 and a Zope 3 part.




Will they have the same relase date or will they be offset by a few 
months or something?


They will have the same release date, same announcement, etc.
Essentially, a single logical release, with a number of separate
release files reflecting different platforms and configurations.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
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: Zope 2.9 goals

2005-06-17 Thread Martijn Faassen

Jim Fulton wrote:

Max M wrote:


Jim Fulton wrote:


Further, we will coordinate the releases.  Essentially, *Zope*
is switching to a new release schedule. Zope will be released every 6 
months
and the releases will be in two parts, a Zope 2 part that includes 
the current

Zope 3 and a Zope 3 part.


Will they have the same relase date or will they be offset by a few 
months or something?


They will have the same release date, same announcement, etc.
Essentially, a single logical release, with a number of separate
release files reflecting different platforms and configurations.


This definitely gets me worried about coordinating everybody. We need 
very good planning to pull this off, something we haven't shown in 
previous Zope 2 or Zope 3 release processes. Perhaps a little ambitious?


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: Zope 2.9 goals

2005-06-17 Thread Jim Fulton

Martijn Faassen wrote:

Jim Fulton wrote:


Max M wrote:


Jim Fulton wrote:


Further, we will coordinate the releases.  Essentially, *Zope*
is switching to a new release schedule. Zope will be released every 
6 months
and the releases will be in two parts, a Zope 2 part that includes 
the current

Zope 3 and a Zope 3 part.



Will they have the same relase date or will they be offset by a few 
months or something?



They will have the same release date, same announcement, etc.
Essentially, a single logical release, with a number of separate
release files reflecting different platforms and configurations.



This definitely gets me worried about coordinating everybody. We need 
very good planning to pull this off, something we haven't shown in 
previous Zope 2 or Zope 3 release processes. Perhaps a little ambitious?


Actually, I think that time-based releases make planning fairly easy.

There *will absolutely* be a Zope (23) feature freeze and beta release
November 1 (or sooner if we think that this leaves too little time for
a beta cycle).

There *will* be a final release in December, come hell or high water.

If you think this is to ambitious, then lets move the freeze/beta up
to give us more time for bug fixes, say October 1?

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
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: Zope 2.9 goals

2005-06-17 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Fulton wrote:
 Chris McDonough wrote:
 
 On Fri, 2005-06-17 at 10:12 -0400, Jim Fulton wrote:

 
 ...
 
 We have historically always had the opportunity to introduce features
 that preserve 100% b/c (like filestream iterators) in point releases.
 This has worked pretty well for the last few years.
 
 
 I wasn't aware of this and I don't think it's a good policy.
 
 Feature releases should be backward compatible. Bug-fix
 releases should be for bug fixes.

Agreed, in theory.  In practice, the usual handwave has been to construe
the absence of the feature as a bug (with greater or lesser justification).

 Perhaps we can be more hard-nosed about a no new features in third-dot
releases policy *after* we get a timeboxed release process in place?  I
have some recollection that a hard-nosed application of such a policy in
ZODB land contributed to the creation of the dead-end 3.3 release
line, never incorporated in any released Zope2 / Zope3 version.


Tres.
- --
===
Tres Seaver  +1 202-558-7113  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCsvsB+gerLs4ltQ4RAkJzAKC/9ZzsDNmhJ7zLC8dOQ77FKowouwCgu5RV
iZ9fsxZWKXYVwY5bVZfwA/g=
=3/4a
-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: Zope 2.9 goals

2005-06-17 Thread Jim Fulton

Tres Seaver wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Fulton wrote:


Chris McDonough wrote:



On Fri, 2005-06-17 at 10:12 -0400, Jim Fulton wrote:



...



We have historically always had the opportunity to introduce features
that preserve 100% b/c (like filestream iterators) in point releases.
This has worked pretty well for the last few years.



I wasn't aware of this and I don't think it's a good policy.

Feature releases should be backward compatible. Bug-fix
releases should be for bug fixes.



Agreed, in theory.  In practice, the usual handwave has been to construe
the absence of the feature as a bug (with greater or lesser justification).

 Perhaps we can be more hard-nosed about a no new features in third-dot
releases policy *after* we get a timeboxed release process in place?  I
have some recollection that a hard-nosed application of such a policy in
ZODB land contributed to the creation of the dead-end 3.3 release
line, never incorporated in any released Zope2 / Zope3 version.


Which is just fine IMO.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
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: Zope 2.9 goals

2005-06-17 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Fulton wrote:
 Tres Seaver wrote:
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 Jim Fulton wrote:

 Chris McDonough wrote:


 On Fri, 2005-06-17 at 10:12 -0400, Jim Fulton wrote:


 ...


 We have historically always had the opportunity to introduce features
 that preserve 100% b/c (like filestream iterators) in point releases.
 This has worked pretty well for the last few years.



 I wasn't aware of this and I don't think it's a good policy.

 Feature releases should be backward compatible. Bug-fix
 releases should be for bug fixes.



 Agreed, in theory.  In practice, the usual handwave has been to construe
 the absence of the feature as a bug (with greater or lesser
 justification).

  Perhaps we can be more hard-nosed about a no new features in third-dot
 releases policy *after* we get a timeboxed release process in place?  I
 have some recollection that a hard-nosed application of such a policy in
 ZODB land contributed to the creation of the dead-end 3.3 release
 line, never incorporated in any released Zope2 / Zope3 version.
 
 
 Which is just fine IMO.

Such an outcome might be acceptable, but could hardly be called
desirable.

I'll note that a *big* pile of potentially useful ZODB features were
pretty much inaccessible to the Zope2 community from the date of the
first 3.3a1 release, nearly two years ago[1], until the release of Zope
2.8 last month.  This timespan, eerily enough, coincides almost exactly
with the  life of the Zope 2.7 release cycle[2].

I know how and why the loss happened (I helped *make* it happen, I'm
afraid), but I don't want it to happen again.  Moving to time-based
releases should help with the problem, but we aren't there yet, and
won't be for a year (a successful delivery in December could be a fluke).


[1] \
http://www.zope.org/Products/ZODB3.3/NEWS.html#what-s-new-in-zodb3-3-3-alpha-1

[2] http://www.zope.org/Products/Zope/2.7.6/CHANGES.txt


Tres.
- --
===
Tres Seaver  +1 202-558-7113  [EMAIL PROTECTED]
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCswEA+gerLs4ltQ4RAmv6AJ98s+dbAbB81g8lRpcRaDHjcyVpMACgq0Ak
GK6MYOUvPrazO5oJDn5xXIo=
=1SET
-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: Zope 2.9 goals

2005-06-17 Thread Tim Peters
[Tres Seaver]
 Agreed, in theory.  In practice, the usual handwave has been to construe
 the absence of the feature as a bug (with greater or lesser justification).

Like that's going to change wink.

 Perhaps we can be more hard-nosed about a no new features in third-dot
 releases policy *after* we get a timeboxed release process in place?  I
 have some recollection that a hard-nosed application of such a policy in
 ZODB land contributed to the creation of the dead-end 3.3 release
 line, never incorporated in any released Zope2 / Zope3 version.

Various versions of ZODB 3.3 were shipped with various ZopeX3-3.0.0
releases, but ZODB is also used by people who don't run Zope.  The
latter is why I make standalone ZODB releases, which have no
dependence at all on Zope.  While I have timed ZODB releases entirely
based on what various Zopes seem to need, I try to do that in ways
that make good sense for standalone-ZODB users too.  Starting a ZODB
3.4 for new features (and new deprecations) was necessary for ZODB's
other users (despite not being crucial for Zope's purposes).
___
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: Zope 2.9 goals

2005-06-17 Thread Jim Fulton

Tres Seaver wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Fulton wrote:


Tres Seaver wrote:



-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jim Fulton wrote:



Chris McDonough wrote:




On Fri, 2005-06-17 at 10:12 -0400, Jim Fulton wrote:



...




We have historically always had the opportunity to introduce features
that preserve 100% b/c (like filestream iterators) in point releases.
This has worked pretty well for the last few years.




I wasn't aware of this and I don't think it's a good policy.

Feature releases should be backward compatible. Bug-fix
releases should be for bug fixes.




Agreed, in theory.  In practice, the usual handwave has been to construe
the absence of the feature as a bug (with greater or lesser
justification).

Perhaps we can be more hard-nosed about a no new features in third-dot
releases policy *after* we get a timeboxed release process in place?  I
have some recollection that a hard-nosed application of such a policy in
ZODB land contributed to the creation of the dead-end 3.3 release
line, never incorporated in any released Zope2 / Zope3 version.



Which is just fine IMO.



Such an outcome might be acceptable, but could hardly be called
desirable.


I'm not sure what outcome you are refering to.  Surely not the dead-end
of 3.3.


I'll note that a *big* pile of potentially useful ZODB features were
pretty much inaccessible to the Zope2 community from the date of the
first 3.3a1 release, nearly two years ago[1], until the release of Zope
2.8 last month.  This timespan, eerily enough, coincides almost exactly
with the  life of the Zope 2.7 release cycle[2].


Of course, ZODB 3.3 was technically incompatible with Zope 2.7
because it required new-style classes.  There's nothing we could
have done to make those features accessable sooner short of a major
architectural change which, frankly, we could not afford.


I know how and why the loss happened (I helped *make* it happen, I'm
afraid), but I don't want it to happen again.  Moving to time-based
releases should help with the problem,  but we aren't there yet,


Right, we are going there. That's what the discussion is about.
We have to start some time. We are going to start in December.
We couldn't start for Zope 2.9 or 3.1 because we were already committed
to changes that were in and needed time to finish.  This won't happen
in the future because we know that something can't be checked into
the trunk unless it is ready for beta and we know that there will be a
definate date for the beta. Anything not in by then won't be in the release.


and
won't be for a year (a successful delivery in December could be a fluke).


This makes no sense to me at all.

Jim

--
Jim Fulton   mailto:[EMAIL PROTECTED]   Python Powered!
CTO  (540) 361-1714http://www.python.org
Zope Corporation http://www.zope.com   http://www.zope.org
___
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: Zope 2.9 goals

2005-06-17 Thread Chris McDonough
On Fri, 2005-06-17 at 13:00 -0400, Tim Peters wrote:
 [Tres Seaver]
  Agreed, in theory.  In practice, the usual handwave has been to construe
  the absence of the feature as a bug (with greater or lesser justification).
 
 Like that's going to change wink.

Over the last year Tres, Andreas, Tim, Fred, Jim, Florent, Stefan H.,
Yvo, Sidnei, Christian T., Chris W., Christian T., Mark, Jens, Brian,
Tino, Paul W., Lennart, dunny, and Dieter (by proxy ;-) have all
contributed code to Zope 2 one degree or another.

Policy aside, I trust all of these people implicitly to do the right
thing with judging whether a feature should make it into a dot release
and I wouldn't complain any of them snuck a minor feature into one.  If
one of them got out of control (that Tim character is a wild-man!), I'm
sure somebody would notice and go hose them down.

If time-based releases prove not to work out, I'd hope we could revert
to that sort of common-sense defacto process.

- 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: Zope 2.9 goals

2005-06-17 Thread Andreas Jung



--On 17. Juni 2005 13:17:13 -0400 Chris McDonough [EMAIL PROTECTED] wrote:



Policy aside, I trust all of these people implicitly to do the right
thing with judging whether a feature should make it into a dot release
and I wouldn't complain any of them snuck a minor feature into one.  If
one of them got out of control (that Tim character is a wild-man!), I'm
sure somebody would notice and go hose them down.



I agree totally. As RM I would have been task to enforce this policy. But 
because given the fact we had very long release cycles adding new minor 
feature was acceptable and worked more or less fine - not perfectly but it 
worked. Otherwise the complete Z2 development would have stand still. So 
for me time-based releases will only work if people show responsibility and 
commitment.


-aj






pgpxpcsIIFHUX.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 )