Hi, so, we've been running with the steering group for a few weeks now and I'm losing track of things, because we're letting the mailing list do the job of an issue tracking system. (And the one document in SVN.) We need to start using Launchpads tracking mechanisms for issues, filing bugs or blueprints much earlier and much more often than having threads just sit around in the zope-dev archive and *maybe* get picked up. As the steering group is supposed to follow up on opened issues and remind and work on them, having to track that kind of status in my mailbox is cruel to me and breaks the development process as that data is inaccessible to others. After all: that's what issue tracking systems are for, please, let's use ours. Please note that I don't want to move discussions off the mailing list: I want to be able to track issues that people want to get solved using an appropriate tracking system. I can't follow every single email on zope-dev and having to review large threads that were solved already isn't good use of anybodies time. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
Previously Christian Theune wrote:
We need to start using Launchpads tracking mechanisms for issues, filing bugs or blueprints much earlier and much more often than having threads just sit around in the zope-dev archive and *maybe* get picked up.
Can someone document how they work? I have never been able to understand what blueprints do from browsing the launchpad docs. Wichert. -- Wichert Akkerman <wichert@wiggy.net> It is simple to make things. http://www.wiggy.net/ It is hard to make things simple.
On Wed, 2009-03-25 at 09:01 +0100, Wichert Akkerman wrote:
Previously Christian Theune wrote:
We need to start using Launchpads tracking mechanisms for issues, filing bugs or blueprints much earlier and much more often than having threads just sit around in the zope-dev archive and *maybe* get picked up.
Can someone document how they work? I have never been able to understand what blueprints do from browsing the launchpad docs.
Instead of defects, they're supposed to let you track functional additions/changes to your project. Using them you can define the roadmap of your project. I'm not so much worried about us getting the distinction between bugs and blueprints right at the moment, so if you don't know what to file, feel free to just report a bug. Did you read this? https://help.launchpad.net/Blueprint Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
Hi Christian
Betreff: [Zope-dev] Please use launchpad bugtracking/blueprints more
Hi,
so, we've been running with the steering group for a few weeks now and I'm losing track of things, because we're letting the mailing list do the job of an issue tracking system. (And the one document in SVN.)
[...]
I can't follow every single email on zope-dev and having to review large threads that were solved already isn't good use of anybodies time.
Agreed, Can we use a marker in the header for "official" steering group mails like this one? Something like [Zope-dev][Announcment]. This let us easier pick up the important mails. Regards Roger Ineichen
Hey, I'm okay with using launchpad more, though I do think we shouldn't underestimate the power of a mailbox (I use gmane and a newsreader myself :) and a document with decisions recorded. People can simply bring up an issue again if it hasn't resolved itself, after all. I really don't want people to have to struggle through launchpad just to bring up an issue. Anyway, if the steering group wants launchpad to be used more, we'll have to get specific. Steering group members can do in two ways: * put issues in launchpad ourselves. * we suggest to people to put *particular* issues in launchpad during discussions here. This will work much better than general calls to use launchpad. :) One question is what launchpad project we should use. The current launchpad is for "Zope 3". The steering group isn't about Zope 3. It's about a whole bunch of libraries. Creating a separate launchpad project for each library in the framework seems like a bit of overkill at this stage, though it would please those people who come at us at the perspective from libraries the most. For now, I propose we create a launchpad project "zopeframework" and file bugs there. If a particular component such as zope.component gets a lot of traffic by itself, we'll open up a project for that as well (and issues can be assigned to two projects). Christian, can you create a zopeframework project in launchpad? Let it be nice and empty so there's no past we have to worry about. Mining through the current Zope 3 issues is a project all by itself. Regards, Martijn
Hi Martijn, On Wed, Mar 25, 2009 at 11:54 AM, Martijn Faassen <faassen@startifact.com> wrote:
One question is what launchpad project we should use.
The current launchpad is for "Zope 3". The steering group isn't about Zope 3. It's about a whole bunch of libraries. Creating a separate launchpad project for each library in the framework seems like a bit of overkill at this stage, though it would please those people who come at us at the perspective from libraries the most.
It smells like 'Zope Framework' (zope-framework) should be a Project Group then, and there should be a 'Zope Steering Group Project' (zope-steering-group-project) as part of it, and sibling of Zope 3 and any other libraries that are part of Zope Framework. For an example of what this looks like, look at: https://launchpad.net/chameleon-template-engine I can help setting up this structure, if needed. -- Sidnei da Silva Canonical Ltd. Landscape · Changing the way you manage your systems http://landscape.canonical.com
On Mar 25, 2009, at 11:52 AM, Sidnei da Silva wrote:
Hi Martijn,
On Wed, Mar 25, 2009 at 11:54 AM, Martijn Faassen <faassen@startifact.com> wrote:
One question is what launchpad project we should use.
The current launchpad is for "Zope 3". The steering group isn't about Zope 3. It's about a whole bunch of libraries. Creating a separate launchpad project for each library in the framework seems like a bit of overkill at this stage, though it would please those people who come at us at the perspective from libraries the most.
It smells like 'Zope Framework' (zope-framework) should be a Project Group then, and there should be a 'Zope Steering Group Project' (zope-steering-group-project) as part of it, and sibling of Zope 3 and any other libraries that are part of Zope Framework. For an example of what this looks like, look at:
https://launchpad.net/chameleon-template-engine
I can help setting up this structure, if needed.
I agree with Sidnei. Another example is the lazr projects (https://launchpad.net/lazr ). To be clear, making an umbrella project like this does need someone with admin rights in lp, so it will need "help" if it is desired. :-) Gary
On Wed, Mar 25, 2009 at 10:52 AM, Sidnei da Silva <sidnei.da.silva@canonical.com> wrote:
Hi Martijn,
On Wed, Mar 25, 2009 at 11:54 AM, Martijn Faassen <faassen@startifact.com> wrote:
One question is what launchpad project we should use.
The current launchpad is for "Zope 3". The steering group isn't about Zope 3. It's about a whole bunch of libraries. Creating a separate launchpad project for each library in the framework seems like a bit of overkill at this stage, though it would please those people who come at us at the perspective from libraries the most.
It smells like 'Zope Framework' (zope-framework) should be a Project Group then, and there should be a 'Zope Steering Group Project' (zope-steering-group-project) as part of it, and sibling of Zope 3 and any other libraries that are part of Zope Framework.
If possible, I think it is better to rename current 'zope3' as 'zope-framework', then create another 'zope3' project. So that we will get all bugs and blueprints as part of 'zope-framework'. Regards, Baiju M
On Wed, Mar 25, 2009 at 1:49 PM, Baiju M <mbaiju@zeomega.net> wrote:
If possible, I think it is better to rename current 'zope3' as 'zope-framework', then create another 'zope3' project. So that we will get all bugs and blueprints as part of 'zope-framework'.
If 'zope-framework' is a project group containing 'zope3', you would already get that. See: https://bugs.launchpad.net/chameleon-template-engine https://bugs.launchpad.net/lazr -- Sidnei da Silva Canonical Ltd. Landscape · Changing the way you manage your systems http://landscape.canonical.com
On Wed, Mar 25, 2009 at 12:16 PM, Sidnei da Silva <sidnei.da.silva@canonical.com> wrote:
On Wed, Mar 25, 2009 at 1:49 PM, Baiju M <mbaiju@zeomega.net> wrote:
If possible, I think it is better to rename current 'zope3' as 'zope-framework', then create another 'zope3' project. So that we will get all bugs and blueprints as part of 'zope-framework'.
If 'zope-framework' is a project group containing 'zope3', you would already get that. See:
https://bugs.launchpad.net/chameleon-template-engine https://bugs.launchpad.net/lazr
But making 'zope3' as a part of 'zope-framework' is not not good idea. Regards, Baiju M
Hey, Baiju M wrote: [snip]
But making 'zope3' as a part of 'zope-framework' is not not good idea.
Agreed. It's more likely the other way around, but I'm not going to suggest any alterations to the Zope 3 project, as I'm not involved in steering that. :) Regards, Martijn
Sidnei da Silva wrote:
On Wed, Mar 25, 2009 at 1:49 PM, Baiju M <mbaiju@zeomega.net> wrote:
If possible, I think it is better to rename current 'zope3' as 'zope-framework', then create another 'zope3' project. So that we will get all bugs and blueprints as part of 'zope-framework'.
If 'zope-framework' is a project group containing 'zope3', you would already get that. See:
The Zope Framework does not contain Zope 3. Zope 3, Zope 2 and Grok (will) use the Zope Framework. Other projects only use sub-projects of the Zope Framework. Regards, Martijn
Hey, Baiju M wrote: [snip]
If possible, I think it is better to rename current 'zope3' as 'zope-framework', then create another 'zope3' project. So that we will get all bugs and blueprints as part of 'zope-framework'.
I don't think that's correct at all, as Zope 3 isn't the Zope Framework. Also I'd like to start with a clean slate instead of an intimidating pile of stuff. We can always go through the Zope 3 bugs one by one and assign them to the Zope Framework too. Regards, Martijn
Sidnei da Silva wrote:
Hi Martijn,
On Wed, Mar 25, 2009 at 11:54 AM, Martijn Faassen <faassen@startifact.com> wrote:
One question is what launchpad project we should use.
The current launchpad is for "Zope 3". The steering group isn't about Zope 3. It's about a whole bunch of libraries. Creating a separate launchpad project for each library in the framework seems like a bit of overkill at this stage, though it would please those people who come at us at the perspective from libraries the most.
It smells like 'Zope Framework' (zope-framework) should be a Project Group then, and there should be a 'Zope Steering Group Project' (zope-steering-group-project) as part of it, and sibling of Zope 3 and any other libraries that are part of Zope Framework. For an example of what this looks like, look at:
Why would the steering group be a project as part of the Zope Framework? The steering group isn't a project? I'm all for setting something up, but I'm still not clear on what you'd set up. A Zope Framework project group with what inside? Regards, Martijn
On Wed, 2009-03-25 at 19:21 +0100, Martijn Faassen wrote:
Why would the steering group be a project as part of the Zope Framework? The steering group isn't a project?
I'm all for setting something up, but I'm still not clear on what you'd set up. A Zope Framework project group with what inside?
The Steering Committee can be a Team on Launchpad with or without associated source code. I do this with the oship-dev team and it works well. HTH, Tim -- Timothy Cook, MSc Health Informatics Research & Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ************************************************************** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* **************************************************************
On Mar 25, 2009, at 2:21 PM, Martijn Faassen wrote:
Sidnei da Silva wrote:
Hi Martijn,
On Wed, Mar 25, 2009 at 11:54 AM, Martijn Faassen <faassen@startifact.com> wrote:
One question is what launchpad project we should use.
The current launchpad is for "Zope 3". The steering group isn't about Zope 3. It's about a whole bunch of libraries. Creating a separate launchpad project for each library in the framework seems like a bit of overkill at this stage, though it would please those people who come at us at the perspective from libraries the most.
It smells like 'Zope Framework' (zope-framework) should be a Project Group then, and there should be a 'Zope Steering Group Project' (zope-steering-group-project) as part of it, and sibling of Zope 3 and any other libraries that are part of Zope Framework. For an example of what this looks like, look at:
Why would the steering group be a project as part of the Zope Framework? The steering group isn't a project?
I'm all for setting something up, but I'm still not clear on what you'd set up. A Zope Framework project group with what inside?
My take would be the following. It's probably contentious. - The current zope3 project is regarded as a project for the aggregation of the pieces into the old tgz and the old mgmt UI. This should be clarified on the project page. - There is a new Zope Framework (I would prefer Zope Libraries myself, but let's not start that again ;-) ) umbrella project, controlled by a new Zope Framework team. - There are multiple zope.* (and z3c.* and whatever) library projects. They are part of the umbrella project (if so desired by the pertinent parties). - The current zope3 project should be considered part of the Zope Framework *at least for now* because it has legacy information. If someone reassigns the bugs and blueprints and so on to the pertinent library projects (or to the Zope Framework), "zope3" could no longer be part of the Zope Framework umbrella project, if desired. That's work, though, so I'd be inclined to see if it happens and meanwhile be happy to take the zope3 project in as legacy. Gary
Good analysis Gary, Though I would tend to see Zope3 as the umbrella and the various projects (components) under it. Is there REALLY too much bad press vs. good press about Zope3? I don't think so. I think inventing a new name ala, Zope Umbrella is a bad thing. Presenting Zope3 as the Zope Component Architecture is not a bad thing. But not consolidating on a specific brand *is* a bad thing. I believe that from an outsiders point of view; keeping the Zope3 moniker ties it to the legacy of Zope.org and Zope Corp. These are not bad things. Explaining that it is now a component architecture is a good thing. In my project, this received a very positive response from Python developers. They liked the ideas of Zope but hated the monolithic structure of Zope2.x I am not a Zope developer, have never contributed a single line of code. I have complained a lot, mostly because I misunderstood Zope. but I can tell you that as a user it is easy to see the power and functionality. Even if I do not yet know how to fully exploit it. Moving away from the name is bad for the FOSS product and bad for the company that started it all. My 2.5 cents, Tim -- Timothy Cook, MSc Health Informatics Research & Development Services LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook Skype ID == timothy.cook ************************************************************** *You may get my Public GPG key from popular keyservers or * *from this link http://timothywayne.cook.googlepages.com/home* **************************************************************
On Wed, 2009-03-25 at 15:54 +0100, Martijn Faassen wrote:
Hey,
I'm okay with using launchpad more, though I do think we shouldn't underestimate the power of a mailbox (I use gmane and a newsreader myself :) and a document with decisions recorded. People can simply bring up an issue again if it hasn't resolved itself, after all. I really don't want people to have to struggle through launchpad just to bring up an issue.
Anyway, if the steering group wants launchpad to be used more, we'll have to get specific.
Steering group members can do in two ways:
* put issues in launchpad ourselves.
* we suggest to people to put *particular* issues in launchpad during discussions here.
This will work much better than general calls to use launchpad. :)
I'm happy to ask people to put stuff into launchpad. However, I think that if a topic goes onto the washing list of the steering group, it should definitely go into launchpad. The document we maintain in SVN already asks whether it should better live in LP and I think it should. Yeesh. I so wish I could be at PyCon to discuss some of that face to face. Christian -- Christian Theune · ct@gocept.com gocept gmbh & co. kg · forsterstraße 29 · 06112 halle (saale) · germany http://gocept.com · tel +49 345 1229889 7 · fax +49 345 1229889 1 Zope and Plone consulting and development
participants (8)
-
Baiju M -
Christian Theune -
Gary Poster -
Martijn Faassen -
Roger Ineichen -
Sidnei da Silva -
Tim Cook -
Wichert Akkerman