Re: [Zope-dev] People in the Zope 3 and ZMI teams

2009-04-21 Thread Yusei TAHARA
Hi Roger,

Thank you very much for your comment, and sorry for my late reply.
I did not receive your post I don't know why...

  Betreff: Re: [Zope-dev] People in the Zope 3 and ZMI teams
  
  Hi,
  
  I just start working on maintaining ZMI and make it optional package.
  For now, it is easy to participate, just porting zope.app.* 
  (I already list up targets as directories in zmi.core) and 
  make sure that existing tests succeeds.
 
 Can you tell a little bit about what you mean with tests succeed?
 Should the test in the existing package succeed? But this whould
 mean that the old packages we move the zmi parts from needs to depend
 on the new zmi.core package.
 
 Should the old zope.app.* package depend on the new zmi.core package?
 (I think not)

No. But zmi.core might depend on zope.app.* packages.


 Or should we break BBB and let people know that they have to install
 zmi.core for zmi support? (I think so)

I won't break BBB as much as possible, at least I'd like to keep persistent 
data compatibility...


 If so, then the test should succeed in the new zmi.core packages, right?

Yes, my intention was to make sure that after we copy files from zope.app.* to 
zmi.core.*,
then existing tests which were originally in zope.app.* have to work in 
zmi.core.*.


 Can you write down some comment how we sould do the refactoring
 like:
 
 - move the zmi part from a zope.app.* package to
   the new zmi.core.* package.

Yes.

 - make sure the test pass in both packages. The zmi
   test should all get moved to the new zmi.core.* package
   Probably enhance the tests since the zmi part was not very 
   well tested.

Yes.

 - release the zmi.core package after each package move
   or at least before the zope.app.* package get released
 
 - bump up the zope.app.* package version (full not partial)
   e.g. 3.5.1 to 3.6.0

Hmm, I'm not sure yet...

 Not sure if the above is correct. Please change if not.
 It is at least only correct if we break BBB and move the zmi
 completly out of all zope.app packages to zmi.core.
 
 And probably we should also implement a testing layer setup
 which all test in zmi.core can share/use.

Sounds good idea.

For now, I don't have clear image yet. I'm checking all zope.app.* packages and 
make
sure all tests pass. And maybe I will review current package dependencies.
After that, I will copy zmi parts to zmi.core one by one. I'm sorry but I'm 
very slow
for some reasons, I cannot make an exact schedule yet.

Best regards,
-- 
Yusei TAHARA yu...@domen.cx
___
Zope-Dev maillist  -  Zope-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zope-dev
**  No cross posts or HTML encoding!  **
(Related lists - 
 http://mail.zope.org/mailman/listinfo/zope-announce
 http://mail.zope.org/mailman/listinfo/zope )


Re: [Zope-dev] People in the Zope 3 and ZMI teams

2009-04-21 Thread Martijn Faassen
Yusei TAHARA wrote:
[snip]
 Should the old zope.app.* package depend on the new zmi.core package?
 (I think not)
 
 No. But zmi.core might depend on zope.app.* packages.

I think this should be avoided if we can. The idea is to lose the 
dependency of the zope.app.* packages for the ZMI, after all.

Of course there are exceptions: if you rely on a zope.app.* package that 
hasn't really been moved to zope.* yet (zope.app.form.browser for 
instance). But relying on zope.app.*.browser should be avoided in most 
cases, otherwise we create circular dependencies.

 Or should we break BBB and let people know that they have to install
 zmi.core for zmi support? (I think so)
 
 I won't break BBB as much as possible, at least I'd like to keep persistent 
 data compatibility...

But the ZMI is all views, right? What is persistent?

For BBB, you want the zope.app.*.browser packages to import from 
zmi.core, not the other way around. Otherwise we don't clean up 
dependencies at all.

[snip]
 - bump up the zope.app.* package version (full not partial)
   e.g. 3.5.1 to 3.6.0
 
 Hmm, I'm not sure yet...

I think this should be done; if you update a zope.app.* package to 
import its ZMI stuff from zmi.* a new release of the zope.app.* package 
should eventually be made, and it should have a new feature release (so 
increase y in x.y.z).

[snip]
 For now, I don't have clear image yet. I'm checking all zope.app.* packages 
 and make
 sure all tests pass. And maybe I will review current package dependencies.

