Re: [Zope-CMF] GenericSetup backport

2011-05-31 Thread Godefroid Chapelle
Le 27/05/11 10:03, Hanno Schlichting a écrit :
 On Thu, May 26, 2011 at 10:39 PM, Godefroid Chapelle
 got...@bubblenet.be  wrote:
 Le 26/05/11 17:15, Hanno Schlichting a écrit :
 Smaller 1.4.x numbers could be kept for bug fix releases for CMF 2.1 and
 Plone 3.

 That's a really weird way of doing it. And I'm a -1 on that.

 I agree it is a bit weird, I am just trying to be creative to comply with
 your request of preserving Plone 3 tests.

 Outside being weird, can you explain issues you have ?

 You want to backport a feature that is known to break things into a
 stable release series.

It does not break things, this is too wide.

GS test suite was not touched outside places where tests did check 
internal implementation.

It would be much more fair to state that it is known to break tests setup.

 To me that's just wrong and defeats the very purpose of having stable 
 releases.

 Hanno

What I am actually trying to understand is which versions to give to 
public releases after forking an existing branch.

The numbering scheme of those versions should fill the following goals :

- systems that depend on releases of the original branch should not be 
impacted.

- new releases of the original branch should be pullable without the 
need to touch the existing systems.

- releases of the newest branch should have their own numbering so that 
other packages can state unambiguous dependency on those new releases.

This is what dev releases are for (as you suggested).

My proposal is then the following : I would publish a 
Products.GenericSetup 1.4.6dev001 release from my backported branch to PyPi.

And have p.a.testing 3.0.x depend explicitely on this GS 1.4.6dev001 
release until there is a need for a new release of GS from this 
backported branch.

Opinions ?

-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] GenericSetup backport

2011-05-31 Thread Hanno Schlichting
On Tue, May 31, 2011 at 3:15 PM, Godefroid Chapelle got...@bubblenet.be wrote:
 What I am actually trying to understand is which versions to give to
 public releases after forking an existing branch.

 This is what dev releases are for (as you suggested).

No. I said this is what private releases are for.

 My proposal is then the following : I would publish a
 Products.GenericSetup 1.4.6dev001 release from my backported branch to PyPi.

Sorry, but publishing dev releases is frowned upon on PyPi.

The version numbering scheme we have doesn't allow for you use-case.
You want to effectively fork the 1.4 release series to continue with a
different feature set than we have already gotten in the 1.5 and 1.6
series.

We have a stable feature releases in all of the 1.4, 1.5 and 1.6
series. If you want to introduce any new feature you can only do this
in the 1.6.x or 1.7 release series. Anything else means doing a
private fork and publishing it under some other URL.

It's really not that hard to do that and will only cost you ten
minutes. Anyone who wants to use this version will need a find-links
URL in addition to the version pin, but that's just one extra line of
config. Doing this means keeping things sane and stable for the
majority of users and adding a tiny little bit of extra work for the
few that want to run your backport. I think that is a very sane
approach.

Hanno
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] GenericSetup backport

2011-05-31 Thread Godefroid Chapelle
Le 31/05/11 15:36, Hanno Schlichting a écrit :
 My proposal is then the following : I would publish a
   Products.GenericSetup 1.4.6dev001 release from my backported branch to 
  PyPi.
 Sorry, but publishing dev releases is frowned upon on PyPi.

The arguments against the proposal seem lighter and lighter.

I begin to feel zope-dev like stop energy.

 The version numbering scheme we have doesn't allow for you use-case.
 You want to effectively fork the 1.4 release series to continue with a
 different feature set than we have already gotten in the 1.5 and 1.6
 series.
 
 We have a stable feature releases in all of the 1.4, 1.5 and 1.6
 series. If you want to introduce any new feature you can only do this
 in the 1.6.x or 1.7 release series. Anything else means doing a
 private fork and publishing it under some other URL.

 It's really not that hard to do that and will only cost you ten
 minutes.

True as I told already.

 Anyone who wants to use this version will need a find-links
 URL in addition to the version pin, but that's just one extra line of
 config.

But the user needs to know that he needs to add that line.

 Doing this means keeping things sane and stable for the
 majority of users

Using a dev release does the same without the need for debugging broken 
cases where the user did not know.

 and adding a tiny little bit of extra work for the
 few that want to run your backport. I think that is a very sane
 approach.

 Hanno

Constructively ;-)
-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] GenericSetup backport

2011-05-31 Thread Charlie Clark
Am 31.05.2011, 16:05 Uhr, schrieb Godefroid Chapelle got...@bubblenet.be:

 The arguments against the proposal seem lighter and lighter.

No, they are the same all along. It is the repetition that is becoming  
tedious.

