Hi there,
Because my suggestions (besides the fork issue) as a ZTK
user/contributor were scattered through the thread, here's a handy summary:
* please construct guidelines for updating the ZTK when making a release
of a package that's managed by the ZTK project. It's useful people
test
Hi Martijn,
On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen faas...@startifact.com wrote:
Because my suggestions (besides the fork issue) as a ZTK
user/contributor were scattered through the thread, here's a handy summary:
Thank you very much for your suggestions. I'm sure the release team
Hanno Schlichting wrote:
Hi Martijn,
On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen faas...@startifact.com
wrote:
Because my suggestions (besides the fork issue) as a ZTK
user/contributor were scattered through the thread, here's a handy summary:
Thank you very much for your
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Martijn Faassen wrote:
Hanno Schlichting wrote:
Hi Martijn,
On Mon, May 3, 2010 at 2:03 PM, Martijn Faassen faas...@startifact.com
wrote:
Because my suggestions (besides the fork issue) as a ZTK
user/contributor were scattered through the
Hi there,
Tres Seaver wrote:
One issue with insta-updates to ztk.cfg is that ongoing development of a
package can be in real tension with the needs of ZTK consumers for
stability in the package set.
Since there are no ZTK releases Grok and BlueBream gain stability by
pinning to a
On Mon, May 3, 2010 at 20:13, Martijn Faassen faas...@startifact.com wrote:
Since there are no ZTK releases Grok and BlueBream gain stability by
pinning to a particular revision of ztk.cfg (and moving it forward when
needed). Zope 2 could easily do the same. If more is needed, then a
branch or
Lennart Regebro wrote:
On Mon, May 3, 2010 at 20:13, Martijn Faassen faas...@startifact.com wrote:
Since there are no ZTK releases Grok and BlueBream gain stability by
pinning to a particular revision of ztk.cfg (and moving it forward when
needed). Zope 2 could easily do the same. If more is
On Mon, May 3, 2010 at 21:57, Martijn Faassen faas...@startifact.com wrote:
I think the list needs to commit to something
If it needs to commit to what packages are included, then there is no
reason to call it an alpha, and also, we can't do it now. So then the
status persists with the users of
Thanks for these suggestions. This is *exactly* what we (the ztk release team)
need.
Are there other recommendations from other people?
Martijn Faassen a écrit :
Hi there,
Because my suggestions (besides the fork issue) as a ZTK
user/contributor were scattered through the thread, here's a
Hey,
Christophe Combelles wrote:
Thanks for these suggestions. This is *exactly* what we (the ztk
release team) need.
How wonderfully diplomatic and constructive, my compliments! The
release team (you, Hanno and JW) look good to me.
* please let these guidelines not block most updates by
Hi again,
One more suggestion I can make is a way to get an integrated changelog
for lists of packages such as the ZTK. Right now it's hard to track what
kind of changes there have been in the ZTK as a whole; you have to go
through all packages. If there were a way to generate a unified
11 matches
Mail list logo
