Re: [Zope-dev] People in the Zope 3 and ZMI teams
Hey, Roger Ineichen wrote: 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? Right. Note that I'm against making too many zmi.* packages right now, keep it all in a few packages now. Concerning dependencies, let's first talk about zope.container: zmi should depend on zope.container zope.app.container.browser should have backwards compatibility imports from zmi, and zope.app.container should depend on zmi Now let's talk about a package that *hasn't* been factored away from zope.app.* yet, such as zope.app.file: in this case, zmi would depend on zope.app.file but zope.app.file.browser would depend on zmi. That's a circular dependency, which we should break as soon as possible by moving zope.app.file's content objects to zope.file or something like that. 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 Agreed. 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. Agreed. 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. Agreed; do it after the zmi refactoring. Thanks Roger for the coordination. I think we all agree on where we need to go, which is good. 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
Hi, On Tue, 21 Apr 2009 18:40:51 +0200 Martijn Faassen faas...@startifact.com wrote: 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? Yes, you're right. It's my mistake...We would not have any persistent data in zmi package. 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 Oh I did not know that. Thanks. 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
Hi, On Wed, 22 Apr 2009 09:48:40 +0200 Martijn Faassen faas...@startifact.com wrote: Hey, Roger Ineichen wrote: 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? Right. Note that I'm against making too many zmi.* packages right now, keep it all in a few packages now. Concerning dependencies, let's first talk about zope.container: zmi should depend on zope.container zope.app.container.browser should have backwards compatibility imports from zmi, and zope.app.container should depend on zmi Now let's talk about a package that *hasn't* been factored away from zope.app.* yet, such as zope.app.file: in this case, zmi would depend on zope.app.file but zope.app.file.browser would depend on zmi. That's a circular dependency, which we should break as soon as possible by moving zope.app.file's content objects to zope.file or something like that. I see, this is very clear. BTW, what do you think of zope.app.form? As far as I know, it has some basic interfaces like IInputWidget and IDisplayWidget, and they are used by various packages. Then I don't see any reason to leave them under zope.app.form. So, I think maybe we could also move them to zope.form or somewhere generic package after we finish zmi package. 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
Hey, Yusei TAHARA wrote: [snip] BTW, what do you think of zope.app.form? As far as I know, it has some basic interfaces like IInputWidget and IDisplayWidget, and they are used by various packages. Then I don't see any reason to leave them under zope.app.form. So, I think maybe we could also move them to zope.form or somewhere generic package after we finish zmi package. I think we should consider reorganizing everything in zope.app.form (including zope.app.form.browser) at some point. The widgets in zope.app.form.browser could be called zope.formlibwidgets or something like that (better name would be nice). I'm not sure where the interfaces in zope.app.form should go though - zope.form sounds a bit generic, and there is a competing form framework in z3c.form - things might be confusing. Perhaps we can simply move these interfaces to zope.formlib? zope.app.form.browser also contains the old ZML directives implementation to create forms using ZCML directivess, so we could leave them in zope.app.form.browser Thanks for your 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
Hi Martijn Betreff: Re: [Zope-dev] People in the Zope 3 and ZMI teams Hey, Roger Ineichen wrote: 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? Right. Note that I'm against making too many zmi.* packages right now, keep it all in a few packages now. Concerning dependencies, let's first talk about zope.container: zmi should depend on zope.container zope.app.container.browser should have backwards compatibility imports from zmi, and zope.app.container should depend on zmi Now let's talk about a package that *hasn't* been factored away from zope.app.* yet, such as zope.app.file: in this case, zmi would depend on zope.app.file but zope.app.file.browser would depend on zmi. That's a circular dependency, which we should break as soon as possible by moving zope.app.file's content objects to zope.file or something like that. Agreed, we should at the same time split the packages like we did with others. 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 Agreed. 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. Agreed. 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. Agreed; do it after the zmi refactoring. Thanks Roger for the coordination. I think we all agree on where we need to go, which is good. Yes, sounds good to me too Yusei, I'm out of the office till next monday. but I can answer mails if you have questions. Regards Roger Ineichen 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 )
Re: [Zope-dev] People in the Zope 3 and ZMI teams
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
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
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 )
Re: [Zope-dev] People in the Zope 3 and ZMI teams
Hi 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) Or should we break BBB and let people know that they have to install zmi.core for zmi support? (I think so) If so, then the test should succeed in the new zmi.core packages, right? 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. - 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. - 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 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. Regards Roger Ineichen _ END OF MESSAGE 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 ) ___ 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
Hi, On Fri, 17 Apr 2009 13:09:05 +0200 Fabio Tranchitella kob...@kobold.it wrote: To be honest, zope3 (as it is today) is a nice platform for me and for my company to build web applications (and, in general, the ZCA is a nice platform for building not-only-web applications), and it would be a shame to loose it. ZCA will be improved by ZTK, so I don't worry. To make explicit: I am not talking just about maintaining the ZMI, I'm talking about making zope3 a *real* user-friendly web framework, as (for example) grok is already right now. For me, my main purpose is maintaing the ZMI as an application server on ZTK, because I find it still useful for maintenance/configuration on the spot for example. But making Zope3(though it is still ambiguous for me)/ZTK user- friendly sounds a very nice idea. I could imagine a lot of packages might makes beginners shrink a bit, although we already have nice books. 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
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. 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
Hi From: zope-dev-boun...@zope.org [mailto:zope-dev-boun...@zope.org] On Behalf To be honest, zope3 (as it is today) is a nice platform for me and for my company to build web applications (and, in general, the ZCA is a nice platform for building not-only-web applications), and it would be a shame to loose it. Agreed that ZCA has great pottencial to be used as not-only-web-framework I have used ZCA+ZODB successfully in some desktop only projects Roman ___ 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
Hello there, * 2009-04-16 09:44, Martijn Faassen wrote: Just so we don't lose track of who are interested in maintaining Zope 3 (and/or the ZMI). I've distilled the following list of people who are interested in helping maintain Zope 3. This might mean making sure existing apps work, maintaining or replacing the ZMI, and working on making sure installation works. We can work out these details over time. I've just checked out that the domain zope3.org is not owned by the Zope Corporation. Do you have any idea about it? Would it be possible to claim it back? I'm thinking about taking over maintenance of zope3 in the wider term (not only maintaining the code, but also the community around it). To be honest, zope3 (as it is today) is a nice platform for me and for my company to build web applications (and, in general, the ZCA is a nice platform for building not-only-web applications), and it would be a shame to loose it. To make explicit: I am not talking just about maintaining the ZMI, I'm talking about making zope3 a *real* user-friendly web framework, as (for example) grok is already right now. Thanks. -- Fabio Tranchitella http://www.kobold.it Free Software Developer and Consultant http://www.tranchitella.it _ 1024D/7F961564, fpr 5465 6E69 E559 6466 BF3D 9F01 2BF8 EE2B 7F96 1564 ___ 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
Hey Fabio, Thanks again for coming back on this, this is quite encouraging. Fabio Tranchitella wrote: I've just checked out that the domain zope3.org is not owned by the Zope Corporation. Do you have any idea about it? Would it be possible to claim it back? I don't know, unfortunately. I'm thinking about taking over maintenance of zope3 in the wider term (not only maintaining the code, but also the community around it). I might've missed your statement on this before, but do you think you could work with a renamed Zope 3? The same technology but with a different name? We could easily create a 'foo.zope.org' for it just like we have 'grok.zope.org', or we could of course start with a new domain name. I think a fresh take on Zope 3 would help focus the efforts as well, and perhaps dumping the conceptual baggage would help attract new users and developers. But this discussions is fraught with danger. :) To be honest, zope3 (as it is today) is a nice platform for me and for my company to build web applications (and, in general, the ZCA is a nice platform for building not-only-web applications), and it would be a shame to loose it. The ZCA is well in hand and I hope it's going to do better than ever, managed as part of the Zope Toolkit project. I hope we'll eventually gain improved documentation describing it too, right there on zope.org. To make explicit: I am not talking just about maintaining the ZMI, I'm talking about making zope3 a *real* user-friendly web framework, as (for example) grok is already right now. Very cool! So, what about the name? Open to a change? 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] People in the Zope 3 and ZMI teams
Hi there, Just so we don't lose track of who are interested in maintaining Zope 3 (and/or the ZMI). I've distilled the following list of people who are interested in helping maintain Zope 3. This might mean making sure existing apps work, maintaining or replacing the ZMI, and working on making sure installation works. We can work out these details over time. I've sorted it all more or less in the order of perceived commitment, based on my statements and wild guesses on my part, I might be completely wrong. If you want to help, please reply to this thread and indicate your support. I'd suggest if you want to help you talk to the people nearer to the top of the list. But what typically works better is for the people on this list to tell zope-dev what they're doing, and how others could help them with particular bits, on a regular basis. Yusei TAHARA Concerning the ZMI: For me, the ZMI is useful to managing local components, security settings, making views for ad hoc changes etc. I think it could be an optional package like grokui.admin. I'm interested in maintenance it. I'll note that Yusei is planning to start work on rearranging the ZMI into a smaller set of packages (by moving code into zmi.core) soon. Please help him if you're interested! Fabio Tranchitella -- If the question was who is interested in zope3, the application server, and willing to maintain it, I'd answer me. Concerning the ZMI: We use the ZMI to manage applications, where applications are instances of a content object stored in the ZODB. All in all, we manage applications in a similar way we manage plone sites in zope2.x. If this specific feature is going to be removed, I'm willing to support and maintain it. Uli Fouquet --- On a UI for installation of apps, possibly to be shared inside the Zope Toolkit: I'd be willing to help He adds: although I don't feel qualified enough to drive such a process. Stephan Richter --- I have no problem keeping the Zope 3 KGS releases alive. Concerning the ZMI: I have not used the ZMI since 2 years now and I am still considering myself writing Zope 3 apps. Concerning a documentation website for Zope 3: I am not interested about that. Albertas Agejevas - I'm very interested that existing applications that use the the zope.app server remain usable with future versions of Zope Toolkit libraries, or Zope 3 KGS if you will. He also adds: I'm not interested in documentation or maintaining the installation story on any platform, that is attracting new users Roger Ineichen -- I'm willing to help to find a way to move the old code parts to a newer and better concept. Roger also says he's interested in maintaining the ZMI in some form or find something new to migrate to. I will help to support such a Zope Toolkit management app which will allow to get rid of the zmi part. I'm not sure what he means with the old code He adds: Note, I don't use this code in my own projects and I don't propose to do that just for fun. But if someone proposes to do it, I'm willing to help. Baiju M --- I am interested to maintain the packages necessary to create a simple application out of the box. He adds: This is just an academic interest :) 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 )
