ZTK release team - kickoff meeting - delayed summary
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
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
participants (2)
-
Hanno Schlichting -
Martijn Faassen