Re: [Zope-dev] official release policy ZTK is still not changed

2009-09-16 Thread Martijn Faassen
Hey,

Stephan Richter wrote:
[snip]
 -1 from me too. Having the previous version avoids having to look it up in 
 CHANGES.txt or the tags, which is really lame if you do lots of releasing.

 From private conversations here at the Grok sprint with Christian I 
think that means that the steering group has concluded the release 
policy remains unchanged for the ZTK.

For other packages of course other approaches can be taken - the ZTK 
steering group takes no authority there.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] official release policy ZTK is still not changed

2009-09-16 Thread Martijn Faassen
Hi there,

Unless you think you have a great argument that you think will make 
significant portions of the ZTK steering group change their mind on 
this, this discussion should now be closed.

We're sticking with our current release policy for the ZTK packages. 
This doesn't affect non-ZTK packages; the ZTK steering group explicitly 
takes no responsibility for those packages. As a personal preference of 
course I'd like some uniformity in this, but I can live with a divergence.

Regards,

Martijn


___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] official release policy ZTK is still not changed

2009-09-15 Thread Reinout van Rees
On 2009-09-11, Benji York be...@zope.com wrote:
 On Fri, Sep 11, 2009 at 10:41 AM, Jim Fulton j...@zope.com wrote:
 On Fri, Sep 11, 2009 at 10:11 AM, Martijn Faassen
 faas...@startifact.com wrote:
 * I (and others) use tools to do releases (zest.releaser in my case).
 These tools are based on this policy. Changing the policy breaks the tools.

 The proposed change would make this tool simpler. 

zest.releaser's job would not become simpler.  It currently grabs the version
(with or without dev marker) from either version.txt (old projects or
non-setup.py stuff) or the setup.py.  Suddenly it is '0' instead of '1.2dev'.
What's it going to suggest as new version?  Yeah, it grabs the tags from
subversion so it *can* make a decent guess.  But you cannot easily register I
want this to become 2.0 anymore.

  More importantly,
 it makes things simpler for people who don't use the tool.
 +1 -- reducing the number of tools necessary to (easily) accomplish a
 particular task is valuable.

I'd rather do a bin/fullrelease (one step) instead of following a 7-step
method to properly release a package.  And setting the version to 0 only adds
one more potential error point: where do you look up the next version?
Someone might have forgotten to tag the previous release (if you look at tags)
or might have forgotten to update the CHANGES.txt (if you look at that) or
have not uploaded it to pypi (if you look at that).

People aren't that good at repetitive tasks.  Use a small tool like
zest.releaser (or collective.releaser if you don't mind occasional 1.2-r1234
releases as that uses the setup.cfg for the dev marker).  Use such a tool and
you won't have to bash yourself or co-workers for

- forgetting to tag a release.

- forgetting to use 'register' in 'sdist upload register' so that the
  documentation on pypi isn't updated.

- forgetting to remove a dev marker (or changing the 0).

- Updating the changelog, preparing it for the next changes.


Well, we might as well do away with buildout.  Reducing the number of
tools...  Just do it by hand!


Reinout

-- 
Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
Military engineers build missiles. Civil engineers build targets

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] official release policy ZTK is still not changed

2009-09-15 Thread Reinout van Rees
On 2009-09-11, Martijn Faassen faas...@startifact.com wrote:

 Jim Fulton wrote:
 but if it is, I
 propose to using 0 instead of the dev of the next version.  Where I've
 used '0', I've found it to be less error prone.  Ir also requires less
 effort because it means you never have to edit the version on the
 trunk.

 I'm -1 to using 0.

