Re: [tools-discuss] Draft DTS requirements, 3

* Peter Tribble <[EMAIL PROTECTED]> [2007-10-07 18:57]: > On 8/20/07, Stephen Hahn <[EMAIL PROTECTED]> wrote: > > > > As some of you have guessed, I've picked up a couple of other > > problems, which caused me to slow down on this particular issue. > > Is there a list of candidates anywhere? I

Re: [tools-discuss] Draft DTS requirements, 3

On 8/20/07, Stephen Hahn <[EMAIL PROTECTED]> wrote: > > As some of you have guessed, I've picked up a couple of other > problems, which caused me to slow down on this particular issue. Is there a list of candidates anywhere? I don't seem to be able to find a record of one. There's clearly bug

Re: [tools-discuss] Draft DTS requirements, 3

On Fri, 28 Sep 2007 13:54:17 +0530 "S h i v" <[EMAIL PROTECTED]> wrote: > [1] Facility for a user to track bugs/feature that he/she identifies > as their interest list. In Bugzilla there are two ways of doing that, either by "tagging" a bug (kind of like blog tags) or by creating a search

Re: [tools-discuss] Draft DTS requirements, 3

On Fri, 28 Sep 2007 14:00:33 +0530 "S h i v" <[EMAIL PROTECTED]> wrote: > VMware appliance of Bugzilla(version 3.0.1) is available for those who > want to try it. > http://www.vmware.com/vmtn/appliances/directory/807 There's also a test site: http://landfill.bugzilla.org/

Re: [tools-discuss] Draft DTS requirements, 3

On 9/28/07, S h i v <[EMAIL PROTECTED]> wrote: > Hello, > > On 9/26/07, Stephen Hahn <[EMAIL PROTECTED]> wrote: > > > > In other news, I've been gradually working through an evaluation of > > Roundup [1], which is super-customizable but possibly has a default > > configuration that is too far

Re: [tools-discuss] Draft DTS requirements, 3

Hello, On 9/26/07, Stephen Hahn <[EMAIL PROTECTED]> wrote: > > In other news, I've been gradually working through an evaluation of > Roundup [1], which is super-customizable but possibly has a default > configuration that is too far from our minimum requirements. I'll > probably do GNATS

Re: [tools-discuss] Draft DTS requirements, 3

On Tue, 25 Sep 2007 17:48:12 -0700 Stephen Hahn <[EMAIL PROTECTED]> wrote: > > The API is also being improved for 3.2. > > Would more of the WebService interfaces be promoted to Unstable in > that release? You mean to Stable? Probably, yeah. Most of the things marked EXPERIMENTAL

Re: [tools-discuss] Draft DTS requirements, 3

* Max Kanat-Alexander <[EMAIL PROTECTED]> [2007-09-26 00:32]: > On Tue, 25 Sep 2007 17:15:59 -0700 Stephen Hahn <[EMAIL PROTECTED]> wrote: > > * Shawn Walker <[EMAIL PROTECTED]> [2007-09-26 00:01]: > > > I'm really keen on BugZilla v3, as everything I have seen so far > > > indicates that it fulfil

Re: [tools-discuss] Draft DTS requirements, 3

On Tue, 25 Sep 2007 17:15:59 -0700 Stephen Hahn <[EMAIL PROTECTED]> wrote: > * Shawn Walker <[EMAIL PROTECTED]> [2007-09-26 00:01]: > > I'm really keen on BugZilla v3, as everything I have seen so far > > indicates that it fulfills the DTS requirements. Plus, it has a > > great xmlrpc focus... > >

Re: [tools-discuss] Draft DTS requirements, 3

* Shawn Walker <[EMAIL PROTECTED]> [2007-09-26 00:01]: > I'm really keen on BugZilla v3, as everything I have seen so far > indicates that it fulfills the DTS requirements. Plus, it has a great > xmlrpc focus... Have you got a good URL for the xmlrpc APIs? I couldn't find a particularly good

Re: [tools-discuss] Draft DTS requirements, 3