Charlie
-- 
Charlie Clark
Managing Director
Clark Consulting  Research
German Office
Helmholtzstr. 20
Düsseldorf
D- 40215
Tel: +49-211-600-3657
Mobile: +49-178-782-6226
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] GenericSetup backport

2011-05-31 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 05/31/2011 10:05 AM, Godefroid Chapelle wrote:
 Le 31/05/11 15:36, Hanno Schlichting a écrit :
 My proposal is then the following : I would publish a
  Products.GenericSetup 1.4.6dev001 release from my backported branch to 
 PyPi.
 Sorry, but publishing dev releases is frowned upon on PyPi.
 
 The arguments against the proposal seem lighter and lighter.
 
 I begin to feel zope-dev like stop energy.

Godefroid, Hanno is pushing back on your desire to add features to
long-feature-frozen release branches:  that isn't stop energy, but
just our normal policy.  Please don't push to release an official
1.4.x or 1.5.x with such a change in it.

Folks who need stability have to be able to live with its costs:  if
they want your feature, they should be prepared to upgrade to get it.


Tres.
- -- 
===
Tres Seaver  +1 540-429-0999  tsea...@palladion.com
Palladion Software   Excellence by Designhttp://palladion.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk3lHTIACgkQ+gerLs4ltQ7RJwCgj4ONCJprO33UhZ6RaHda9aDd
4U4AoKdJ6R14fV5twnJrroMa0QNryv8o
=mXta
-END PGP SIGNATURE-

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] GenericSetup backport

2011-05-27 Thread Raphael Ritz
On 5/26/11 10:39 PM, Godefroid Chapelle wrote:

[..]


 Further, I think it is a real advantage for the product developers if
 they can migrate their tests to p.a.testing while keeping Plone 3
 compatibility.

FWIW: whatever the solution ends up being I'd welcome
such an option as well.

Raphael



 Hanno

 Gotcha
 ___
 Zope-CMF maillist  -  Zope-CMF@zope.org
 https://mail.zope.org/mailman/listinfo/zope-cmf

 See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] GenericSetup backport

2011-05-27 Thread Hanno Schlichting
On Thu, May 26, 2011 at 10:39 PM, Godefroid Chapelle
got...@bubblenet.be wrote:
 Le 26/05/11 17:15, Hanno Schlichting a écrit :
 Smaller 1.4.x numbers could be kept for bug fix releases for CMF 2.1 and
 Plone 3.

 That's a really weird way of doing it. And I'm a -1 on that.

 I agree it is a bit weird, I am just trying to be creative to comply with
 your request of preserving Plone 3 tests.

 Outside being weird, can you explain issues you have ?

You want to backport a feature that is known to break things into a
stable release series.

To me that's just wrong and defeats the very purpose of having stable releases.

Hanno
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] GenericSetup backport

2011-05-26 Thread Godefroid Chapelle
Le 26/04/11 12:04, Hanno Schlichting a écrit :
 Most tests failed as the ZCA now has to be setup before calling
 certain API's like profile_registry.registerProfile. It's been a
 very common pattern in Plone add-ons to call this on the module level
 of a test to register a test-only profile.

 We have adjusted most of the test layers for the recent Plone release,
 so the change can stay in the 1.6.x series from my point of view. But
 if would be a lot of pain to do this for Plone 3.x releases using
 GenericSetup 1.4.

 Hanno

I'd like to move on this. Lemme explain the context.

One of our customers has a Plone 3 application for which we would like 
to add more tests before migrating to Plone 4.

Some of the programmers that would do the work have never written Plone 
tests and we need to bring them up to speed.

plone.app.testing (p.a.t) is imo much simpler to learn than PTC/ZTC magic.

Reason why we would like our programmers to use p.a.t and why we 
backported p.a.t to Plone 3.

Now that GenericSetup delegates its registries management to ZCA,
p.a.t 4.x has been refactored to be even simpler.

This refactoring has also been backported successfully to p.a.t 3.x.

I'd like to make a release of p.a.t 3.x but it does need to depend on a 
GS-1.4 release that delegates its registries to ZCA.

A long introduction for a simple question :

Would anyone see an issue that I release a Products.GenericSetup 1.4.20 
(or any other big integer) with ZCA registries ?

Smaller 1.4.x numbers could be kept for bug fix releases for CMF 2.1 and 
Plone 3.

p.a.t 3.x would then state a dependency = 1.4.20

-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] GenericSetup backport

2011-05-26 Thread Hanno Schlichting
On Thu, May 26, 2011 at 4:46 PM, Godefroid Chapelle got...@bubblenet.be wrote:
 Would anyone see an issue that I release a Products.GenericSetup 1.4.20
 (or any other big integer) with ZCA registries ?

 Smaller 1.4.x numbers could be kept for bug fix releases for CMF 2.1 and
 Plone 3.