-1

 Reasons:

 * it breaks dependencies on development versions which have version 
 requirements in it (see Wichert's comments on the original thread). 

Really important.  When I add an external to a trunk/branch version of
something as I need to fix/improve something, I immediately change the version
requirement in the setup.py.

What's better? Do a my.package  2.7 or leaving it at my.package = 2.5
and trusting your memory to change that afterwards?

You'll surely see the my.package == 0 when releasing (as stuff breaks),
which means more work as you have to look up version numbers again.

Make it easy to do the right thing instead of making it more work, I'd say.
The '0' means it is easier (human nature...) to just leave the version
requirement in the setup.py alone as it is too much hassle.

 * I (and others) use tools to do releases (zest.releaser in my case). 
 These tools are based on this policy. Changing the policy breaks the tools.

In case the policy is changed, I'll of course fix up the tool.  I'm still -1,
though :-)

 This way it is much easier to help new people get up to speed in our 
 community, maintain consistent practices, and people already in our 
 community will also have an easier time keeping track of what's going on.

A '0' version does little to help people pitching in with a bugfix.  They'll
have to figure out themselves what the version is supposed to be.

If you pick the my.project/branches/reinout-fixthingy branch and the version
is set to '0', you'll have to figure out what version of the branch is.
A 2.8 bugfix branch? A feature brach off the trunk?

The '0' seems especially unclear for branches.

 [I hope people who appreciate having such a policy will chip in here and 
 say yes, I want a written-down policy, please so it isn't just me who 
 is telling Jim this.]

for i in range(20):
print yes, I want a written-down policy, please



Reinout


-- 
Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
Military engineers build missiles. Civil engineers build targets

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] official release policy ZTK is still not changed

2009-09-15 Thread Stephan Richter
On Tuesday 15 September 2009, Reinout van Rees wrote:
 On 2009-09-11, Martijn Faassen faas...@startifact.com wrote:
  Jim Fulton wrote:
  but if it is, I
  propose to using 0 instead of the dev of the next version.  Where I've
  used '0', I've found it to be less error prone.  Ir also requires less
  effort because it means you never have to edit the version on the
  trunk.
 
  I'm -1 to using 0.

 -1

-1 from me too. Having the previous version avoids having to look it up in 
CHANGES.txt or the tags, which is really lame if you do lots of releasing.

Regards,
Stephan
-- 
Entrepreneur and Software Geek
Google me. Zope Stephan Richter
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] official release policy ZTK is still not changed

2009-09-15 Thread Tres Seaver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Stephan Richter wrote:
 On Tuesday 15 September 2009, Reinout van Rees wrote:
 On 2009-09-11, Martijn Faassen faas...@startifact.com wrote:
 Jim Fulton wrote:
 but if it is, I
 propose to using 0 instead of the dev of the next version.  Where I've
 used '0', I've found it to be less error prone.  Ir also requires less
 effort because it means you never have to edit the version on the
 trunk.
 I'm -1 to using 0.
 -1
 
 -1 from me too. Having the previous version avoids having to look it up in 
 CHANGES.txt or the tags, which is really lame if you do lots of releasing.

If you are making releases without having the CHANGES.txt open in your
browser, then you need to put down the keyboard and back away slowly, so
that nobody gets hurt.  Reviewing / correcting the changelog (and
comparing it with a diff from the last release) should be a fundamental
part of making a release.  At the very minimum, you're supposed to
update the release date in the changelog, right?

I *like* the property of the 0 strategy that it makes the job of
releasing a package a little harder:  releaseing software should be a
thoughtful, careful process, not something you do without a bit of
hesitation and review.


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

iD8DBQFKr/9i+gerLs4ltQ4RArnjAJsEFhiKH6pyOx9AYsoZVP1W0N3U5wCgivGn
jc897TMxlf9XAmW4K/TJjag=
=/fhs
-END PGP SIGNATURE-

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] official release policy ZTK is still not changed

2009-09-15 Thread Benji York
On Tue, Sep 15, 2009 at 4:56 PM, Tres Seaver tsea...@palladion.com wrote:
 I *like* the property of the 0 strategy that it makes the job of
 releasing a package a little harder:  releaseing software should be a
 thoughtful, careful process, not something you do without a bit of
 hesitation and review.

Well said.
-- 
Benji York
Senior Software Engineer
Zope Corporation
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] official release policy ZTK is still not changed