On 25/09/2007, Alan Coopersmith <[EMAIL PROTECTED]> wrote: > Stephen Hahn wrote: > > E0. Open source > > > > To be considered for use by the OpenSolaris community, the > > candidate DTS is expected to be available in source form under > > an OSI-approved lic

Re: [tools-discuss] Draft DTS requirements, 3

Stephen Hahn wrote: > E0. Open source > > To be considered for use by the OpenSolaris community, the > candidate DTS is expected to be available in source form under > an OSI-approved license. At this point in time, the community > expects to b

Re: [tools-discuss] Draft DTS requirements, 3

* Stephen Lau <[EMAIL PROTECTED]> [2007-08-20 17:55]: > Stephen Hahn wrote: > > (I'll go reread the Bugzilla thread from a couple of weeks ago, but if > > anyone wants to send me edits, I'll mention that > > I believe that thread was mostly text related to how Bugzilla meets the > requirements.

Re: [tools-discuss] Draft DTS requirements, 3

Okay, I've responded to some of the additions. > Use of the candidate DTS with advanced file system > capabilities should be defined. (For example: Can ZFS clones be used > to | back up the defect corpus, or is consistency enforced > above the | file system layer

Re: [tools-discuss] Draft DTS requirements, 2

On Thu, 16 Aug 2007 18:51:44 -0400 Richard Lowe <[EMAIL PROTECTED]> wrote: > Something I think is missing here is the granularity of bug states. > Bugtraq/Bugster have 11 + substates on some, > > bugzilla seems to have 4 or 5: > UNCONFIRMED, NEW, ASSIGNED, RESOLVED (+ substates), REOPENED

[tools-discuss] Draft DTS requirements, 3

As some of you have guessed, I've picked up a couple of other problems, which caused me to slow down on this particular issue. In the revision below, I've incorporated some feedback from Charlie LaBrec, who's been involved with defect management at Sun, both as an architect and as a S

Re: [tools-discuss] Draft DTS requirements, 2

Stephen Hahn <[EMAIL PROTECTED]> writes: > I've made a number of edits, based on private feedback and the > on-alias responses. Clarifications: > > 1. My operational concern about access to the entire database was > specifically about not having a multi-gigabyte download. Nothing >

Re: [tools-discuss] Draft DTS requirements, 2

On Wed, 15 Aug 2007 16:59:46 -0700 Rachna Mahajan <[EMAIL PROTECTED]> wrote: >And there's JIRA from Atlassian. > JIRA: http://www.atlassian.com/software/jira/ JIRA fails the essential requirements by not being available under an open-source license. (Although it is offered for free to

Re: [tools-discuss] Draft DTS requirements, 2

Alan Coopersmith wrote: James C. McPherson wrote: Right, so if we accept the draft DTS requirements from sch as being almost solid - what potential candidates do we have for a system? Apart from Bugzilla, which we already know about? Ones I've heard of/seen, but know lit

Re: [tools-discuss] Draft DTS requirements, 2

> "Alan" == Alan Coopersmith <[EMAIL PROTECTED]> writes: Alan> Ubuntu Launchpad: https://launchpad.ubuntu.net/ (not sure if we Alan> can get source) IIRC, it was closed source when Mark Shuttleworth talked about it last May. mike ___ tools-discus

Re: [tools-discuss] Draft DTS requirements, 2

I suppose http://www.producingoss.com/en/bug-trackers.html might have a list On 8/16/07, Alan Coopersmith <[EMAIL PROTECTED]> wrote: > Ones I've heard of/seen, but know little else about: > Scarab: http://scarab.tigris.org/ i can't name a single large user of scarab. a nontrivial portion of tigr

Re: [tools-discuss] Draft DTS requirements, 2

> "James" == James C McPherson <[EMAIL PROTECTED]> writes: James> what potential candidates do we have for a system? Apart from James> Bugzilla, which we already know about? Roundup , which is what the Mercurial project uses. mike

Re: [tools-discuss] Draft DTS requirements, 2

Alan Coopersmith wrote: > James C. McPherson wrote: >> Right, so if we accept the draft DTS requirements >> from sch as being almost solid - what potential >> candidates do we have for a system? Apart from >> Bugzilla, which we already know about? > > Ones I've heard of/seen, but know little else

Re: [tools-discuss] Draft DTS requirements, 2

James C. McPherson wrote: > Right, so if we accept the draft DTS requirements > from sch as being almost solid - what potential > candidates do we have for a system? Apart from > Bugzilla, which we already know about? Ones I've heard of/seen, but know little else about: Scarab: http://scarab.tigr

Re: [tools-discuss] Draft DTS requirements, 2

Stephen Lau wrote: ... > So we, the OpenSolaris Tools Community, need to move ahead with getting > that next draft published - any comments addressed, and get started with > the evaluation. > > To the rest of the community: none of this is blocking on any action by > the Bugster team. This is

Re: [tools-discuss] Draft DTS requirements, 2

Valerie Bubb Fenwick wrote: > On Wed, 15 Aug 2007, Stephen Lau wrote: > >> Rachna Mahajan wrote: >>> The BugTraq team has been involved all along , however we did not make >>> our presence felt on the forum. >> >> There is no such thing. :) You can't be involved and not be on the >> forum. How