For that, you might want to investigate the z3c.recipe.depgraph recipe 
to generate dependency graphs. To try it against trunks you need to add 
them to 'develop' in your buildout.cfg

 After that, I will copy zmi parts to zmi.core one by one. I'm sorry but I'm 
 very slow
 for some reasons, I cannot make an exact schedule yet.

I don't think you're slow at all. Your plan sounds good and I'm glad you 
have Roger giving you feedback.

Regards,

Martijn

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


Re: [Zope-dev] People in the Zope 3 and ZMI teams

2009-04-21 Thread Roger Ineichen
Hi Martijn, Yusei

I think there is a little confusion about which package depends on
each other.

Right now there is a zmi.core package this package should
contain core parts without to much dependency. After that
we need several zmi.* packages which are replacements for
each zope.app.* package. right?

I think it should be like:

1. zope.app.foo moves ZMI code to zmi.foo

2. zope.app.foo imports the zmi code from it's zmi.foo package


This allows us to move the zmi code from the zope.app packages
to zmi packages. Custom projects can then depend on zmi.foo
and skip the dependency to zope.app.foo. (at least for the zmi)
probably some zope.app.* packages contain only zmi code
probably some contain other code like Martijn told with
zope.app.form. That's fine and is not a part of our refactoring.

Projects which depend on zope.app.foo and will use the latest code
will get pulled in the zmi.foo package without any other dependecy
and should just work without to change the project setup since the
zope.app.foo package defines the zmi.foo dependency in thier
setup.py file.


btw,
I think we should refactor the old menu implementaiton too
ar at least review it since this part is very, very slow.
But that's another part and could probably done after
finishing the zmi refactoring part.

Regards
Roger Ineichen


 Betreff: Re: [Zope-dev] People in the Zope 3 and ZMI teams
 
 Yusei TAHARA wrote:
 [snip]
  Should the old zope.app.* package depend on the new 
 zmi.core package?
  (I think not)
  
  No. But zmi.core might depend on zope.app.* packages.
 
 I think this should be avoided if we can. The idea is to lose 
 the dependency of the zope.app.* packages for the ZMI, after all.
 
 Of course there are exceptions: if you rely on a zope.app.* 
 package that hasn't really been moved to zope.* yet 
 (zope.app.form.browser for instance). But relying on 
 zope.app.*.browser should be avoided in most cases, otherwise 
 we create circular dependencies.
 
  Or should we break BBB and let people know that they have 
 to install 
  zmi.core for zmi support? (I think so)
  
  I won't break BBB as much as possible, at least I'd like to 
 keep persistent data compatibility...
 
 But the ZMI is all views, right? What is persistent?
 
 For BBB, you want the zope.app.*.browser packages to import 
 from zmi.core, not the other way around. Otherwise we don't 
 clean up dependencies at all.
 
 [snip]
  - bump up the zope.app.* package version (full not partial)
e.g. 3.5.1 to 3.6.0
  
  Hmm, I'm not sure yet...
 
 I think this should be done; if you update a zope.app.* 
 package to import its ZMI stuff from zmi.* a new release of 
 the zope.app.* package should eventually be made, and it 
 should have a new feature release (so increase y in x.y.z).
 
 [snip]
  For now, I don't have clear image yet. I'm checking all zope.app.* 
  packages and make sure all tests pass. And maybe I will 
 review current package dependencies.
 
 For that, you might want to investigate the 
 z3c.recipe.depgraph recipe to generate dependency graphs. To 
 try it against trunks you need to add them to 'develop' in 
 your buildout.cfg
 
  After that, I will copy zmi parts to zmi.core one by one. I'm sorry 
  but I'm very slow for some reasons, I cannot make an exact 
 schedule yet.
 
 I don't think you're slow at all. Your plan sounds good and 
 I'm glad you have Roger giving you feedback.
 
 Regards,
 
 Martijn
 
 ___
 Zope-Dev maillist  -  Zope-Dev@zope.org
 http://mail.zope.org/mailman/listinfo/zope-dev
 **  No cross posts or HTML encoding!  ** (Related lists -  
 http://mail.zope.org/mailman/listinfo/zope-announce
  http://mail.zope.org/mailman/listinfo/zope )
 

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