2009-09-15 Thread Reinout van Rees
On 2009-09-15, Tres Seaver tsea...@palladion.com wrote:

 If you are making releases without having the CHANGES.txt open in your
 browser, then you need to put down the keyboard and back away slowly, so
 that nobody gets hurt.  Reviewing / correcting the changelog (and
 comparing it with a diff from the last release) should be a fundamental
 part of making a release.  At the very minimum, you're supposed to
 update the release date in the changelog, right?

Checking the changelog: yes, do that.

And again, zest.releaser takes the make doing the right thing simple
approach by providing a lasttagdiff command to show the diff of the current
checkout with the last tag it can find in svn.  For the common case, this
helps a lot.

And updating the release date? Yes, zest.releaser does that for you so that
you never ever forget it.

(And yes, it first shows you a diff and asks you to press yes so you do get
to review it and you're constantly reminded about what's happening).

 I *like* the property of the 0 strategy that it makes the job of
 releasing a package a little harder:  releaseing software should be a
 thoughtful, careful process, not something you do without a bit of
 hesitation and review.

Seen from a different viewpoint, this also makes it an unappetizing yucky
event.  Human nature then quickly takes over and tries to find corners to
cut.  And human nature includes mistakes, so stuff is forgotten (like that
forgotten upload to pypi we saw here on the mailinglist).


Tres, is your preference something personal or is it something you'd like to
see everyone adopt?  In that case my zest.releaser would be quite high on
your things-to-torture list :-)  Which would sadden me a bit as my goals were:

- make it easy to do the good thing (like an easy diff with the last tag)

- make it painless and take the hassle out of it

- get more good releases.


The '0' would be something zest.releaser could code around, so it would defeat
the purpose of making it harder.  The loss of clarity would still be there.


Reinout


-- 
Reinout van Rees - rein...@vanrees.org - http://reinout.vanrees.org
Software developer at http://www.thehealthagency.com
Military engineers build missiles. Civil engineers build targets

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] official release policy ZTK is still not changed

2009-09-15 Thread Roger Ineichen
Hi

 Betreff: Re: [Zope-dev] official release policy ZTK is still 
 not changed
 
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1
 
 Stephan Richter wrote:
  On Tuesday 15 September 2009, Reinout van Rees wrote:
  On 2009-09-11, Martijn Faassen faas...@startifact.com wrote:
  Jim Fulton wrote:
  but if it is, I
  propose to using 0 instead of the dev of the next 
 version.  Where 
  I've used '0', I've found it to be less error prone.  Ir also 
  requires less effort because it means you never have to edit the 
  version on the trunk.
  I'm -1 to using 0.
  -1
  
  -1 from me too. Having the previous version avoids having 
 to look it 
  up in CHANGES.txt or the tags, which is really lame if you 
 do lots of releasing.
 
 If you are making releases without having the CHANGES.txt 
 open in your browser, then you need to put down the keyboard 
 and back away slowly, so that nobody gets hurt.  Reviewing / 
 correcting the changelog (and comparing it with a diff from 
 the last release) should be a fundamental part of making a 
 release.  At the very minimum, you're supposed to update the 
 release date in the changelog, right?
 
 I *like* the property of the 0 strategy that it makes the 
 job of releasing a package a little harder:  releaseing 
 software should be a thoughtful, careful process, not 
 something you do without a bit of hesitation and review.

I propose to delete the CHANGES.txt file after we tagged
the trunk. This will force people to carefully read all the
revisions till they will find the removed CHANGES.txt file
for restore them.

And of corse we should add a comit hook in subversion which
will not allow to tag a trunk without a CHANGES.txt file.

Hard enough?

just kidding,
Roger Ineichen

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] official release policy ZTK is still not changed

2009-09-11 Thread Jim Fulton
On Fri, Sep 11, 2009 at 8:55 AM, Martijn Faassen faas...@startifact.com wrote:
 Hi there,

 Apparently some people are using '0' instead of the next version for
 packages in the ZTK.

 Please do not do this for ZTK packages. The official policy for
 releasing is here.

 http://docs.zope.org/zopetoolkit/process/releasing-software.html