Re: [tools-discuss] Draft DTS requirements, 2

On Wed, 15 Aug 2007, Stephen Lau wrote: > Rachna Mahajan wrote: >> The BugTraq team has been involved all along , however we did not make >> our presence felt on the forum. > > There is no such thing. :) You can't be involved and not be on the > forum. How else are people supposed to know you

Re: [tools-discuss] Draft DTS requirements, 2

Rachna Mahajan wrote: > The BugTraq team has been involved all along , however we did not make > our presence felt on the forum. There is no such thing. :) You can't be involved and not be on the forum. How else are people supposed to know you are involved? > The BugTraq team responded to t

Re: [tools-discuss] Draft DTS requirements, 2

Richard Lowe writes: > Rachna Mahajan <[EMAIL PROTECTED]> writes: > > [I've requoted this, and may have messed up...] Thanks. The HTML noise was driving me batty. ;-} > It would appear that (beyond the interest-list work), progress here > would stem from the mail thread that's been happening o

Re: [tools-discuss] Draft DTS requirements, 2

Rachna Mahajan <[EMAIL PROTECTED]> writes: [I've requoted this, and may have messed up...] >> James C. McPherson wrote: >> >>> Rachna Mahajan wrote: >>> ... >>> >>> While we have been taking some baby steps to help make the final >>> decisions, we are working on making some changes to the B

Re: [tools-discuss] Draft DTS requirements, 2

James C. McPherson wrote: Rachna Mahajan wrote: ... While we have been taking some baby steps to help make the final decisions, we are working on making some changes to the BugTraq's email notification program for notifications sent to non-Sun addresses. We will be piloting the chang

Re: [tools-discuss] Draft DTS requirements, 2

Rachna Mahajan <[EMAIL PROTECTED]> writes: > Richard Lowe wrote: > >>> Stephen Hahn <[EMAIL PROTECTED]> writes: >>> >>> >>> >>> I've made a number of edits, based on private feedback and the >>> on-alias responses. Clarifications: >>> >>> 1. My operational concern about access to the entire

Re: [tools-discuss] Draft DTS requirements, 2

James C. McPherson wrote: > Rachna Mahajan wrote: > ... > >> While we have been taking some baby steps to help make the final >> decisions, we are working on making some changes to the BugTraq's email >> notification program for notifications sent to non-Sun addresses. We >> will be piloting th

Re: [tools-discuss] Draft DTS requirements, 2

Rachna Mahajan wrote: ... > While we have been taking some baby steps to help make the final > decisions, we are working on making some changes to the BugTraq's email > notification program for notifications sent to non-Sun addresses. We > will be piloting the change for Open Solaris in Septemb

Re: [tools-discuss] Draft DTS requirements, 2

Richard Lowe wrote: Stephen Hahn <[EMAIL PROTECTED]> writes: I've made a number of edits, based on private feedback and the on-alias responses. Clarifications: 1. My operational concern about access to the entire database was specifically about not having a multi-gi

Re: [tools-discuss] Draft DTS requirements, 2

Stephen Hahn <[EMAIL PROTECTED]> writes: > I've made a number of edits, based on private feedback and the > on-alias responses. Clarifications: > > 1. My operational concern about access to the entire database was > specifically about not having a multi-gigabyte download. Nothing >

Re: [tools-discuss] Draft DTS requirements, 2

Hey folks. I just signed up for this list today. I was directed here by timeless. To clarify things, timeless is a Bugzilla user and contributor to the codebase. His views represent some definitely experience with Bugzilla, but they are his own, not those of the Bugzilla Project in

Re: [tools-discuss] Draft DTS requirements, 2

Alan Coopersmith wrote: > With a public system, having the ability to delete spam and similar > non-bug abuse that sneaks in would be good - I agree that deleting > actual technical information should not be done. > > Similarly, user accounts should be deleted or permanently disabled > only in ca

Re: [tools-discuss] Draft DTS requirements, 2

On 8/1/07, Alan Coopersmith <[EMAIL PROTECTED]> wrote: > With a public system, having the ability to delete spam and similar > non-bug abuse that sneaks in would be good - I agree that deleting > actual technical information should not be done. It's possible to hide comments (one approach for hand

Re: [tools-discuss] Draft DTS requirements, 2

On 8/1/07, James Carlson <[EMAIL PROTECTED]> wrote: > The first section is about defect categories. It should be possible > to mark them as "closed," meaning that new bugs can't be filed > (because the software itself no longer exists or because the category > has been refactored). this is indeed

Re: [tools-discuss] Draft DTS requirements, 2

James Carlson wrote: > The requirements said nothing about deleting bugs. The requirements > said: > > | It should be possible, via the interfaces or extension > | facilities, to perform administrative operations on the DTS: > | creation, modification, and closure of defect categories (or > | oth

Re: [tools-discuss] Draft DTS requirements, 2

timeless writes: > On 8/1/07, James Carlson <[EMAIL PROTECTED]> wrote: > basically, you can > 1. load the bugzilla query page > 2. {paste} a comma delimited list into > Email Addresses, Bug Numbers, and Votes > [Only include |v] bugs numbered: [ ] > 3. press the [Search] > 4. S

Re: [tools-discuss] Draft DTS requirements, 2

On 8/1/07, James Carlson <[EMAIL PROTECTED]> wrote: > I can answer some of your questions ... > Suppressing 'bugmail' isn't the issue. good. > When a build cycle closes, the > gatekeepers mark the bugs and RFEs in that build as "integrated." > There are often a *lot* of these, so these changes si

Re: [tools-discuss] Draft DTS requirements, 2

timeless writes: > On Tue Jun 19 13:54:30 2007, Stephen Hahn wrote: > > I've made a number of edits, based on private feedback and the > > on-alias responses. Clarifications: > > I've made an annotated version of this document, > from the perspect

Re: [tools-discuss] Draft DTS requirements, 2

On Tue Jun 19 13:54:30 2007, Stephen Hahn wrote: > I've made a number of edits, based on private feedback and the > on-alias responses. Clarifications: I've made an annotated version of this document, from the perspective of potential Bugzilla ado

Re: [tools-discuss] Draft DTS requirements

Mike Kupfer wrote: Here are a few more thoughts on requirements, after spending 20 minutes or so looking through the Bugster functional specs. * automated account creation (conditional requirement?). It should be possible to use one's opensolaris.org account to access the BTS. Example imple

Re: [tools-discuss] Draft DTS requirements, 2

* Bill Sommerfeld <[EMAIL PROTECTED]> [2007-06-19 15:23]: > On Tue, 2007-06-19 at 13:53 -0700, Stephen Hahn wrote: > > 2. The relationship between the development branch and the > > maintenance branches of any particular consolidation does not seem > > well understood. It seems prem

Re: [tools-discuss] Draft DTS requirements, 2

On Tue, 2007-06-19 at 13:53 -0700, Stephen Hahn wrote: > 2. The relationship between the development branch and the > maintenance branches of any particular consolidation does not seem > well understood. It seems premature to conclude that a multiple > release relationship bel

[tools-discuss] Draft DTS requirements, 2

I've made a number of edits, based on private feedback and the on-alias responses. Clarifications: 1. My operational concern about access to the entire database was specifically about not having a multi-gigabyte download. Nothing else should be read into that point. 2.

Re: [tools-discuss] Draft DTS requirements

James C. McPherson wrote: Mike Kupfer wrote: Here are a few more thoughts on requirements, after spending 20 minutes or so looking through the Bugster functional specs. * automated account creation (conditional requirement?). It should be possible to use one's opensolaris.org account to acce

Re: [tools-discuss] Draft DTS requirements

James C. McPherson wrote: Mike Kupfer wrote: Here are a few more thoughts on requirements, after spending 20 minutes or so looking through the Bugster functional specs. * automated account creation (conditional requirement?). It should be possible to use one's opensolaris.org account to acce

Re: [tools-discuss] Draft DTS requirements

Mike Kupfer wrote: Here are a few more thoughts on requirements, after spending 20 minutes or so looking through the Bugster functional specs. * automated account creation (conditional requirement?). It should be possible to use one's opensolaris.org account to access the BTS. Example imple

Re: [tools-discuss] Draft DTS requirements

Here are a few more thoughts on requirements, after spending 20 minutes or so looking through the Bugster functional specs. * automated account creation (conditional requirement?). It should be possible to use one's opensolaris.org account to access the BTS. Example implementation techniques:

Re: [tools-discuss] Draft DTS requirements

Mike Kupfer wrote: 2.2. Ideal outcome sequence [...] Phase 2. Deprecated second system. Integrations must refer only to bugs in the community DTS, but bugs could be filed in either system. This seems backwards, in that it encourages extra copying (new bugs can get filed in the lega

Re: [tools-discuss] Draft DTS requirements

Mike Kupfer wrote: 2.2. Ideal outcome sequence [...] Phase 2. Deprecated second system. Integrations must refer only to bugs in the community DTS, but bugs could be filed in either system. This seems backwards, in that it encourages extra copying (new bugs can get filed in the lega

Re: [tools-discuss] Draft DTS requirements

> 2.2. Ideal outcome sequence [...] > Phase 2. Deprecated second system. Integrations must refer only to > bugs in the community DTS, but bugs could be filed in either system. This seems backwards, in that it encourages extra copying (new bugs can get filed in the legacy system, only t

Re: [tools-discuss] Draft DTS requirements

Richard Lowe writes: > > I think we do have to have a way to maintain referential integrity > > between the open bug database and private data stores, but I don't > > think we can avoid the problem merely by hiding away the raw (open) > > repository. > > True, I was referring to (I think) the init

Re: [tools-discuss] Draft DTS requirements

James Carlson wrote: Richard Lowe writes: James Carlson wrote: Stephen Hahn writes: descriptions (E7). (I'm also curious about operational requirements about offering the entire community bug corpus, but that's probably separate.) I don't think it's separate from the DTS requirement

Re: [tools-discuss] Draft DTS requirements

Richard Lowe writes: > James Carlson wrote: > > Stephen Hahn writes: > >>descriptions (E7). (I'm also curious about operational requirements > >>about offering the entire community bug corpus, but that's probably > >>separate.) > > > > I don't think it's separate from the DTS requirem

Re: [tools-discuss] Draft DTS requirements

James Carlson wrote: Stephen Hahn writes: descriptions (E7). (I'm also curious about operational requirements about offering the entire community bug corpus, but that's probably separate.) I don't think it's separate from the DTS requirements at all. I see offering the raw database

Re: [tools-discuss] Draft DTS requirements

Stephen Hahn writes: >descriptions (E7). (I'm also curious about operational requirements >about offering the entire community bug corpus, but that's probably >separate.) I don't think it's separate from the DTS requirements at all. I see offering the raw database itself as a fundame

[tools-discuss] Draft DTS requirements

Here's a starting point for the defect tracking requirements. It incorporates many of Keith's requirements, updated for the changes in context since last fall. I'd like to flesh out the candidate transactions, maybe add some optional requirements around notification choices, and e