[Zope-dev] ZTK release team - kickoff meeting - delayed summary

[Hanno Schlichting]

Hi there,

I've been slacking and forgot to post the summary of the first ZTK
release team meeting.

Here it is. I'll put it into SVN into the ztk-docs area as well.

Cheers,
Hanno

ZTK meeting - 2010-05-06


Attendance
--

ccomb, j-w, hannosch

Agenda
--

- No fixed agenda, this is a kick-off meeting.

Discussion
--

Communication

- We'll use the zope-dev mailing list for our discussions and no separate list

Our role

- We see ourselves as representatives of communities that make use of the ZTK
- We should ensure stable releases of the ZTK, which are useful to our projects
  not more and not less

Release outcome

- Should produce a http://download.zope.org/ztk/release/1.1 with a ztk.cfg in
  it and a the zopeapp.cfg (for as long as it exists) in it.
- Nice to have: an index (for easy_install people)
- Should have some documentation site stating changes
  (http://docs.zope.org/zopetoolkit/releases/overview-trunk.html)

Release policies

- At first manual releases (x.y.Z), automate the process to generate the bugfix
  releases later. We need to make sure to release only versions sets for which
  all tests passed.

- ztk x.y.z. releases, stable package list per release

- a ztk minor release per month would be ok

- a ztk major release when one of the consumers projects needs it.

- backward compatibility breaking only happens in X.y.z that means, if we have
  a zope.component 4.0.0, it will be part of ZTK 2.0 or 3.0

- generally upstream releases happen in a 6-12 month interval, so the same
  timeline makes sense for ZTK releases

Tasks
-

- We want 64bit Linux and Windows tests for the ZTK. j-w is bugging janjaap to
  create those. Maybe contact ccomb for adding slaves to afpy [j-w]

- Make sure we have a buildbot testing the ZTK releases (and not SVN) [ccomb]

Open points
---

- Look at Tres's list of packages in all three frameworks, decide on a way to
  drop things from the initial ZTK set and on a process for the future.

- Look at and update http://docs.zope.org/zopetoolkit/about/coreextra.html for
  adding/removing policies, probably have a deprecated.cfg file

- Decide on process for new feature versions and the process for going from
  1.1.0 alpha to a final

Next meeting


2010-05-18, 14:00 to 15:00 UTC before the zope-dev meeting, in #zope
___
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] ZTK release team - kickoff meeting - delayed summary

[Martijn Faassen]

Hanno Schlichting wrote:

 - Look at Tres's list of packages in all three frameworks, decide on a way to
   drop things from the initial ZTK set and on a process for the future.

As long as things are not dropped immediately. Even though Grok 1.2 
might not need foo.bar, transition support might mean it requires it 
still for those people who are porting over existing projects.

Note also that Tres' list is not exactly accurate as it comes to Grok, 
as Tres assumed that information about deprecation in Grok's setup.py 
was actually correct. :). Please be careful with that. I think Grok's 
upcoming 1.2 list will be better.

  - Look at and update
  http://docs.zope.org/zopetoolkit/about/coreextra.html for
adding/removing policies, probably have a deprecated.cfg file

A deprecated.cfg would be a way to support this. Most of zopeapp.cfg 
could eventually go into deprecated.cfg.

The tricky question is what to do those things in zopeapp.cfg which 
won't be deprecated any time soon. An example is zope.app.wsgi. Should 
it stay in zopeapp.cfg? we could rename it to zope.wsgi and move it into 
the ztk.cfg too.

You can then argue that since Zope 2 doesn't use it, it shouldn't be in 
the ZTK, but there are already packages in the ZTK that aren't used by 
Zope 2. If we moved the four to six things out of zopeapp.cfg over into 
ztk.cfg (and deprecated the rest) might that be an acceptable extra 
burden for those who don't use these packages?

Eventually of course we'd even want to dump deprecated stuff completely 
so that we don't need to maintain it at all anymore. We can even move 
that code into a subdir in SVN and put markers in pypi. You'd need a 
clear procedure for that too.

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 )