I don't understand why this would be important, but if it is, I
propose to using 0 instead of the dev of the next version.  Where I've
used '0', I've found it to be less error prone.  Ir also requires less
effort because it means you never have to edit the version on the
trunk.

Jim

-- 
Jim Fulton
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] official release policy ZTK is still not changed

2009-09-11 Thread Martijn Faassen
Hey,

Jim Fulton wrote:
 On Fri, Sep 11, 2009 at 8:55 AM, Martijn Faassen faas...@startifact.com 
 wrote:
 Hi there,

 Apparently some people are using '0' instead of the next version for
 packages in the ZTK.

 Please do not do this for ZTK packages. The official policy for
 releasing is here.

 http://docs.zope.org/zopetoolkit/process/releasing-software.html
 
 I don't understand why this would be important,

?!..

See my comment below.

 but if it is, I
 propose to using 0 instead of the dev of the next version.  Where I've
 used '0', I've found it to be less error prone.  Ir also requires less
 effort because it means you never have to edit the version on the
 trunk.

I'm -1 to using 0.

Reasons:

* it breaks dependencies on development versions which have version 
requirements in it (see Wichert's comments on the original thread). 
We're supposed to be maintaining these: see the version requirements in 
setup.py decision of the steering group: 
http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html

* I (and others) use tools to do releases (zest.releaser in my case). 
These tools are based on this policy. Changing the policy breaks the tools.

* change with little gain (and some loss) to a policy which we've had 
for years and works fine. (Philipp wrote this sometime in 2007 or so, 
and we were already having debates about doing VBs back then. Christian 
added it in the documentation that turned into the ZTK documentation 
right away)

I'm also particularly disgruntled that people just started deviating 
from the ZTK policy without discussion. Goes completely against the 
point of having a steering group and a written down policy.

Comments like I don't understand why this should be important don't 
improve my mood. The whole point of writing down policy is so everybody 
knows what it is and will use it, instead of it being some randomly 
evolving community practice.

This way it is much easier to help new people get up to speed in our 
community, maintain consistent practices, and people already in our 
community will also have an easier time keeping track of what's going on.

[I hope people who appreciate having such a policy will chip in here and 
say yes, I want a written-down policy, please so it isn't just me who 
is telling Jim this.]

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] official release policy ZTK is still not changed

