Hi,
This is a question about our bug tracking system. In this system we can define components against which people can then file issues. This helps to categorize the bug reports and to automatically assign bugs to people (component owners). At the moment only a few components are defined, e.g. simfactory, the ET websites, GetComponents, Carpet or trac itself. In the extreme case we could have one trac component for each ET component, e.g. each thorn or other utility. However, I think that this would not be so useful. This list would be really long and some issues would still not fit into that.
I propose to group components within the Cactus framework mainly by arrangement, but not making that an absolute rule. We would assign maintainers to each of the arrangement. That would of course not mean that they would be (the only people) responsible to actually fix those problems, but merely taking care that the issues have proper owners and are not forgotten.
What are the opinions about this?
Frank
On 3 Dec 2010, at 22:08, Frank Loeffler wrote:
Hi,
This is a question about our bug tracking system. In this system we can define components against which people can then file issues. This helps to categorize the bug reports and to automatically assign bugs to people (component owners). At the moment only a few components are defined, e.g. simfactory, the ET websites, GetComponents, Carpet or trac itself. In the extreme case we could have one trac component for each ET component, e.g. each thorn or other utility. However, I think that this would not be so useful. This list would be really long and some issues would still not fit into that.
I propose to group components within the Cactus framework mainly by arrangement, but not making that an absolute rule. We would assign maintainers to each of the arrangement. That would of course not mean that they would be (the only people) responsible to actually fix those problems, but merely taking care that the issues have proper owners and are not forgotten.
What are the opinions about this?
Since we introduced the TRAC system, there have not been a large number of bug reports against thorns - most of the issues have been related to simfactory, the website, Cactus, Carpet, GetComponents etc. I propose adding one new component: "Einstein Toolkit Thorns", which would be used for any issue relating to an ET thorns.
On Fri, Dec 3, 2010 at 4:08 PM, Frank Loeffler knarf@cct.lsu.edu wrote:
Hi,
This is a question about our bug tracking system. In this system we can define components against which people can then file issues. This helps to categorize the bug reports and to automatically assign bugs to people (component owners). At the moment only a few components are defined, e.g. simfactory, the ET websites, GetComponents, Carpet or trac itself. In the extreme case we could have one trac component for each ET component, e.g. each thorn or other utility. However, I think that this would not be so useful. This list would be really long and some issues would still not fit into that.
I propose to group components within the Cactus framework mainly by arrangement, but not making that an absolute rule. We would assign maintainers to each of the arrangement. That would of course not mean that they would be (the only people) responsible to actually fix those problems, but merely taking care that the issues have proper owners and are not forgotten.
What are the opinions about this?
One reason for having components is so that people who are experts in one subject are not bothered by having to look at issues in other fields. As you mention, it also doesn't make sense to have more than five or ten components, because otherwise the distinctions would be so fine that people would misfile.
This may work:
Cactus (flesh and all Cactus* arrangements) Carpet (all Carpet* arrangements) Einstein Toolkit (all Einstein* arrangements) web sites (Cactus, Carpet, Einstein Toolkit, Trac, ...) utilities (SimFactory, GetComponents, ...)
-erik
Do we have to call them components? Given that we're touting Cactus as a component-based framework in which the components are the thorns it seems awkward to use component for a group of thorns.
Cheers, Steve
On 12/04/2010 12:16 AM, Erik Schnetter wrote:
One reason for having components is so that people who are experts in one subject are not bothered by having to look at issues in other fields. As you mention, it also doesn't make sense to have more than five or ten components, because otherwise the distinctions would be so fine that people would misfile.
This may work:
Cactus (flesh and all Cactus* arrangements) Carpet (all Carpet* arrangements) Einstein Toolkit (all Einstein* arrangements) web sites (Cactus, Carpet, Einstein Toolkit, Trac, ...) utilities (SimFactory, GetComponents, ...)
-erik
On Mon, Dec 06, 2010 at 08:58:45AM -0600, Steven R. Brandt wrote:
Do we have to call them components? Given that we're touting Cactus as a component-based framework in which the components are the thorns it seems awkward to use component for a group of thorns.
'Components' is a trac-terminology. But even if that would not be the case, there are non-Cactus components like the website, simfactory or GetComponents - and hopefully also some non-Cactus codes in the future, so I think we should avoid calling this thorns or arrangements.
Frank
On Mon, Dec 6, 2010 at 10:02 AM, Frank Loeffler knarf@cct.lsu.edu wrote:
On Mon, Dec 06, 2010 at 08:58:45AM -0600, Steven R. Brandt wrote:
Do we have to call them components? Given that we're touting Cactus as a component-based framework in which the components are the thorns it seems awkward to use component for a group of thorns.
'Components' is a trac-terminology. But even if that would not be the case, there are non-Cactus components like the website, simfactory or GetComponents - and hopefully also some non-Cactus codes in the future, so I think we should avoid calling this thorns or arrangements.
Subsystem? Problem area? Module? Unit? Section?
Of these, I like "section" best.
-erik
On Mon, Dec 06, 2010 at 11:18:18AM -0500, Erik Schnetter wrote:
Subsystem? Problem area? Module? Unit? Section?
Well, as I said - the word 'component' doesn't come from Cactus. It's trac terminology and probably deeply within the trac code. I don't think we should try to change that.
Frank
On Monday, December 6, 2010, Frank Loeffler knarf@cct.lsu.edu wrote:
On Mon, Dec 06, 2010 at 11:18:18AM -0500, Erik Schnetter wrote:
Subsystem? Problem area? Module? Unit? Section?
Well, as I said - the word 'component' doesn't come from Cactus. It's trac terminology and probably deeply within the trac code. I don't think we should try to change that.
Then let's call it "TRAC Component" to make it less confusing. After all, people are submitting reports on problems about Einstein Toolkit components and will be confused.
-Erik
Frank
users@lists.einsteintoolkit.org
-
Erik Schnetter -
Frank Loeffler -
Ian Hinder -
Steven R. Brandt