Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Zope: Dev

zope.testing feature creep in release (WAS: zope.testing.doctestunit and BBB)

 

 

Zope dev RSS feed   Index | Next | Previous | View Threaded


ct at gocept

Dec 23, 2009, 1:58 AM

Post #1 of 2 (435 views)
Permalink
zope.testing feature creep in release (WAS: zope.testing.doctestunit and BBB)

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/23/2009 10:55 AM, Lennart Regebro wrote:
| On Wed, Dec 23, 2009 at 10:25, Christian Theune<ct [at] gocept> wrote:
|> Is this about getting rid of our own doctest and relying on Python's
|> standard doctest module?
|
| The deprecations are, yes. The problem (which has now been fixed) is
| that some BBB imports was not marked as being BBB imports and
| therefore was removed in a cleanup.

Sounds like regular maintenance for me then which I won't oppose
regarding a release.

On a related note: we're getting sloppy with the zope.testing releases
AFAICT as the current minor version included several feature changes. I
sneaked in the last one myself because I wanted to get rid of that
review without having to think hard about the already broken branch.

Nevertheless, I think the (agile, many, flexible, easy) releases and not
branching the trunk at all start hurting us here as we're getting lost
in our own policy. Any ideas for limiting feature creep?

Christian

- --
Christian Theune · ct [at] gocept
gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany
http://gocept.com · tel +49 345 1229889 0 · fax +49 345 1229889 1
Zope and Plone consulting and development
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAksx6d4ACgkQdUt9X/gknwLzYQCgwyC7AYcKtEKjt9byVDhRkrtH
FQIAoK7ku/+gWcPEnO5GBPWYzPNuHK6N
=HFJc
-----END PGP SIGNATURE-----
Attachments: smime.p7s (3.74 KB)


benji at zope

Dec 23, 2009, 7:12 AM

Post #2 of 2 (396 views)
Permalink
Re: zope.testing feature creep in release (WAS: zope.testing.doctestunit and BBB) [In reply to]

On Wed, Dec 23, 2009 at 4:58 AM, Christian Theune <ct [at] gocept> wrote:
> Nevertheless, I think the (agile, many, flexible, easy) releases and not
> branching the trunk at all start hurting us here as we're getting lost
> in our own policy. Any ideas for limiting feature creep?

Two comments:

Whenever I wish I had created a major release branch (like
/branches/1.5) at that point I go back and create one by copying the
1.5.0 tag. That way you have the best of both worlds, you don't have to
remember to create major release branches (that you may never use) and
you can have them if you end up doing significant maintenance on that
version.

As for having a broken trunk: I believe that every project needs a head
maintainer that feels personally responsible for the state of a
particular project. They would be in charge of reviewing and approving
branches before they are merged to the project trunk.

We've inherited a communal process from the pre-explosion days that
worked well there, but there are just too many projects for the
community to keep track of and to care for.
--
Benji York
_______________________________________________
Zope-Dev maillist - Zope-Dev [at] zope
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 )

Zope dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.