2009-09-11 Thread Jim Fulton
On Fri, Sep 11, 2009 at 10:11 AM, Martijn Faassen
faas...@startifact.com wrote:
 Hey,

 Jim Fulton wrote:
 On Fri, Sep 11, 2009 at 8:55 AM, Martijn Faassen faas...@startifact.com 
 wrote:
 Hi there,

 Apparently some people are using '0' instead of the next version for
 packages in the ZTK.

 Please do not do this for ZTK packages. The official policy for
 releasing is here.

 http://docs.zope.org/zopetoolkit/process/releasing-software.html

 I don't understand why this would be important,

 ?!..

 See my comment below.

 but if it is, I
 propose to using 0 instead of the dev of the next version.  Where I've
 used '0', I've found it to be less error prone.  Ir also requires less
 effort because it means you never have to edit the version on the
 trunk.

 I'm -1 to using 0.

 Reasons:

 * it breaks dependencies on development versions which have version
 requirements in it (see Wichert's comments on the original thread).

I'm not sure I understand this.

 We're supposed to be maintaining these: see the version requirements in
 setup.py decision of the steering group:
 http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html

'0' becomes another name for trunk so anything that specified
version requirements with a lower bound would need to also include
==0.


 * I (and others) use tools to do releases (zest.releaser in my case).
 These tools are based on this policy. Changing the policy breaks the tools.

The proposed change would make this tool simpler.  More importantly,
it makes things simpler for people who don't use the tool.


 * change with little gain (and some loss)

I don't see a loss.

 to a policy which we've had
 for years and works fine. (Philipp wrote this sometime in 2007 or so,
 and we were already having debates about doing VBs back then. Christian
 added it in the documentation that turned into the ZTK documentation
 right away)

Right, Philipp wrote a process that was pretty good. People followed
it and in the process we found it could be improved.

 I'm also particularly disgruntled that people just started deviating
 from the ZTK policy without discussion. Goes completely against the
 point of having a steering group and a written down policy.

I'm sorry you're disgruntled. I wasn't aware that this was a ZTK policy.

I've been using '0' since before there was a ZTK.  I never proposed it
as any sort of standard before, because I wanted to try it for a while
first and see if it was an improvement.

 Comments like I don't understand why this should be important don't
 improve my mood. The whole point of writing down policy is so everybody
 knows what it is and will use it, instead of it being some randomly
 evolving community practice.

Not everything is of equal importance.  I don't consider this very
important, other than that it seems to be important to you.

 This way it is much easier to help new people get up to speed in our
 community, maintain consistent practices, and people already in our
 community will also have an easier time keeping track of what's going on.

 [I hope people who appreciate having such a policy will chip in here and
 say yes, I want a written-down policy, please so it isn't just me who
 is telling Jim this.]

I don't mind if there are standards and I wasn't proposing that there
shouldn't be. I was proposing a change to the standard. For ZTK
packages, I'm willing to follow the standard.

I don't agree with this particular standard and won't follow it for my
own non-ZTK packages.

Jim

-- 
Jim Fulton
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] official release policy ZTK is still not changed

2009-09-11 Thread Benji York
On Fri, Sep 11, 2009 at 10:41 AM, Jim Fulton j...@zope.com wrote:
 On Fri, Sep 11, 2009 at 10:11 AM, Martijn Faassen
 faas...@startifact.com wrote:
 * I (and others) use tools to do releases (zest.releaser in my case).
 These tools are based on this policy. Changing the policy breaks the tools.

 The proposed change would make this tool simpler.  More importantly,
 it makes things simpler for people who don't use the tool.

+1 -- reducing the number of tools necessary to (easily) accomplish a
particular task is valuable.
-- 
Benji York
Senior Software Engineer
Zope Corporation
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] official release policy ZTK is still not changed

