Hi Wendy - I think these things you mentioned are a symptom of a greater problem - the concept of "build definitions" is sort of unclear from the user interface perspective. When using 1.1 for the first time, I was pretty surprised by the way that build definitions are shared.
Perhaps this is due to a lack of documentation, but somehow the UI needs to better communicate which build definitions are shared and how they are shared. Ken On Thu, Sep 11, 2008 at 6:29 PM, Wendy Smoak <[EMAIL PROTECTED]> wrote: > On Wed, Sep 3, 2008 at 7:37 PM, Wendy Smoak <[EMAIL PROTECTED]> wrote: > > > This is still on my list to test and verify, but I suspect that when a > > build definition is added to a project group at group creation time > > (i.e., from a template) then that build definition is shared between > > all groups created this way. > > > > When I look at the Build Definition Templates page, I see only one > > build definition. > > > > However, if I add build definitions to existing project groups, then I > > see new build definitions show up on the templates page. > > Working with build definitions, I've observed > > 1. Each time you add a project group, a copy of each templated build > def is created. (So they are NOT shared.) > > 2. Each time a project group makes a change to their build definition, > a new build def is added to the list. (Is this correct?) > > 3. The list of build definitions on the Build Definitions Templates > page can get quite long, and it's not clear which build definitions > are actually in use. > > 4. The 'delete' icon is disabled for copies of the default build > definitions, even if the build def is edited so that a new one appears > and no one is actually using the 'original'. > > 5. The delete icon is enabled on user-added build defs and copies, > even if the build def is in use and trying to delete it will cause a > constraint violation complete with error message and stack trace. > > I'll open some issues... > > -- > Wendy >