That's a really weird way of doing it. And I'm a -1 on that.

Why don't you just cut a branch of GenericSetup 1.4 with your changes
and make a private (vendor) release of it?

Then put the private release up on some Web server serving a flat
directory, including it into the buildout via find-links? We do that
all the time, see for example http://dist.jarn.com/public/

Hanno
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] GenericSetup backport

2011-05-26 Thread Godefroid Chapelle
Le 26/05/11 17:15, Hanno Schlichting a écrit :
 On Thu, May 26, 2011 at 4:46 PM, Godefroid Chapellegot...@bubblenet.be  
 wrote:
 Would anyone see an issue that I release a Products.GenericSetup 1.4.20
 (or any other big integer) with ZCA registries ?

 Smaller 1.4.x numbers could be kept for bug fix releases for CMF 2.1 and
 Plone 3.

 That's a really weird way of doing it. And I'm a -1 on that.

I agree it is a bit weird, I am just trying to be creative to comply 
with your request of preserving Plone 3 tests.

Outside being weird, can you explain issues you have ?


 Why don't you just cut a branch of GenericSetup 1.4 with your changes
 and make a private (vendor) release of it?

 Then put the private release up on some Web server serving a flat
 directory, including it into the buildout via find-links? We do that
 all the time, see for example http://dist.jarn.com/public/

I obviously thought of an egg on our own server. Nevertheless, at least 
Vitaliy Podoba from Quintagroup also uses p.a.testing 3.x and I'd like 
him (and others) to be able to also use p.a.testing released eggs.

Further, I think it is a real advantage for the product developers if 
they can migrate their tests to p.a.testing while keeping Plone 3 
compatibility.

 Hanno

Gotcha
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] GenericSetup backport

2011-04-26 Thread Hanno Schlichting
On Tue, Apr 26, 2011 at 11:53 AM, Godefroid Chapelle
got...@bubblenet.be wrote:
 I had made changes to GS registries (use ZCA instead of own registries)
 which got released in 1.6.3.

 I backported those changes to 1.4.

 http://zope3.pov.lt/trac/browser/Products.GenericSetup/branches/1.4-with-global-zca

 Can I merge to 1.4 branch ?

Please don't. The changes broke quite a number of tests and some of my
own code. It's bad enough this got into the 1.6 bug fix releases, even
though it's a feature change.

Most tests failed as the ZCA now has to be setup before calling
certain API's like profile_registry.registerProfile. It's been a
very common pattern in Plone add-ons to call this on the module level
of a test to register a test-only profile.

We have adjusted most of the test layers for the recent Plone release,
so the change can stay in the 1.6.x series from my point of view. But
if would be a lot of pain to do this for Plone 3.x releases using
GenericSetup 1.4.

Hanno
___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests


Re: [Zope-CMF] GenericSetup backport

2011-04-26 Thread Godefroid Chapelle
Le 26/04/11 12:04, Hanno Schlichting a écrit :
 On Tue, Apr 26, 2011 at 11:53 AM, Godefroid Chapelle
 got...@bubblenet.be  wrote:
 I had made changes to GS registries (use ZCA instead of own registries)
 which got released in 1.6.3.

 I backported those changes to 1.4.

 http://zope3.pov.lt/trac/browser/Products.GenericSetup/branches/1.4-with-global-zca

 Can I merge to 1.4 branch ?

 Please don't. The changes broke quite a number of tests

This feels acceptable to me.

 and some of my own code.

But this does not. Can you explain more ? I'd like to understand how 
your code got broken, which I did not foresee at all. This way, I'll 
learn how to avoid same type of issues for a next case.

 It's bad enough this got into the 1.6 bug fix releases, even
 though it's a feature change.

 Most tests failed as the ZCA now has to be setup before calling
 certain API's like profile_registry.registerProfile. It's been a
 very common pattern in Plone add-ons to call this on the module level
 of a test to register a test-only profile.

I guess it should be possible to ensure ZCA is setup from within GS.
Would that help ?

 We have adjusted most of the test layers for the recent Plone release,
 so the change can stay in the 1.6.x series from my point of view.

I made a few fixes to test layers for Plone 4.1. Can you point me to the 
other changes that you had to do ?

 But if would be a lot of pain to do this for Plone 3.x releases using
 GenericSetup 1.4.

I see.

 Hanno

-- 
Godefroid Chapelle (aka __gotcha) http://bubblenet.be

___
Zope-CMF maillist  -  Zope-CMF@zope.org
https://mail.zope.org/mailman/listinfo/zope-cmf

See https://bugs.launchpad.net/zope-cmf/ for bug reports and feature requests