2009-09-11 Thread Martijn Faassen
Jim Fulton wrote:

 * it breaks dependencies on development versions which have version
 requirements in it (see Wichert's comments on the original thread).
 
 I'm not sure I understand this.

I think your answer is below, and your solution would be to add a == 0 
to the dependencies.

 We're supposed to be maintaining these: see the version requirements in
 setup.py decision of the steering group:
 http://docs.zope.org/zopetoolkit/steeringgroup/decisions.html
 
 '0' becomes another name for trunk so anything that specified
 version requirements with a lower bound would need to also include
 ==0.

That affects the ZTK policy I mentioned above. It would also need to 
change to support the 0 convention.

 * I (and others) use tools to do releases (zest.releaser in my case).
 These tools are based on this policy. Changing the policy breaks the tools.
 
 The proposed change would make this tool simpler.  More importantly,
 it makes things simpler for people who don't use the tool.

The tool is already there. Making it simpler is not of a major concern, 
I'd say; that'd only mean extra work at this point.

I can see it makes it simpler for people who don't use the tool, though 
I cannot see the full scope of it yet, as I haven't seen a list of steps 
people would need to take. It does make the (version-including) 
dependencies slightly messier to read, however.

 * change with little gain (and some loss)
 
 I don't see a loss.

I think just a simple version dependency without the == 0 is simpler to 
do right, and more likely to be understood by people coming in. You're 
exchanging a cost in work (doing the vb) that isn't reflected in code 
with a cost in the dependencies listing in setup.py, that is reflected 
in code.

In addition, there is the cost of change. In particular, making this 
change involves two policy changes and a tool change. People need to 
become aware of these changes.

[snip]
 I'm also particularly disgruntled that people just started deviating
 from the ZTK policy without discussion. Goes completely against the
 point of having a steering group and a written down policy.
 
 I'm sorry you're disgruntled. I wasn't aware that this was a ZTK policy.

May I kindly recommend to you as a fellow steering group member that you 
read about the ZTK policies on the ZTK website? This may help us avoid a 
few more surprises like this in the future...

 I don't mind if there are standards and I wasn't proposing that there
 shouldn't be. I was proposing a change to the standard. For ZTK
 packages, I'm willing to follow the standard.

Thanks.

Christian Theune and Stephan Richter might both go +1 on this change - 
perhaps you ask them to read the threads involved and it's quite 
possible you can convince them for this change. I'd be outvoted.

I think a sketch of what this document would look like under the new 
policy would be useful to see in advance to help with the evaluation:

http://docs.zope.org/zopetoolkit/process/releasing-software.html

And if the steering group decides in favor of this change, I'd like to 
ask those in favor of this policy change to adjust the ZTK documents in 
this case.

I take it that all version dependencies in setup.py would need to be 
modified to include == 0 too, though I imagine this can be done on a 
case by case basis. I think a description on how one takes a package 
under development (in combination with an existing package that uses it, 
such as with an external) would be a valuable addition to our existing 
documentation.

  Not everything is of equal importance.  I don't consider this very
  important, other than that it seems to be important to you.

Let me explain to you what exactly I find important in this matter.

* I want to remind people of what the ZTK policy is and not to use the 
other approach for ZTK packages until that policy is changed.

* I want to point out the importance of having a written down policy for 
things and people actually following it.

* I want to make sure that when people want to change a policy, they are 
aware of the need to discuss it in advance, not after people already 
started doing different things.

* I want to critically discuss the impact of adopting this new policy, 
comparing it to the old policy, and evaluating the cost of changing. 
We've seen that this change impacts several existing policies of the ZTK 
and a tool that at least some people use.

All this sounds bureaucratic, but it's better than having all sorts of 
undocumented policies that newcomers can't figure out at all, and that 
existing developers have a much harder time to track.

I think all these points have been made clear to people involved in this 
discussion. I'm looking forward to seeing Stephan and Christian's 
opinions on this change.

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 

Re: [Zope-dev] official release policy ZTK is still not changed

2009-09-11 Thread Jim Fulton
I'm guilty of causing most these packages to violate the standards,
while making their tests pass.

Jim

On Fri, Sep 11, 2009 at 11:39 AM, Martijn Faassen
faas...@startifact.com wrote:
 Hi there,

 I was doing some thrawling of ZTK packages anyway, and this was easy.
 So,  it appears the following ZTK packages now follow the 'version=0'
 convention:

 zope.copypastemove
 zope.html
 zope.app.applicationcontrol
 zope.app.basicskin
 zope.app.i18n
 zope.app.publication
 zope.app.pythonpage
 zope.app.security

 The rest seems to follow the official convention. Depending on the
 outcome of this discusion we'll need to figure out how to get all the
 packages in sync with what the policy will be (and describe it).

 Regards,

 Martijn

 ___
 Zope-Dev maillist  -  zope-...@zope.org
 https://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  **
 (Related lists -
  https://mail.zope.org/mailman/listinfo/zope-announce
  https://mail.zope.org/mailman/listinfo/zope )




-- 
Jim Fulton
___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] official release policy ZTK is still not changed

2009-09-11 Thread Martijn Faassen
Jim Fulton wrote:
 I'm guilty of causing most these packages to violate the standards,
 while making their tests pass.

Wasn't my intent to track down the guilty, just ran into this 
information and wanted to record it for posterity.

Making their tests pass is of course way more important than this 
particular standard, so thanks for doing that. :)

Regards,

Martijn

___
Zope-Dev maillist  -  Zope-Dev@zope.org
https://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 https://mail.zope.org/mailman/listinfo/zope-announce
 https://mail.zope.org/mailman/listinfo/zope )