Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
Carlos de la Guardia wrote: On 9/29/06, Jim Fulton [EMAIL PROTECTED] wrote: Thanks for the input. I wonder if anyone wants to volunteer to spearhead a track prototype for zope.org? One of the things I like about Launchpad is that I don't have to do any work. If someone is willing to step forward and commit to a Trac implementation, I'm happy to try it out. I'd like to see a short-term commitment to work out how we'd use it. If we liked it, I wouldn't want to switch to it without a long-term commitment to maintain it. I realize that there are many things going on on the zope dev world right now and this is not a key issue, but I want to reiterate that I am willing to help with this if you decide to implement it. That's good to hear. I'll remember you. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZF] Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
On 10/2/06, Marius Gedminas [EMAIL PROTECTED] wrote: I've found Trac's anti-spam measures somewhat lacking. Having to learn sqlite's command line interface to remove anonymous spam comments from the bug tracker wasn't fun. Having to clean up spammed wiki page versions one at a time (10 pages * 20 spam updates * 2 form submits per version) wasn't fun either. Trac's plugin support (components) covers this area well, and will improve even more in version 0.10. -- Martijn Pieters ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
Jim Fulton wrote: Thanks for the input. I wonder if anyone wants to volunteer to spearhead a track prototype for zope.org? One of the things I like about Launchpad is that I don't have to do any work. If someone is willing to step forward and commit to a Trac implementation, I'm happy to try it out. I'd like to see a short-term commitment to work out how we'd use it. If we liked it, I wouldn't want to switch to it without a long-term commitment to maintain it. If anyone volunteers to do the trac prototype work itself, I can help them making trac.zope.org and such work. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
Carlos de la Guardia wrote: On 9/29/06, Jim Fulton [EMAIL PROTECTED] wrote: Thanks for the input. I wonder if anyone wants to volunteer to spearhead a track prototype for zope.org? One of the things I like about Launchpad is that I don't have to do any work. If someone is willing to step forward and commit to a Trac implementation, I'm happy to try it out. I'd like to see a short-term commitment to work out how we'd use it. If we liked it, I wouldn't want to switch to it without a long-term commitment to maintain it. Ok, I've setup a prototype at http://trac.opentrails.biz/zope Oh, cool, thanks! [snip] I will be happy to help with this, since I am looking for opportunities to help zope.org provide a better user experience, and I think this would really help. Great! If we decide to go with this, then I volunteer to help looking for a host to host it on, and making possible trac.zope.org. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZF] Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
Sidnei da Silva wrote: On Sun, Oct 01, 2006 at 09:38:21AM -0400, Jim Fulton wrote: | | Here are some quick Trac questions. My impression is that track projects | need to be set up as separate applications and that separate projects | can't be set up through the web. Is this right? All of that is true AFAICT. | Does trac have any notion | of sub-projects that would allow smallter efforts (e.g. zope.interface) | to have their own collectors without creating separate trac installations? Not that I know of. You also can't move issues between trac installations. Hm, I saw a trac site before that seemed to have subprojects. I wonder how they did it. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZF] Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
Martijn Faassen wrote: Sidnei da Silva wrote: On Sun, Oct 01, 2006 at 09:38:21AM -0400, Jim Fulton wrote: | | Here are some quick Trac questions. My impression is that track projects | need to be set up as separate applications and that separate projects | can't be set up through the web. Is this right? All of that is true AFAICT. | Does trac have any notion | of sub-projects that would allow smallter efforts (e.g. zope.interface) | to have their own collectors without creating separate trac installations? Not that I know of. You also can't move issues between trac installations. Hm, I saw a trac site before that seemed to have subprojects. I wonder how they did it. okay, a quick scan of docs shows that: * a single trac install can work for multiple subprojects (Documentation says: Only one installation is required, then for each project create an Environment (using trac-admin fooproj initenv). They will be separate projects, all handled by the same installation of Trac.) * but sharing information between subprojects is not yet supported. (Documentation says: Note: Right now there is no support for sharing information between projects.) They have plans to make this work better post Trac 1.0: http://trac.edgewall.org/wiki/TracMultipleProjects Their trac roadmap (indicated in Trac :) makes this look a while off yet, though.. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZF] Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
Marius Gedminas wrote: On Fri, Sep 29, 2006 at 09:52:34AM -0400, Jim Fulton wrote: Thanks for the input. I wonder if anyone wants to volunteer to spearhead a track prototype for zope.org? One of the things I like about Launchpad is that I don't have to do any work. If someone is willing to step forward and commit to a Trac implementation, I'm happy to try it out. I'd like to see a short-term commitment to work out how we'd use it. If we liked it, I wouldn't want to switch to it without a long-term commitment to maintain it. I've found Trac's anti-spam measures somewhat lacking. That's indeed a point to worry about. I can confirm having run into a spammed-to-death Trac in the path. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZF] Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
Previously Martijn Faassen wrote: That's indeed a point to worry about. I can confirm having run into a spammed-to-death Trac in the path. Non-existant was a better description. This is not really a trac-specific problem though: any system which allows anonymous posting of content will suffer from spam at some point. For dev.plone.org we disabled anonymous ticket creation and modification. Since creating a plone.org is trivial that has not been a problem. Also, trac 0.10 has just been released which has some spam filtering hooks that might be useful. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
On 10/1/06, Jim Fulton [EMAIL PROTECTED] wrote: Does trac have any notionof sub-projects that would allow smallter efforts (e.g. zope.interface)to have their own collectors without creating separate trac installations?It depends on what you want. In trac you can define 'components', which in some ways can be thought of as sub-projects. For example, you can easily create a report where only the issues for a given component are shown. In that way we could have separate reports for each component, like zope.interface, and also a general view where everything can be shown. Also, since you can link to anything from the wiki, it would be possible to create a wiki page for each sub-project, with direct links to its own issues. Carlos de la Guardia ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
Carlos de la Guardia wrote: On 9/29/06, *Jim Fulton* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Thanks for the input. I wonder if anyone wants to volunteer to spearhead a track prototype for zope.org http://zope.org? One of the things I like about Launchpad is that I don't have to do any work. If someone is willing to step forward and commit to a Trac implementation, I'm happy to try it out. I'd like to see a short-term commitment to work out how we'd use it. If we liked it, I wouldn't want to switch to it without a long-term commitment to maintain it. Ok, I've setup a prototype at http://trac.opentrails.biz/zope I put some text from the zope 3 wiki (without the links), copied the roadmap from that same source, uploaded the zope3 trunk to the svn repository This worries me a bit. Integration with svn seems to be a major selling point of track, but you haven't done that. I'd like to see a prototype that is actually integrated with our subversion repository. What would be necesary to make that happen? Do you need actual access to the local subversion files? Or can you access them remotely? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
Carlos de la Guardia wrote: On 9/29/06, *Jim Fulton* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Thanks for the input. I wonder if anyone wants to volunteer to spearhead a track prototype for zope.org http://zope.org? One of the things I like about Launchpad is that I don't have to do any work. If someone is willing to step forward and commit to a Trac implementation, I'm happy to try it out. I'd like to see a short-term commitment to work out how we'd use it. If we liked it, I wouldn't want to switch to it without a long-term commitment to maintain it. Ok, I've setup a prototype at http://trac.opentrails.biz/zope Thanks for setting this up. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZF] Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
| This worries me a bit. Integration with svn seems to be a major | selling point of track, but you haven't done that. I'd like to see | a prototype that is actually integrated with our subversion repository. | What would be necesary to make that happen? Do you need actual access | to the local subversion files? Or can you access them remotely? Last I checked trac needed direct access to the local repository. It *might* be able to do remote access these days, but I wouldn't count on that. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
Here are some quick Trac questions. My impression is that track projects need to be set up as separate applications and that separate projects can't be set up through the web. Is this right? Does trac have any notion of sub-projects that would allow smallter efforts (e.g. zope.interface) to have their own collectors without creating separate trac installations? Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZF] Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
Previously Sidnei da Silva wrote: | This worries me a bit. Integration with svn seems to be a major | selling point of track, but you haven't done that. I'd like to see | a prototype that is actually integrated with our subversion repository. | What would be necesary to make that happen? Do you need actual access | to the local subversion files? Or can you access them remotely? Last I checked trac needed direct access to the local repository. It *might* be able to do remote access these days, but I wouldn't count on that. It depends on what you want: - in order to use the repository browser from trac trac needs filesystem access to the repository - for the commit/issue linking magic (commits automatically updating/closing tickets) pretty much any communication channel between a post-commit hook in the repository and trac can suffice. Wichert. -- Wichert Akkerman [EMAIL PROTECTED]It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [ZF] Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
On Sun, Oct 01, 2006 at 09:38:21AM -0400, Jim Fulton wrote: | | Here are some quick Trac questions. My impression is that track projects | need to be set up as separate applications and that separate projects | can't be set up through the web. Is this right? All of that is true AFAICT. | Does trac have any notion | of sub-projects that would allow smallter efforts (e.g. zope.interface) | to have their own collectors without creating separate trac installations? Not that I know of. You also can't move issues between trac installations. -- Sidnei da Silva Enfold Systemshttp://enfoldsystems.com Fax +1 832 201 8856 Office +1 713 942 2377 Ext 214 ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
On 9/29/06, Jim Fulton [EMAIL PROTECTED] wrote: Thanks for the input.I wonder if anyone wants to volunteer tospearhead a track prototype for zope.org?One of the things I likeabout Launchpad is that I don't have to do any work.If someone is willing to step forward and commit to a Trac implementation, I'm happyto try it out.I'd like to see a short-term commitment to work out howwe'd use it.If we liked it, I wouldn't want to switch to it without a long-term commitment to maintain it.Ok, I've setup a prototype at http://trac.opentrails.biz/zopeI put some text from the zope 3 wiki (without the links), copied the roadmap from that same source, uploaded the zope3 trunk to the svn repository and created a couple of real bugs I extracted from the collector (trust me, after searching for the issues there, I know you will never want to go back). Please play around with it a little. Jeff has mentioned some of the good things trac offers, so I will not bore you. There are a lot of details that would have to be defined for this to really work, but you can get a pretty good idea of how it would go. I will be happy to help with this, since I am looking for opportunities to help zope.org provide a better user experience, and I think this would really help.Carlos de la Guardia ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
Thanks for the input. I wonder if anyone wants to volunteer to spearhead a track prototype for zope.org? One of the things I like about Launchpad is that I don't have to do any work. If someone is willing to step forward and commit to a Trac implementation, I'm happy to try it out. I'd like to see a short-term commitment to work out how we'd use it. If we liked it, I wouldn't want to switch to it without a long-term commitment to maintain it. Jim Jeff Shell wrote: On 9/25/06, Martijn Faassen [EMAIL PROTECTED] wrote: Baiju M wrote: On 9/22/06, Jim Fulton [EMAIL PROTECTED] wrote: snip Finally, I'm experimenting with using launchpad for bugs: https://launchpad.net/products/zc.buildout/+bugs and feature requests: https://features.launchpad.net/products/zc.buildout/ So far this is working OK. I haven't really stressed it. Launchpad makes this very easy to set up and I don't think they are allergic to having us create lots of projects. Let's move Zope3 issue collector to launchpad? (Once this discussion came to ZF list, I think there were more +1) Before we move any issue collectors to launchpad, we need a bit more experience with the launchpad issue tracker and its capabilities. I'm also wonder whether launchpad has good issue export facilities in case we want to move to another system. With Tres, I think we should also explore options like Trac. I personally think Trac has attractive features in the way it integrates the development process into things like an issue tracker. I love Trac. I've never installed it or used it to manage any projects on my own, but I find that I stay on top of open source projects more if they're using Trac. On a small aesthetics side, I find Launchpad's side bars incredibly distracting, and I don't like looking at the page because it feels like there are too many things vying for my attention and I have a hard time really reading the text in front of me. The content gets squished. And then I find myself looking at all of these links and buttons around the page trying to figure out what has the information I'm interested in. The sidebar on Zope.org bothers me in the same way when I try to read the Zope 3 wiki - but Zope.org feels nowhere near as noisy as Launchpad. I'm sure their tools are great, and the hosting service is a good feature. But my temper is short these days. My attention span is not: if I can find and read a page that's not full of distractions, I'll stay and read it and learn. But when there are boxes on all sides chock full of colors and links, reading is much harder. A nice simple example is this nice page in SQLAlchemy's Trac wiki (a page I read over and over as I migrated code to 0.2): http://www.sqlalchemy.org/trac/wiki/02Migration It's very nice. I can read that page, print it, save it to a local permanent archive, etc. There is something about Trac's feature set, implementation, and in how it's installed (in most cases) that make it very nice for a cantankerous, stressed out, often overburdened worker like me to stay on top of and even want to get involved (even on some small level) with a project - and that I can do this in small amounts of time. The Zope 3 wiki, collector, and even subversion browser, all feel like they require more of a full time job to stay involved. And if not a full time job, then at least some seriously set-aside time. It's very hard to get answers to what's gone on recently?, what are all of the bugs, and let me see and sort them quickly on some different criteria, and let me then see how they were fixed, and then let me quickly find some minor annoyance issues that I might be able to fix. With a Trac setup like SQLAlchemy is using, I feel like I can do this at home in the morning during my browse-and-drink-coffee-time. With the current Zope tools (and my limited experience with Launchpad's tools), it does not feel casual at all to keep up with everything going on. And that makes it hard to stay enthusiastic and energized about a project. Compare: - http://dev.zope.org/Zope3/RoadMap - http://www.sqlalchemy.org/trac/milestone/0.3.0?by=severity I wish there had been something like that Trac milestone page for Zope 3.3. Of course, it doesn't show everything going on. But it would have made it much easier to find out what may have been slowing the release down so much, and then easier to want to get involved and make it happen sooner. The lack of distracting side columns, the integration of the Wiki, the Roadmaps/Milestones, the Subversion integration (being able to refer to tickets, wiki pages, etc in commit log messages and having the links generated in the web. [ticket:309], etc), the custom issue tracker reports: it's a very nice system to use, even casually. The Timeline is like a Wiki's Recent Changes on crack. Except the crack is filled with helpful vitamins: recent wiki changes, recent checkins, recent issue tracker activity (bugs submitted, opened, closed). It just feels so much
Re: [ZF] Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
On a small aesthetics side, I find Launchpad's side bars incredibly distracting, and I don't like looking at the page because it feels like there are too many things vying for my attention and I have a hard time really reading the text in front of me. The content gets squished. And then I find myself looking at all of these links and buttons around the page trying to figure out what has the information I'm interested in. The sidebar on Zope.org bothers me in the same way when I try to read the Zope 3 wiki - but Zope.org feels nowhere near as noisy as Launchpad. I'm sure their tools are great, and the hosting service is a good feature. I understand what you're saying about the Launchpad UI, and I agree with it. There's a significant re-design of the Launchpad UI underway right now that ought to address many of these issues. It won't be on the live site for a couple of months, though. -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] the maintenance of change logs
Finally, I'm experimenting with using launchpad for bugs: https://launchpad.net/products/zc.buildout/+bugs and feature requests: https://features.launchpad.net/products/zc.buildout/ So far this is working OK. I haven't really stressed it. Launchpad makes this very easy to set up and I don't think they are allergic to having us create lots of projects. We're fine with you creating lots of projects, and actually Launchpad is meant to support working that way. The way the bug tracker is set up, it is straightforward to transfer responsibility for fixing a bug from one project to another, or to indicate that there is a shared responsibility. For example, I might file a bug on Zope, but really it is a bug in zc.buildout. Rather than filing a new bug elsewhere, whoever triages the bug can reassign it to zc.buildout without losing comments or history or subscribers. -- Steve Alexander ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re: [ZF] Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
On 9/29/06, Steve Alexander [EMAIL PROTECTED] wrote: On a small aesthetics side, I find Launchpad's side bars incredibly distracting, and I don't like looking at the page because it feels like there are too many things vying for my attention and I have a hard time really reading the text in front of me. The content gets squished. And then I find myself looking at all of these links and buttons around the page trying to figure out what has the information I'm interested in. The sidebar on Zope.org bothers me in the same way when I try to read the Zope 3 wiki - but Zope.org feels nowhere near as noisy as Launchpad. I'm sure their tools are great, and the hosting service is a good feature. I understand what you're saying about the Launchpad UI, and I agree with it. There's a significant re-design of the Launchpad UI underway right now that ought to address many of these issues. It won't be on the live site for a couple of months, though. I see that you have Matthew P Thomas involved. I know he's had some good writings in the past about usability and consistency. And after looking at `help.launchpad.net` really quickly, I now realize the big seller for Launchpad: bug tracking across multiple projects. With all of the little Zope things out there (zc.catalog, zc.buildout, etc), it would be good to be able to share such data between them. Actually, this is an issue that my very small company runs into frequently - needing to focus on specific projects while also keeping an eye on the underlying tools and frameworks. So many other systems seem suited for just-one-project-at-a-time, and it's frustrating to try to keep track of issues four layers down from customer-specific code. So: I really like Launchpad's goals and intentions. But its a usability nightmare to me as a casual visitor. And I've found that for me, personally, it's hard to stay involved with or on top of a project in that situation, especially when I'm stressed out (like I have been the past few days). I look forward to seeing the re-design. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
On 9/25/06, Martijn Faassen [EMAIL PROTECTED] wrote: Baiju M wrote: On 9/22/06, Jim Fulton [EMAIL PROTECTED] wrote: snip Finally, I'm experimenting with using launchpad for bugs: https://launchpad.net/products/zc.buildout/+bugs and feature requests: https://features.launchpad.net/products/zc.buildout/ So far this is working OK. I haven't really stressed it. Launchpad makes this very easy to set up and I don't think they are allergic to having us create lots of projects. Let's move Zope3 issue collector to launchpad? (Once this discussion came to ZF list, I think there were more +1) Before we move any issue collectors to launchpad, we need a bit more experience with the launchpad issue tracker and its capabilities. I'm also wonder whether launchpad has good issue export facilities in case we want to move to another system. With Tres, I think we should also explore options like Trac. I personally think Trac has attractive features in the way it integrates the development process into things like an issue tracker. I love Trac. I've never installed it or used it to manage any projects on my own, but I find that I stay on top of open source projects more if they're using Trac. On a small aesthetics side, I find Launchpad's side bars incredibly distracting, and I don't like looking at the page because it feels like there are too many things vying for my attention and I have a hard time really reading the text in front of me. The content gets squished. And then I find myself looking at all of these links and buttons around the page trying to figure out what has the information I'm interested in. The sidebar on Zope.org bothers me in the same way when I try to read the Zope 3 wiki - but Zope.org feels nowhere near as noisy as Launchpad. I'm sure their tools are great, and the hosting service is a good feature. But my temper is short these days. My attention span is not: if I can find and read a page that's not full of distractions, I'll stay and read it and learn. But when there are boxes on all sides chock full of colors and links, reading is much harder. A nice simple example is this nice page in SQLAlchemy's Trac wiki (a page I read over and over as I migrated code to 0.2): http://www.sqlalchemy.org/trac/wiki/02Migration It's very nice. I can read that page, print it, save it to a local permanent archive, etc. There is something about Trac's feature set, implementation, and in how it's installed (in most cases) that make it very nice for a cantankerous, stressed out, often overburdened worker like me to stay on top of and even want to get involved (even on some small level) with a project - and that I can do this in small amounts of time. The Zope 3 wiki, collector, and even subversion browser, all feel like they require more of a full time job to stay involved. And if not a full time job, then at least some seriously set-aside time. It's very hard to get answers to what's gone on recently?, what are all of the bugs, and let me see and sort them quickly on some different criteria, and let me then see how they were fixed, and then let me quickly find some minor annoyance issues that I might be able to fix. With a Trac setup like SQLAlchemy is using, I feel like I can do this at home in the morning during my browse-and-drink-coffee-time. With the current Zope tools (and my limited experience with Launchpad's tools), it does not feel casual at all to keep up with everything going on. And that makes it hard to stay enthusiastic and energized about a project. Compare: - http://dev.zope.org/Zope3/RoadMap - http://www.sqlalchemy.org/trac/milestone/0.3.0?by=severity I wish there had been something like that Trac milestone page for Zope 3.3. Of course, it doesn't show everything going on. But it would have made it much easier to find out what may have been slowing the release down so much, and then easier to want to get involved and make it happen sooner. The lack of distracting side columns, the integration of the Wiki, the Roadmaps/Milestones, the Subversion integration (being able to refer to tickets, wiki pages, etc in commit log messages and having the links generated in the web. [ticket:309], etc), the custom issue tracker reports: it's a very nice system to use, even casually. The Timeline is like a Wiki's Recent Changes on crack. Except the crack is filled with helpful vitamins: recent wiki changes, recent checkins, recent issue tracker activity (bugs submitted, opened, closed). It just feels so much more alive. -- Jeff Shell ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
Baiju M wrote: On 9/22/06, Jim Fulton [EMAIL PROTECTED] wrote: snip Finally, I'm experimenting with using launchpad for bugs: https://launchpad.net/products/zc.buildout/+bugs and feature requests: https://features.launchpad.net/products/zc.buildout/ So far this is working OK. I haven't really stressed it. Launchpad makes this very easy to set up and I don't think they are allergic to having us create lots of projects. Let's move Zope3 issue collector to launchpad? (Once this discussion came to ZF list, I think there were more +1) What worries me with all these development process ideas and decisions is that we don't seem to have a document where all the decisions are marked. (I'm not saying the launchpad idea is a decision, I'm just worrying that we've been discussing a lot of them recently and we don't seem to have a document somewhere in SVN or on a URL that describes what we *did* decide) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] the maintenance of change logs
Jim Fulton wrote: On Sep 22, 2006, at 1:31 PM, Stephan Richter wrote: On Friday 22 September 2006 12:52, Martijn Faassen wrote: I hope we can move to a pattern where projects gain a homepage somewhere on zope.org, including doctests and some other information, and the cheeseshop is used for everything else (pointing to the homepage on zope.org with the 'url' field in setup.py). Yep, me too. Sigh, I have to get to work again on the software site. It could be argued that, given existing tools like pypi and launchpad, that we should focus on other things. I think that we should look into leveraging pypi as much as possible, but that from a perspective of a project having a face and marketing it to developers, it's important that at least the larger projects have a homepage on zope.org. The larger projects also will need a documentation presence larger than what can be comfortably stuffed into PyPi. Tutorials, etc. I also consider it very important that we have at least a *list* on zope.org of zope 3 projects. :) Stephan also worked hard on giving an idea of quality/maturity indication for Zope 3 projects. While I think we should go carefully with this, and definitely introduce such quality metrics gradually, I think that presenting *some* of this information to the public could be valuable over time. This cannot be presented on PyPi, so this is again an argument for a presence on zope.org. That said, please continue using PyPi and I also don't mind using launchpad more; I definitely don't want to block anyone. I just consider it important to consider project identity. Having an identity can go a long way in creating a *community* around the software. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] the maintenance of change logs
Jim Fulton wrote: On Sep 22, 2006, at 12:52 PM, Martijn Faassen wrote: While I'm happy with the way this works now as it's agile, I am also hoping that eventually we can move away from the cheeseshop as the prime documentation site of a project; it's not ideally suited for that. It's not bad either, IMO. Anyway, in the mean time, I suggest that if we try to standardize on anything, I suggest we follow a mechanism that works *now*. I agree, with my arguments for a project presence on zope.org I am not intending to block this. Please continue what you are doing. I'll get around to project presence on zope.org at some stage, and we can reuse whatever's in pypi to get a running start. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] the maintenance of change logs
Martijn Faassen wrote: I also consider it very important that we have at least a *list* on zope.org of zope 3 projects. :) I'd suggest something that links back to PyPi, like the TurboGears GogBin: http://www.turbogears.org/cogbin/ -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] the maintenance of change logs
Benji York wrote: Martijn Faassen wrote: I also consider it very important that we have at least a *list* on zope.org of zope 3 projects. :) I'd suggest something that links back to PyPi, like the TurboGears GogBin: http://www.turbogears.org/cogbin/ Yes, that may be enough for many of the projects. As soon as the documentation and/or community gets more complicated I suspect we need something on zope.org proper, though. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
Baiju M wrote: On 9/22/06, Jim Fulton [EMAIL PROTECTED] wrote: snip Finally, I'm experimenting with using launchpad for bugs: https://launchpad.net/products/zc.buildout/+bugs and feature requests: https://features.launchpad.net/products/zc.buildout/ So far this is working OK. I haven't really stressed it. Launchpad makes this very easy to set up and I don't think they are allergic to having us create lots of projects. Let's move Zope3 issue collector to launchpad? (Once this discussion came to ZF list, I think there were more +1) Before we move any issue collectors to launchpad, we need a bit more experience with the launchpad issue tracker and its capabilities. I'm also wonder whether launchpad has good issue export facilities in case we want to move to another system. With Tres, I think we should also explore options like Trac. I personally think Trac has attractive features in the way it integrates the development process into things like an issue tracker. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] the maintenance of change logs
Martijn Faassen wrote: Benji York wrote: Martijn Faassen wrote: I also consider it very important that we have at least a *list* on zope.org of zope 3 projects. :) I'd suggest something that links back to PyPi, like the TurboGears GogBin: http://www.turbogears.org/cogbin/ Yes, that may be enough for many of the projects. As soon as the documentation and/or community gets more complicated I suspect we need something on zope.org proper, though. Right. I was only suggesting that we use PyPi for what it is and create something that adds on what we need. It should probably not be as simple as the CogBin (except in the beginning). -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] the maintenance of change logs
Benji York wrote: Martijn Faassen wrote: Benji York wrote: Martijn Faassen wrote: I also consider it very important that we have at least a *list* on zope.org of zope 3 projects. :) I'd suggest something that links back to PyPi, like the TurboGears GogBin: http://www.turbogears.org/cogbin/ Yes, that may be enough for many of the projects. As soon as the documentation and/or community gets more complicated I suspect we need something on zope.org proper, though. Right. I was only suggesting that we use PyPi for what it is and create something that adds on what we need. It should probably not be as simple as the CogBin (except in the beginning). Yes, we're violently agreeing, I think. :) Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
On 23.09.2006, at 06:46, Baiju M wrote: On 9/22/06, Jim Fulton [EMAIL PROTECTED] wrote: snip Finally, I'm experimenting with using launchpad for bugs: https://launchpad.net/products/zc.buildout/+bugs and feature requests: https://features.launchpad.net/products/zc.buildout/ So far this is working OK. I haven't really stressed it. Launchpad makes this very easy to set up and I don't think they are allergic to having us create lots of projects. Let's move Zope3 issue collector to launchpad? (Once this discussion came to ZF list, I think there were more +1) We can create seperate products in launchpad (It can be grouped) for each project. +1 Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/zope- mailinglist%40mopa.at ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] the maintenance of change logs
Jim Fulton wrote: On Sep 22, 2006, at 11:47 AM, Martijn Faassen wrote: I am about to do a new egg release of zc.catalog and will be putting out other eggs as well (to the cheeseshop as we now have our own category there). I notice in the SVN that there have been quite a few changes to zc.catalog. We do not have any CHANGES.txt or such, so it's very hard for me to determine what in fact changed without digging through SVN commit messages and such. So, I propose we start maintaining CHANGES.txt in packages, and mark changes there when we make them. I'd rather see this in projects, not packages. So this would be in the root of an SVN project alongside of setup.py. Maybe this is what you meant. Yes, sorry for being unclear, that is what I meant. [snip] See what I've been doing for zc.buildout: http://svn.zope.org/zc.buildout/trunk/CHANGES.txt?view=auto I took a look at it after I wrote this post. Some things to note: I knit all of the .txt files, including documentation-oriented doctest files together in the distutils long description. This causes the pypi page to be pretty informative: http://www.python.org/pypi/zc.buildout I looked into doing this for zc.catalog as well, but in the end decided not to. zc.catalog contains quite a few doctests and the knitting would be quite involved, so I deferred the work. While I'm happy with the way this works now as it's agile, I am also hoping that eventually we can move away from the cheeseshop as the prime documentation site of a project; it's not ideally suited for that. I hope we can move to a pattern where projects gain a homepage somewhere on zope.org, including doctests and some other information, and the cheeseshop is used for everything else (pointing to the homepage on zope.org with the 'url' field in setup.py). [snip] I find putting dates on releases to be a bother. If it's a bother for me, it's probably a bother for others. Is it really worth it? I really appreciate seeing release dates myself. I already found myself wondering the other day whether a release of zc.buildout was new or whether I'd seen it again. Release dates help there. It is also helpful to track a project's release history later. If the cheeseshop had release dates for files somewhere visible then I'd be okay with leaving them off. I've done a bad job of tagging releases, I need to get better about that. Yes, as not tagging removes one more way to determine the release date. :) Finally, I'm experimenting with using launchpad for bugs: https://launchpad.net/products/zc.buildout/+bugs and feature requests: https://features.launchpad.net/products/zc.buildout/ So far this is working OK. I haven't really stressed it. Launchpad makes this very easy to set up and I don't think they are allergic to having us create lots of projects. I intend to take a look at this later. Anyway, we need to start writing this stuff down in an easily found place. Like zope.org... Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] the maintenance of change logs
Gary Poster wrote: [snip] Also, for these, we're taking the tack of We're not ashamed of calling it 1.0 rather than the 0.x Oh, when will I reach perfection approach. Good point. I'll be a bit more aggressive with 1.0 in the future. Regards, Martijn ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] the maintenance of change logs
On Friday 22 September 2006 12:52, Martijn Faassen wrote: I hope we can move to a pattern where projects gain a homepage somewhere on zope.org, including doctests and some other information, and the cheeseshop is used for everything else (pointing to the homepage on zope.org with the 'url' field in setup.py). Yep, me too. Sigh, I have to get to work again on the software site. Something that really disturbs me about the current setup info is that the meta data lives in a Python call and not in a text file that makes it very hard for other software to extract. Regards, Stephan -- Stephan Richter CBU Physics Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] the maintenance of change logs
On Sep 22, 2006, at 12:52 PM, Martijn Faassen wrote: Jim Fulton wrote: ... Some things to note: I knit all of the .txt files, including documentation-oriented doctest files together in the distutils long description. This causes the pypi page to be pretty informative: http://www.python.org/pypi/zc.buildout I looked into doing this for zc.catalog as well, but in the end decided not to. zc.catalog contains quite a few doctests and the knitting would be quite involved, so I deferred the work. I bet it has fewer doc files that zope.testing. http://www.python.org/ pypi/zope.testing, and the knitting wasn't that hard, http://svn.zope.org/zope.testing/trunk/setup.py?view=markup. While I'm happy with the way this works now as it's agile, I am also hoping that eventually we can move away from the cheeseshop as the prime documentation site of a project; it's not ideally suited for that. It's not bad either, IMO. Anyway, in the mean time, I suggest that if we try to standardize on anything, I suggest we follow a mechanism that works *now*. ... Anyway, we need to start writing this stuff down in an easily found place. Like zope.org... While I feel what I'm doing is still somewhat experimental, I'm happy to write it down somewhere, if someone will tell me where. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] the maintenance of change logs
On Sep 22, 2006, at 1:31 PM, Stephan Richter wrote: On Friday 22 September 2006 12:52, Martijn Faassen wrote: I hope we can move to a pattern where projects gain a homepage somewhere on zope.org, including doctests and some other information, and the cheeseshop is used for everything else (pointing to the homepage on zope.org with the 'url' field in setup.py). Yep, me too. Sigh, I have to get to work again on the software site. It could be argued that, given existing tools like pypi and launchpad, that we should focus on other things. Something that really disturbs me about the current setup info is that the meta data lives in a Python call and not in a text file that makes it very hard for other software to extract. Well, with eggs, the meta data ends up in files that can be extracted. You can always run setup to generate this information if you don't have an egg yet. Jim -- Jim Fulton mailto:[EMAIL PROTECTED]Python Powered! CTO (540) 361-1714 http://www.python.org Zope Corporationhttp://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Use launchpad ! (was Re: [Zope3-dev] the maintenance of change logs)
On 9/22/06, Jim Fulton [EMAIL PROTECTED] wrote: snip Finally, I'm experimenting with using launchpad for bugs: https://launchpad.net/products/zc.buildout/+bugs and feature requests: https://features.launchpad.net/products/zc.buildout/ So far this is working OK. I haven't really stressed it. Launchpad makes this very easy to set up and I don't think they are allergic to having us create lots of projects. Let's move Zope3 issue collector to launchpad? (Once this discussion came to ZF list, I think there were more +1) We can create seperate products in launchpad (It can be grouped) for each project. Regards, Baiju M ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
