From bugzilla at colinogilvie.co.uk Sun Apr 8 17:46:31 2007 From: bugzilla at colinogilvie.co.uk (Colin Ogilvie) Date: Sun, 08 Apr 2007 18:46:31 +0100 Subject: JavaScript Concern from a recent review In-Reply-To: <200704070116.l371GK6t007951@recluse.mozilla.org> References: <200704070116.l371GK6t007951@recluse.mozilla.org> Message-ID: <46192A77.8080804@colinogilvie.co.uk> bugzilla-daemon at mozilla.org wrote: > Nit: omit braces for one-line conditional and loop blocks here and elsewhere, > i.e.: > > for (var i = 0; i < document.forms.length; i++) > for (var j = 0; j < document.forms[i].elements.length; j++) > /* MS decided to add fieldsets to the elements array; and > * Mozilla decided to copy this brokenness. Grr. > */ > if (document.forms[i].elements[j].tagName != 'FIELDSET') > document.forms[i].elements[j].onmouseover = showHelp; I'm concerned by a recent review Myk did on a JavaScript file (quoted above) where he says that for one-line conditionals and loop blocks you should omit braces (as a Nit). I'd like to suggest that this is a bad practice, and possibly going to cause confusion in the future, particularly in the example above. For clarity, it would be better written including braces. Does anyone else have thoughts on this, or is it just because I've been bitten by this in something I was doing at work... Colin From justdave at bugzilla.org Sun Apr 8 20:16:47 2007 From: justdave at bugzilla.org (David Miller) Date: Sun, 08 Apr 2007 16:16:47 -0400 Subject: JavaScript Concern from a recent review In-Reply-To: <46192A77.8080804@colinogilvie.co.uk> References: <200704070116.l371GK6t007951@recluse.mozilla.org> <46192A77.8080804@colinogilvie.co.uk> Message-ID: <46194DAF.6000509@bugzilla.org> Colin Ogilvie wrote on 4/8/07 1:46 PM: > bugzilla-daemon at mozilla.org wrote: >> Nit: omit braces for one-line conditional and loop blocks here and >> elsewhere, >> i.e.: >> >> for (var i = 0; i < document.forms.length; i++) >> for (var j = 0; j < document.forms[i].elements.length; j++) >> /* MS decided to add fieldsets to the elements array; and >> * Mozilla decided to copy this brokenness. Grr. >> */ >> if (document.forms[i].elements[j].tagName != 'FIELDSET') >> document.forms[i].elements[j].onmouseover = showHelp; > > I'm concerned by a recent review Myk did on a JavaScript file (quoted > above) where he says that for one-line conditionals and loop blocks you > should omit braces (as a Nit). > > I'd like to suggest that this is a bad practice, and possibly going to > cause confusion in the future, particularly in the example above. For > clarity, it would be better written including braces. > > Does anyone else have thoughts on this, or is it just because I've been > bitten by this in something I was doing at work... Although javascript does make it optional, if it extends more than one line to make it readable (especially like in the above example where there's nested loops) I'd just as soon use the braces, because as you said, it makes it much easier to follow what's looping. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From gerv at mozilla.org Mon Apr 9 09:43:24 2007 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 09 Apr 2007 10:43:24 +0100 Subject: JavaScript Concern from a recent review In-Reply-To: <46192A77.8080804@colinogilvie.co.uk> References: <200704070116.l371GK6t007951@recluse.mozilla.org> <46192A77.8080804@colinogilvie.co.uk> Message-ID: <461A0ABC.5090008@mozilla.org> Colin Ogilvie wrote: > I'm concerned by a recent review Myk did on a JavaScript file (quoted > above) where he says that for one-line conditionals and loop blocks you > should omit braces (as a Nit). > > I'd like to suggest that this is a bad practice, and possibly going to > cause confusion in the future, particularly in the example above. For > clarity, it would be better written including braces. I would agree with you, and respectfully disagree with Myk. I don't believe that omitting braces adds to readability. The most it does, given Bugzilla's current coding style, is save a line. And I don't think that advantage outweighs the potential mistakes that can be made in maintenance, and the mental switch required to notice the different syntax in this special case. Gerv From dwilliss at microimages.com Mon Apr 9 13:55:36 2007 From: dwilliss at microimages.com (Dave Williss) Date: Mon, 09 Apr 2007 08:55:36 -0500 Subject: JavaScript Concern from a recent review In-Reply-To: <461A0ABC.5090008@mozilla.org> References: <200704070116.l371GK6t007951@recluse.mozilla.org> <46192A77.8080804@colinogilvie.co.uk> <461A0ABC.5090008@mozilla.org> Message-ID: <461A45D8.2040400@microimages.com> Gervase Markham wrote: > Colin Ogilvie wrote: >> I'm concerned by a recent review Myk did on a JavaScript file (quoted >> above) where he says that for one-line conditionals and loop blocks >> you should omit braces (as a Nit). >> >> I'd like to suggest that this is a bad practice, and possibly going >> to cause confusion in the future, particularly in the example above. >> For clarity, it would be better written including braces. > > I would agree with you, and respectfully disagree with Myk. I don't > believe that omitting braces adds to readability. The most it does, > given Bugzilla's current coding style, is save a line. And I don't > think that advantage outweighs the potential mistakes that can be made > in maintenance, and the mental switch required to notice the different > syntax in this special case. Where I work, our code style guidelines actually *require* braces in this case. The only time we don't require them is if the whole thing is on one line. This is for C/C++ code, but it applies to just about any language which uses braces. In fact, if I'm not mistaken, in Perl it's actually invalid syntax to omit them. I vote for braces. Much more readable. From myk at mozilla.org Mon Apr 9 14:40:07 2007 From: myk at mozilla.org (Myk Melez) Date: Mon, 09 Apr 2007 07:40:07 -0700 Subject: JavaScript Concern from a recent review In-Reply-To: <46192A77.8080804@colinogilvie.co.uk> References: <200704070116.l371GK6t007951@recluse.mozilla.org> <46192A77.8080804@colinogilvie.co.uk> Message-ID: <461A5047.7010907@mozilla.org> Colin Ogilvie wrote: > I'm concerned by a recent review Myk did on a JavaScript file (quoted > above) where he says that for one-line conditionals and loop blocks > you should omit braces (as a Nit). > > I'd like to suggest that this is a bad practice, and possibly going to > cause confusion in the future, particularly in the example above. For > clarity, it would be better written including braces. The advantages to omitting braces are code concision and consistency with Firefox coding practices. > Does anyone else have thoughts on this, or is it just because I've > been bitten by this in something I was doing at work... I've been bitten occasionally by implicit braces, but I'm bitten regularly by complex code, and braces for one-line blocks adds to that complexity without providing enough compensatory elucidation, IMHO. -myk From myk at mozilla.org Mon Apr 9 15:05:06 2007 From: myk at mozilla.org (Myk Melez) Date: Mon, 09 Apr 2007 08:05:06 -0700 Subject: JavaScript Concern from a recent review In-Reply-To: <461A0ABC.5090008@mozilla.org> References: <200704070116.l371GK6t007951@recluse.mozilla.org> <46192A77.8080804@colinogilvie.co.uk> <461A0ABC.5090008@mozilla.org> Message-ID: <461A5622.8090605@mozilla.org> Gervase Markham wrote: > I don't believe that omitting braces adds to readability. The most it > does, given Bugzilla's current coding style, is save a line. In this case, omitting braces actually saves three lines, and it would be even clearer if the comment commented the entire block to which it applies. The original: for (var i = 0; i < document.forms.length; i++) { for (var j = 0; j < document.forms[i].elements.length; j++) { /* MS decided to add fieldsets to the elements array; and * Mozilla decided to copy this brokenness. Grr. */ if (document.forms[i].elements[j].tagName != 'FIELDSET') { document.forms[i].elements[j].onmouseover = showHelp; } } } My nit: for (var i = 0; i < document.forms.length; i++) for (var j = 0; j < document.forms[i].elements.length; j++) /* MS decided to add fieldsets to the elements array; and * Mozilla decided to copy this brokenness. Grr. */ if (document.forms[i].elements[j].tagName != 'FIELDSET') document.forms[i].elements[j].onmouseover = showHelp; What I consider optimal: // MS decided to add fieldsets to the elements array; // and Mozilla decided to copy this brokenness. Grr. for (var i = 0; i < document.forms.length; i++) for (var j = 0; j < document.forms[i].elements.length; j++) if (document.forms[i].elements[j].tagName != 'FIELDSET') document.forms[i].elements[j].onmouseover = showHelp; > And I don't think that advantage outweighs the potential mistakes that > can be made in maintenance, and the mental switch required to notice > the different syntax in this special case. It's not a particularly special case, as one-line blocks occur frequently in code, and the "mental-switch" required is IMHO less significant than that required to grok a condition/block combination on a single line. -myk From myk at mozilla.org Mon Apr 9 15:08:19 2007 From: myk at mozilla.org (Myk Melez) Date: Mon, 09 Apr 2007 08:08:19 -0700 Subject: JavaScript Concern from a recent review In-Reply-To: <461A45D8.2040400@microimages.com> References: <200704070116.l371GK6t007951@recluse.mozilla.org> <46192A77.8080804@colinogilvie.co.uk> <461A0ABC.5090008@mozilla.org> <461A45D8.2040400@microimages.com> Message-ID: <461A56E3.6080602@mozilla.org> Dave Williss wrote: > Where I work, our code style guidelines actually *require* braces in > this case. The only time we don't require them is if the whole thing > is on one line. FWIW, in another nit in the same review, I suggest not putting the block on the same line as the condition, i.e.: >+ if (phase < 1 && phase > 2) return false; Nit: block on a new line here and elsewhere: if (phase < 1 && phase > 2) return false; > This is for C/C++ code, but it applies to just about any language > which uses braces. In fact, if I'm not mistaken, in Perl it's > actually invalid syntax to omit them. Right, except with statement modifiers. FWIW, I do think braces are justified for certain one-line blocks, like where there are nested elses. I just don't think they help more than they hurt in the general case. But this seems to be a matter of opinion, and Dave says he wants braces, so nit revoked. -myk From gerv at mozilla.org Thu Apr 12 16:34:11 2007 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 12 Apr 2007 17:34:11 +0100 Subject: UI for editing workflow Message-ID: <461E5F83.1000906@mozilla.org> LpSolit is working on custom statuses and editable workflow. I've mocked up a UI for configuring what transitions are permitted. What we are basically doing here is configuring permitted and forbidden transitions in a state machine. This particular application cries out for a matrix where you mark a transition as yes/no at each intersection. http://landfill.bugzilla.org/qa30pg/page.cgi?id=editworkflow.html [When you define a new status, you say whether it's an open status or a closed one, and that drives the colour (and other things like whether a resolution is required).] Note click behaviour and tooltips. I think this UI is good because you can visually pick out patterns in the workflow, e.g.: * The big blue block in the top left shows you can move from any opened state (apart from UNCO) to any other one - except you can't do REOPENED -> NEW. * The vertical line of three in the middle shows that you can REOPEN from any closed state apart from BURIED. * The diagonal line in the bottom right shows that RESOLVED -> VERIFIED -> CLOSED -> BURIED is a progression. * The nearly-empty vertical line on the left shows there's no way back to UNCONFIRMED. Other features: * Impossible or meaningless transitions are clearly marked by the lack of a checkbox. * It easily answers the obvious questions in *both* directions - i.e. "Where can I go from UNCONFIRMED", and "How can I get to VERIFIED". A list-based system would only answer one of those easily. What do you think? Gerv -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: editworkflow.html.tmpl URL: From justdave at bugzilla.org Thu Apr 12 18:50:35 2007 From: justdave at bugzilla.org (David Miller) Date: Thu, 12 Apr 2007 11:50:35 -0700 Subject: UI for editing workflow In-Reply-To: <461E5F83.1000906@mozilla.org> References: <461E5F83.1000906@mozilla.org> Message-ID: <461E7F7B.1090702@bugzilla.org> Gervase Markham wrote on 4/12/07 9:34 AM: > I've mocked up a UI for configuring what transitions are permitted. I like it. -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From myk at mozilla.org Thu Apr 12 19:08:09 2007 From: myk at mozilla.org (Myk Melez) Date: Thu, 12 Apr 2007 12:08:09 -0700 Subject: UI for editing workflow In-Reply-To: <461E5F83.1000906@mozilla.org> References: <461E5F83.1000906@mozilla.org> Message-ID: <461E8399.8080204@mozilla.org> Gervase Markham wrote: > What do you think? This looks pretty usable to me. I particularly like the use of a table and colors to bring out the patterns in the process. Nit: it seems like green and red would be better suited to indicate which transitions can/cannot be made (i.e. as table cell background colors) than to denote open/closed states, given their "go/stop" semantics. Also, the {start} -> REOPENED transition doesn't make much sense to me (which leads me to wonder whether "reopened" is really a state or, like "everconfirmed," an aspect of the state history better defined as something like "everclosed"), but {start} -> closed states could make sense for installations that want to record bugs that they ended up fixing before they got around to filing reports on them. In any case, however these issues are resolved (or whether they're addressed at all), this seems like a fine design. -myk From olav at bkor.dhs.org Thu Apr 12 19:11:29 2007 From: olav at bkor.dhs.org (Olav Vitters) Date: Thu, 12 Apr 2007 21:11:29 +0200 Subject: UI for editing workflow In-Reply-To: <461E5F83.1000906@mozilla.org> References: <461E5F83.1000906@mozilla.org> Message-ID: <20070412191129.GA26443@bkor.dhs.org> On Thu, Apr 12, 2007 at 05:34:11PM +0100, Gervase Markham wrote: > LpSolit is working on custom statuses and editable workflow. I've mocked > up a UI for configuring what transitions are permitted. > > What we are basically doing here is configuring permitted and forbidden > transitions in a state machine. This particular application cries out > for a matrix where you mark a transition as yes/no at each intersection. > > http://landfill.bugzilla.org/qa30pg/page.cgi?id=editworkflow.html r+ ;) Nits: * I want to click anywhere within the cell of a table and change the checkbox state. This should be possible to do with only CSS. * I want the rows state and columns state highlighted. So it doesn't have to be the entire row/column, just the two states (e.g. needinfo and new). This so I can quickly see what the checkbox will do. -- Regards, Olav From dwilliss at microimages.com Thu Apr 12 20:27:35 2007 From: dwilliss at microimages.com (Dave Williss) Date: Thu, 12 Apr 2007 15:27:35 -0500 Subject: UI for editing workflow In-Reply-To: <461E5F83.1000906@mozilla.org> References: <461E5F83.1000906@mozilla.org> Message-ID: <461E9637.3020907@microimages.com> I like it! I especially like having NEEDINFO as a state. We have it in our bugzilla as "resolution" partly because it was easy to add that way, but mainly because when we started using bugzilla, we used RESOLVED/INVALID to mean the same thing. But logically if a bug NEEDINFO, it's not resolved. Gervase Markham wrote: > LpSolit is working on custom statuses and editable workflow. I've > mocked up a UI for configuring what transitions are permitted. > > What we are basically doing here is configuring permitted and > forbidden transitions in a state machine. This particular application > cries out for a matrix where you mark a transition as yes/no at each > intersection. > > http://landfill.bugzilla.org/qa30pg/page.cgi?id=editworkflow.html > > [When you define a new status, you say whether it's an open status or > a closed one, and that drives the colour (and other things like > whether a resolution is required).] > > Note click behaviour and tooltips. I think this UI is good because you > can visually pick out patterns in the workflow, e.g.: > > * The big blue block in the top left shows you can move from any opened > state (apart from UNCO) to any other one - except you can't do > REOPENED -> NEW. > > * The vertical line of three in the middle shows that you can REOPEN > from any closed state apart from BURIED. > > * The diagonal line in the bottom right shows that RESOLVED -> VERIFIED > -> CLOSED -> BURIED is a progression. > > * The nearly-empty vertical line on the left shows there's no way back > to UNCONFIRMED. > > Other features: > > * Impossible or meaningless transitions are clearly marked by the lack > of a checkbox. > > * It easily answers the obvious questions in *both* directions - i.e. > "Where can I go from UNCONFIRMED", and "How can I get to VERIFIED". A > list-based system would only answer one of those easily. > > What do you think? > > Gerv > > ------------------------------------------------------------------------ > > [% PROCESS "global/field-descs.none.tmpl" %] > > [% INCLUDE global/header.html.tmpl > title = "Edit Workflow" > style = '.col-header { width: 70px; } > .checkbox-cell { border: 1px black solid } > .open-status { color: green } > .closed-status { color: red } > .checked { background-color: lightblue }' > %] > > [% open_statuses = ["UNCONFIRMED", "NEEDINFO", "NEW", "ASSIGNED", "REOPENED"] %] > [% closed_statuses = ["RESOLVED", "VERIFIED", "CLOSED", "BURIED"] %] > [% test_data = [ [ 1, 2, 0, 0, 0, 0, 0, 0, 0, 0 ], > [ 0, 1, 2, 1, 1, 1, 0, 0, 0, 0 ], > [ 1, 1, 1, 2, 1, 0, 0, 0, 0, 0 ], > [ 0, 1, 1, 1, 2, 1, 0, 0, 0, 0 ], > [ 0, 0, 0, 0, 0, 2, 1, 1, 1, 0 ], > [ 2, 1, 1, 1, 1, 1, 2, 0, 0, 0 ], > [ 2, 0, 0, 0, 0, 0, 1, 2, 0, 0 ], > [ 2, 0, 0, 0, 0, 0, 0, 1, 2, 0 ], > [ 2, 0, 0, 0, 0, 0, 0, 0, 1, 2 ], > ] > %] > > [%# List concatenation in TT? %] > [% statuses = open_statuses.merge(closed_statuses) %] > > [% start = ["{Start}"] %] > [% status_cols = start.merge(statuses) %] > > > >

This page allows you to define which status transitions are valid in your workflow.

> > > > > > > > > > > > [% FOREACH status = status_cols %] > > [% END %] > > > [% FOREACH status_row = statuses %] > > > [% row_index = loop.index %] > [% FOREACH status_col = status_cols %] > [% col_index = loop.index %] > > [% END %] > > [% END %] > >
   >

From

>

To

 "> > [% status %] >
">[% status_row %] title="From [% status_col %] to [% status_row %]" > > > [% IF test_data.$row_index.$col_index != 2 %] > [% " checked='checked'" IF test_data.$row_index.$col_index == 1 %] > onclick="toggle_cell(this)" > > > [% END %] >
> >
> >

[Note: this is the current Bugzilla workflow, with a couple of extra statuses (NEEDINFO, BURIED) thrown in for illustration purposes. Try clicking a checkbox. I believe this is all the UI that customised statuses would require. The presentation of the knob could be, in most cases, determined programmatically from the current state, the possible new states, and whether the transition was an open -> closed or not.]

> > >
> > [% INCLUDE global/footer.html.tmpl %] > ------------------------------------------------------------------------ > > - > To view or change your list settings, click here: > > From ghendricks at novell.com Thu Apr 12 20:45:53 2007 From: ghendricks at novell.com (Gregary Hendricks) Date: Thu, 12 Apr 2007 14:45:53 -0600 Subject: UI for editing workflow Message-ID: <461E4621020000D200009272@sinclair.provo.novell.com> On Thu, 2007-04-12 at 17:34 +0100, Gervase Markham wrote: > LpSolit is working on custom statuses and editable workflow. I've mocked > up a UI for configuring what transitions are permitted. > This is very well done. It is not overly complex. I agree that it would be better if we could click anywhere in the cell and I would hilight the boxes that are invalid with some subtle color to help make them stand out from the ones that have checkboxes in them. Good Job. Can't wait to see this live. Greg From kevin.benton at amd.com Thu Apr 12 21:55:58 2007 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 12 Apr 2007 14:55:58 -0700 Subject: UI for editing workflow In-Reply-To: <461E5F83.1000906@mozilla.org> References: <461E5F83.1000906@mozilla.org> Message-ID: Gerv - nice job on a significant process improvement with providing a way to manage status transitions from the UI. I think that taking it a bit further might be even better. Offering users the ability to configure which statuses are possible versus those that are not really helps. I think that we're missing the ability to configure which statuses are open versus those that are closed. I wonder if it wouldn't make sense to have a way to configure that list from this page as well. Maybe by adding a column on the left that allows users to select Open/Closed would be intuitive like... | State Type | UNCONFIRMED | NEEDINFO | NEW ... {Start} | | | | UNCONFIRMED | [ Open |v] | | O | O NEEDINFO | [ Open |v] | O | | x NEW | [ Open |v] | O | x | ASSIGNED | [ Open |v] | O | x | x REOPENED | [ Open |v] | O | x | O RESOLVED | [Closed|v] | O | O | O VERIFIED | [Closed|v] | O | O | O CLOSED | [Closed|v] | O | O | O BURIED | [Closed|v] | O | O | O For 3.2, I think we ought to rename Resolution to Sub_Status or Reason, then add a substatus table that includes the list of statuses and possible sub-statuses. This is critical when processes allow a DEFERRED or PENDING status of sorts. For process management, it's important to know why something is deferred, not just that it's deferred. The same can be said about DISCARDED - why was an issue discarded? Then, when a sub-status is available, for a given status, one of the sub statuses can be required. Kevin Benton Senior Software Developer MSS Silicon Design Engineering Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. > -----Original Message----- > From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] > On Behalf Of Gervase Markham > Sent: Thursday, April 12, 2007 10:34 AM > To: developers at bugzilla.org > Subject: UI for editing workflow > > LpSolit is working on custom statuses and editable workflow. I've mocked > up a UI for configuring what transitions are permitted. > > What we are basically doing here is configuring permitted and forbidden > transitions in a state machine. This particular application cries out > for a matrix where you mark a transition as yes/no at each intersection. > > http://landfill.bugzilla.org/qa30pg/page.cgi?id=editworkflow.html > > [When you define a new status, you say whether it's an open status or a > closed one, and that drives the colour (and other things like whether a > resolution is required).] > > Note click behaviour and tooltips. I think this UI is good because you > can visually pick out patterns in the workflow, e.g.: > > * The big blue block in the top left shows you can move from any opened > state (apart from UNCO) to any other one - except you can't do > REOPENED -> NEW. > > * The vertical line of three in the middle shows that you can REOPEN > from any closed state apart from BURIED. > > * The diagonal line in the bottom right shows that RESOLVED -> VERIFIED > -> CLOSED -> BURIED is a progression. > > * The nearly-empty vertical line on the left shows there's no way back > to UNCONFIRMED. > > Other features: > > * Impossible or meaningless transitions are clearly marked by the lack > of a checkbox. > > * It easily answers the obvious questions in *both* directions - i.e. > "Where can I go from UNCONFIRMED", and "How can I get to VERIFIED". A > list-based system would only answer one of those easily. > > What do you think? > > Gerv From gerv at mozilla.org Thu Apr 12 18:03:28 2007 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 12 Apr 2007 19:03:28 +0100 Subject: UI for editing workflow In-Reply-To: <461E5F83.1000906@mozilla.org> References: <461E5F83.1000906@mozilla.org> Message-ID: <461E7470.8070903@mozilla.org> Gervase Markham wrote: > LpSolit is working on custom statuses and editable workflow. I've mocked > up a UI for configuring what transitions are permitted. Oops; didn't mean to attach the mockup template. But, now that I have, people who want to fiddle should drop it into template/en/default/pages/. Gerv From lpsolit at gmail.com Thu Apr 12 22:07:21 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Fri, 13 Apr 2007 00:07:21 +0200 Subject: UI for editing workflow In-Reply-To: References: <461E5F83.1000906@mozilla.org> Message-ID: <461EAD99.6000006@gmail.com> Benton, Kevin a ?crit : > I think that we're missing the ability to > configure which statuses are open versus those that are closed. Unrelated, really! This page is to configure the workflow itself, not to edit the list of statuses. We already have editvalues.cgi for that. > wonder if it wouldn't make sense to have a way to configure that list > from this page as well. Definitely not! > For 3.2, I think we ought to rename Resolution to Sub_Status or Reason, Here too, I see no reason to rename resolution to something else. You are free to edit your templates to replace "resolution" by "sub_status", but the probability that we do it upstream is pretty low. FYI, if everything goes well, custom statuses may be fully implemented within 2-3 weeks (assuming reviewers and me have time to write/review missing patches). LpSolit PS: /me wonders why people keep pasting the whole email when replying. :) From gerv at mozilla.org Thu Apr 12 22:36:54 2007 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 12 Apr 2007 23:36:54 +0100 Subject: UI for editing workflow In-Reply-To: <461E8399.8080204@mozilla.org> References: <461E5F83.1000906@mozilla.org> <461E8399.8080204@mozilla.org> Message-ID: <461EB486.6080603@mozilla.org> Myk Melez wrote: > Nit: it seems like green and red would be better suited to indicate > which transitions can/cannot be made (i.e. as table cell background > colors) than to denote open/closed states, given their "go/stop" semantics. I agree. > Also, the {start} -> REOPENED transition doesn't make much sense to me > (which leads me to wonder whether "reopened" is really a state or, like > "everconfirmed," an aspect of the state history better defined as > something like "everclosed"), but {start} -> closed states could make > sense for installations that want to record bugs that they ended up > fixing before they got around to filing reports on them. I think it's interesting that two of the Bugzillas I surveyed recently which chose to hack statuses removed REOPENED. I wonder if that state actually has much value over just sticking the bug back in NEW. We could enable the {Start} -> CLOSED transitions, but it would complicate the enter_bug UI as it would need to provide the ability to set them. I suggest that, in the rare case you mention, people content themselves with a 2-step process. Gerv From gerv at mozilla.org Thu Apr 12 22:37:53 2007 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 12 Apr 2007 23:37:53 +0100 Subject: UI for editing workflow In-Reply-To: <20070412191129.GA26443@bkor.dhs.org> References: <461E5F83.1000906@mozilla.org> <20070412191129.GA26443@bkor.dhs.org> Message-ID: <461EB4C1.5030605@mozilla.org> Olav Vitters wrote: > * I want to click anywhere within the cell of a table and change the > checkbox state. This should be possible to do with only CSS. Yes, I believe one can expand the borders of the checkbox. > * I want the rows state and columns state highlighted. So it doesn't > have to be the entire row/column, just the two states (e.g. needinfo and > new). This so I can quickly see what the checkbox will do. I don't think it's possible to do this only using CSS. (Or rather, you can do rows but not columns.) But some optional JS could do it. Gerv From gerv at mozilla.org Thu Apr 12 22:40:59 2007 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 12 Apr 2007 23:40:59 +0100 Subject: UI for editing workflow In-Reply-To: References: <461E5F83.1000906@mozilla.org> Message-ID: <461EB57B.3040402@mozilla.org> Benton, Kevin wrote: > I think that taking it a bit further might be even better. Offering > users the ability to configure which statuses are possible versus those > that are not really helps. I think that we're missing the ability to > configure which statuses are open versus those that are closed. We do need this ability, but I think it is a function of the status itself, and so would be configured in the same UI where you create and remove statuses (rather than the one where you express their relationships). I imagine this UI will end up being very like the field editing UI we have now. > For 3.2, I think we ought to rename Resolution to Sub_Status or Reason, > then add a substatus table that includes the list of statuses and > possible sub-statuses. Basically, you are asking for status-dependent resolutions. I haven't seen any demand for this elsewhere... > This is critical when processes allow a DEFERRED > or PENDING status of sorts. For process management, it's important to > know why something is deferred, not just that it's deferred. Except that we killed REMIND and LATER because they sucked. IMO, the ideas of DEFERRED or PENDING should be implemented in a workflow using milestones. Right tool for the right job. Gerv From lpsolit at gmail.com Thu Apr 12 22:57:03 2007 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Fri, 13 Apr 2007 00:57:03 +0200 Subject: UI for editing workflow In-Reply-To: <461EB486.6080603@mozilla.org> References: <461E5F83.1000906@mozilla.org> <461E8399.8080204@mozilla.org> <461EB486.6080603@mozilla.org> Message-ID: <461EB93F.5000100@gmail.com> > We could enable the {Start} -> CLOSED transitions, but it would > complicate the enter_bug UI as it would need to provide the ability to > set them. I suggest that, in the rare case you mention, people content > themselves with a 2-step process. Note that enter_bug.cgi doesn't let you specify the resolution, and post_bug.cgi would ignore it anyway. I agree with gerv here, a 2-step process for such rare events isn't too much. LpSolit From kevin.benton at amd.com Thu Apr 12 23:18:32 2007 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 12 Apr 2007 16:18:32 -0700 Subject: UI for editing workflow In-Reply-To: <461EB57B.3040402@mozilla.org> References: <461E5F83.1000906@mozilla.org> <461EB57B.3040402@mozilla.org> Message-ID: > > For 3.2, I think we ought to rename Resolution to Sub_Status or Reason, > > then add a substatus table that includes the list of statuses and > > possible sub-statuses. > > Basically, you are asking for status-dependent resolutions. I haven't > seen any demand for this elsewhere... > > > This is critical when processes allow a DEFERRED > > or PENDING status of sorts. For process management, it's important to > > know why something is deferred, not just that it's deferred. > > Except that we killed REMIND and LATER because they sucked. IMO, the RESOLVED/REMIND to me makes absolutely no sense. RESOLVED/LATER is an oxymoron - we've resolved that we're going to fix it later? I agree that they did more to confuse than help. > ideas of DEFERRED or PENDING should be implemented in a workflow using > milestones. Right tool for the right job. As I see it, the problem is - how do you deal with it when the reason something is deferred is beyond your control (i.e. pending customer feedback)? What about when a deferment is due to verification (VDEFERRED) - that might make sense for milestones or deadlines, but it's helpful to be able to mark the bug as being in that deferred state because managers like to know what's really keeping us from reaching our goals today. At the same time, those managers want to know why something is deferred. The other thing that a deferred state does is it helps users sort through tasks more easily. When a bug is deferred for customer feedback, the engineer knows that he/she can either ignore the issue or wait for it to show up again on their stale bugs report (non-closed bugs that have gone 7 days without an update for example). That helps the engineer stay focused on what the engineer can work on versus what's out there that needs to be worked on. Items pending a future milestone may need some work now even though it's more than one milestone away. Using a pending state would indicate that the engineer can look at it once a week in the stale bug report. A non-pending open state would mean that the engineer has work to do on it now. Managers are asking "How long did it take to resolve that issue" without asking engineers to fill in the time tracking data. We used to do it in Remedy and we could do it in Bugzilla too with a little adjustment. Someone can correct me if I'm missing something in Bugzilla on how to accomplish this without documenting a sub status, but right now, I just don't see how to do that. Granted, Bugzilla was never intended to be a time management system, though it contains some aspects of that. Kevin Benton Senior Software Developer MSS Silicon Design Engineering Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From kevin.benton at amd.com Thu Apr 12 23:25:56 2007 From: kevin.benton at amd.com (Benton, Kevin) Date: Thu, 12 Apr 2007 16:25:56 -0700 Subject: UI for editing workflow In-Reply-To: <461EAD99.6000006@gmail.com> References: <461E5F83.1000906@mozilla.org> <461EAD99.6000006@gmail.com> Message-ID: > Benton, Kevin a ?crit : > > I think that we're missing the ability to > > configure which statuses are open versus those that are closed. > > Unrelated, really! This page is to configure the workflow itself, not to > edit the list of statuses. We already have editvalues.cgi for that. I'm just thinking out loud here, but I don't see why we have to separate the two. > > wonder if it wouldn't make sense to have a way to configure that list > > from this page as well. > > Definitely not! IMNSHO, I would rather edit them all in one page rather than having to flip back & forth, but that's me. > FYI, if everything goes well, custom statuses may be fully implemented > within 2-3 weeks (assuming reviewers and me have time to write/review > missing patches). Great news! :-) > PS: /me wonders why people keep pasting the whole email when replying. :) It's Outlook, really! :-) Actually, it takes a conscious effort to reformat emails like this. I would gladly use Thunderbird if Lightning actually worked (didn't remind me at the wrong time & date for my appointments), but we've digressed... Kevin Benton Senior Software Developer MSS Silicon Design Engineering Advanced Micro Devices The opinions stated in this communication do not necessarily reflect the view of Advanced Micro Devices and have not been reviewed by management. This communication may contain sensitive and/or confidential and/or proprietary information. Distribution of such information is strictly prohibited without prior consent of Advanced Micro Devices. This communication is for the intended recipient(s) only. If you have received this communication in error, please notify the sender, then destroy any remaining copies of this communication. From myk at mozilla.org Fri Apr 13 04:10:56 2007 From: myk at mozilla.org (Myk Melez) Date: Thu, 12 Apr 2007 21:10:56 -0700 Subject: UI for editing workflow In-Reply-To: <461EB93F.5000100@gmail.com> References: <461E5F83.1000906@mozilla.org> <461E8399.8080204@mozilla.org> <461EB486.6080603@mozilla.org> <461EB93F.5000100@gmail.com> Message-ID: <461F02D0.4040403@mozilla.org> Fr?d?ric Buclin wrote: >> We could enable the {Start} -> CLOSED transitions, but it would >> complicate the enter_bug UI as it would need to provide the ability >> to set them. I suggest that, in the rare case you mention, people >> content themselves with a 2-step process. > > Note that enter_bug.cgi doesn't let you specify the resolution, and > post_bug.cgi would ignore it anyway. I agree with gerv here, a 2-step > process for such rare events isn't too much. My guess is that it wouldn't be rare for those organizations that use it, but since we don't know of any yet, it's probably the right decision to hold off enabling these unless and until demand develops for them. -myk From gerv at mozilla.org Fri Apr 13 08:48:57 2007 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Apr 2007 09:48:57 +0100 Subject: UI for editing workflow In-Reply-To: References: <461E5F83.1000906@mozilla.org> <461EAD99.6000006@gmail.com> Message-ID: <461F43F9.5090901@mozilla.org> Benton, Kevin wrote: > I'm just thinking out loud here, but I don't see why we have to separate the two. I think that if someone were to decide to implement a new workflow, they would undoubtedly design it on paper first, perhaps starting with a printout of the old one. (We can't provide tools that are better for this task than paper is.) Once they'd done that, they need to implement it in Bugzilla. It seems reasonable to me that this implementation would or could consist of two stages - define the states you need, then define the transitions between those states. An advantage of this is that we already have UI that admins understand for defining lists of things like resolutions, priorities and so on. The reason not to do it all on one page is that a combined UI would be harder to understand than two separate UIs. Just looking at what you suggested - if you switch a state from being an open state to a closed state, what happens? Does it move from the top section to the bottom section, along with all its checkboxes? > Actually, it takes a conscious effort to reformat emails like this. I > would gladly use Thunderbird if Lightning actually worked (didn't remind > me at the wrong time & date for my appointments), but we've digressed... Are there no howtos on the web about making Outlook a better email citizen? Gerv From gerv at mozilla.org Fri Apr 13 08:54:05 2007 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 13 Apr 2007 09:54:05 +0100 Subject: UI for editing workflow In-Reply-To: References: <461E5F83.1000906@mozilla.org> <461EB57B.3040402@mozilla.org> Message-ID: <461F452D.6070903@mozilla.org> Benton, Kevin wrote: > As I see it, the problem is - how do you deal with it when the reason > something is deferred is beyond your control (i.e. pending customer > feedback)? I don't think it's all that helpful to get into a discussion about which particular workflows and states are good process and which are bad; after all, we are implementing a general mechanism so that people can shoot themselves in the foot if they so choose :-) But some thoughts: > What about when a deferment is due to verification > (VDEFERRED) - that might make sense for milestones or deadlines, but > it's helpful to be able to mark the bug as being in that deferred state > because managers like to know what's really keeping us from reaching our > goals today. In the current workflow, this state is RESOLVED - i.e. the state between a bug being fixed and it being VERIFIED. I don't consider this to be "deferred", unless any bug not being actively worked on at this very moment counts as "deferred". > At the same time, those managers want to know why > something is deferred. The other thing that a deferred state does is it > helps users sort through tasks more easily. When a bug is deferred for > customer feedback, a.k.a. NEEDINFO :-) You are using a very broad definition of the word "deferred". > the engineer knows that he/she can either ignore the > issue or wait for it to show up again on their stale bugs report > (non-closed bugs that have gone 7 days without an update for example). > That helps the engineer stay focused on what the engineer can work on > versus what's out there that needs to be worked on. Items pending a > future milestone may need some work now even though it's more than one > milestone away. Except that then they should be broken down into multiple related bugs, some targetted at the next milestone, others targetted at a later milestone. The absolute _meaning_ of "Milestone: Future" is "no one has to work on this now". If someone has to work on it, it's not Future. > Managers are asking "How long did it take to resolve that issue" without > asking engineers to fill in the time tracking data. We used to do it in > Remedy and we could do it in Bugzilla too with a little adjustment. Surely this is the time between being filed and being RESOLVED? No changes required. Gerv From lpsolit at gmail.com Thu Apr 19 18:58:53 2007 From: lpsolit at gmail.com (=?ISO-8859-1?Q?Fr=E9d=E9ric_Buclin?=) Date: Thu, 19 Apr 2007 20:58:53 +0200 Subject: Bugzilla 3.0 branch locked Message-ID: <4627BBED.2050708@gmail.com> Here we go. Remaining blockers for 3.0 final have been fixed. We are now running QA tests and we can expect a release next week, unless showstoppers are found meanwhile. This also means the End Of Life of Bugzilla 2.18 (there will be no 2.18.7 release). Those interested in QA can join us in #qa-bugzilla. If you find any critical bug while playing with 3.0 RC1 or 3.0 RC1+, hurry up and report your bug as soon as possible. Many thanks! :) LpSolit From myk at mozilla.org Thu Apr 26 21:26:31 2007 From: myk at mozilla.org (Myk Melez) Date: Thu, 26 Apr 2007 14:26:31 -0700 Subject: Bugzilla @ MySQL Conference - booth report Message-ID: <46311907.6040506@mozilla.org> Hey all, I'm back from the Bugzilla booth at the MySQL conference and thought I'd give a brief summary of my experience. Max and I staffed the booth and were there from 10-11am to 4-5pm both days of the exhibition (Tuesday and Wednesday), but neither of us was there for the evening reception on Tuesday. Traffic was fairly slow. I think I talked to perhaps two dozen people, and they were evenly spread throughout the days (i.e. there didn't seem to be rushes). The interactions can be grouped into roughly three categories: 1. Bugzilla is great. We use it at my organization. Thank you very much, and keep up the good work. (~6 folks) 2. My organization needs a bug tracking system, and I've heard about Bugzilla. Tell me more about it. (~12 folks) 3. We use Trac or something else instead of Bugzilla because Bugzilla is not written in PHP, its user interface sucks, or I couldn't get it installed. (~6 folks) In addition to these interactions, we sold five t-shirts at $15 apiece (which is roughly at-cost). Overall the experience was pleasant enough, and it was good to hear kind words (and get handshakes) from people who've really benefited from Bugzilla. I'm not sure it was worth the time spent, however. I suspect that the time I spent manning the booth would have been better spent doing reviews or the like. -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Fri Apr 27 10:41:37 2007 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 27 Apr 2007 11:41:37 +0100 Subject: Bugzilla @ MySQL Conference - booth report In-Reply-To: <46311907.6040506@mozilla.org> References: <46311907.6040506@mozilla.org> Message-ID: <4631D361.20308@mozilla.org> Myk Melez wrote: > 2. My organization needs a bug tracking system, and I've heard about > Bugzilla. Tell me more about it. (~12 folks) Do you feel that you had sufficient marketing collateral to inform them? ;-) > 3. We use Trac or something else instead of Bugzilla because Bugzilla > is not written in PHP, A legitimate point if all their engineers know PHP and they plan to customise their BTS. However, I assert that there's no point in attempting to win the business of such a customer. We won't get 100% of the market - but we aren't a monopolist, so we don't need to. > its user interface sucks, I know it's a small sample size, but did you ask if this was a recent viewpoint, or one they had got a few years ago? > or I couldn't get > it installed. (~6 folks) On the support list, I've been noticing most of the installation questions come from Windows users. Do other people sense that too? > I'm not sure it was worth the time spent, however. I suspect that the > time I spent manning the booth would have been better spent doing > reviews or the like. You may be right. I'm not sure the Bugzilla project gains overall by having its developers spend time on outreach. We won't grow the community sufficiently to offset the lost time and, even if it does grow, the lead time on those new members becoming helpful developers would be long. Gerv From myk at mozilla.org Fri Apr 27 15:01:40 2007 From: myk at mozilla.org (Myk Melez) Date: Fri, 27 Apr 2007 08:01:40 -0700 Subject: Bugzilla @ MySQL Conference - booth report In-Reply-To: <4631D361.20308@mozilla.org> References: <46311907.6040506@mozilla.org> <4631D361.20308@mozilla.org> Message-ID: <46321054.9090907@mozilla.org> Gervase Markham wrote: > Do you feel that you had sufficient marketing collateral to inform them? ;-) > I could probably have had a more polished presentation, but I know enough about Bugzilla to talk them through its salient features. > A legitimate point if all their engineers know PHP and they plan to > customise their BTS. However, I assert that there's no point in > attempting to win the business of such a customer. We won't get 100% of > the market - but we aren't a monopolist, so we don't need to. > Agreed. > I know it's a small sample size, but did you ask if this was a recent > viewpoint, or one they had got a few years ago? > I didn't ask. > On the support list, I've been noticing most of the installation > questions come from Windows users. Do other people sense that too? > Not sure, but only one person mentioned installing Bugzilla on Windows, and that person wasn't one of the ones that talked about it being hard to install. Actually, the one guy who specifically said that he couldn't get it installed and eventually used Trac instead was installing it on Mac OS X. > You may be right. I'm not sure the Bugzilla project gains overall by > having its developers spend time on outreach. We won't grow the > community sufficiently to offset the lost time and, even if it does > grow, the lead time on those new members becoming helpful developers > would be long. > FWIW, I spoke to one person whom I felt might install Bugzilla and then quickly become a contributor. -myk From mkanat at bugzilla.org Fri Apr 27 19:39:24 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 27 Apr 2007 12:39:24 -0700 Subject: Bugzilla @ MySQL Conference - booth report In-Reply-To: <4631D361.20308@mozilla.org> References: <46311907.6040506@mozilla.org> <4631D361.20308@mozilla.org> Message-ID: <20070427194032.6171F8C8001@help.trusthosting.net> On Fri, 27 Apr 2007 11:41:37 +0100 Gervase Markham wrote: > I know it's a small sample size, but did you ask if this was a recent > viewpoint, or one they had got a few years ago? Most people with complaints hadn't used Bugzilla in a long time, since before 2.18. > On the support list, I've been noticing most of the installation > questions come from Windows users. Do other people sense that too? Yes, and that's mostly because we come from a Linux background. That is, to us it's natural to install a bunch of dependencies like MySQL, Apache, and perl, because those will probably already be on our systems anyway and if they're not, they're available through the package manager. On Windows, though, you have to install everything yourself, and although that process is something a Windows user is used to, they're not necessarily used to the command line and text-file configuration. Also, we require an SMTP server on Windows, and we don't support SMTP Auth. So that causes a lot more support questions. > You may be right. I'm not sure the Bugzilla project gains overall by > having its developers spend time on outreach. We won't grow the > community sufficiently to offset the lost time and, even if it does > grow, the lead time on those new members becoming helpful developers > would be long. I think it could be worth it at a larger conference like OSCON, where there are lots of people to talk to. MySQLConf was a very small, very slow conference. (The focus seemed to be the sessions, not really the Exhibit Hall.) Also, with the size of our team, even ONE extra contributor for two days of sitting around at a booth would be worth it. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From jochen.wiedmann at gmail.com Fri Apr 27 19:43:29 2007 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Fri, 27 Apr 2007 21:43:29 +0200 Subject: Bugzilla @ MySQL Conference - booth report In-Reply-To: <20070427194032.6171F8C8001@help.trusthosting.net> References: <46311907.6040506@mozilla.org> <4631D361.20308@mozilla.org> <20070427194032.6171F8C8001@help.trusthosting.net> Message-ID: On 4/27/07, Max Kanat-Alexander wrote: > Yes, and that's mostly because we come from a Linux background. > That is, to us it's natural to install a bunch of dependencies like > MySQL, Apache, and perl, because those will probably already be on our > systems anyway and if they're not, they're available through the > package manager. That used to be true. IMO, it is no longer the case with 3.0. Fetching and installing all those thousands of mail related modules to a machine without Internet access was a true night mare. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. From myk at mozilla.org Fri Apr 27 19:46:37 2007 From: myk at mozilla.org (Myk Melez) Date: Fri, 27 Apr 2007 12:46:37 -0700 Subject: Bugzilla @ MySQL Conference - booth report In-Reply-To: <46321054.9090907@mozilla.org> References: <46311907.6040506@mozilla.org> <4631D361.20308@mozilla.org> <46321054.9090907@mozilla.org> Message-ID: <4632531D.6090804@mozilla.org> Myk Melez wrote: > Gervase Markham wrote: >> I know it's a small sample size, but did you ask if this was a recent >> viewpoint, or one they had got a few years ago? >> > I didn't ask. But I'll note that the person who most stridently made this case said Bugzilla was too hard to use for his marketing team, who have become "spoiled" by interfaces like Basecamp's. -myk From mkanat at bugzilla.org Fri Apr 27 20:19:21 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 27 Apr 2007 13:19:21 -0700 Subject: Bugzilla @ MySQL Conference - booth report In-Reply-To: References: <46311907.6040506@mozilla.org> <4631D361.20308@mozilla.org> <20070427194032.6171F8C8001@help.trusthosting.net> Message-ID: <20070427202029.AA2618C8001@help.trusthosting.net> On Fri, 27 Apr 2007 21:43:29 +0200 "Jochen Wiedmann" wrote: > That used to be true. IMO, it is no longer the case with 3.0. Fetching > and installing all those thousands of mail related modules to a > machine without Internet access was a true night mare. Yes. That should become easier once those particular perl modules are packaged by each distro. They're already available through RPMForge for CentOS and RHEL. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From myk at mozilla.org Fri Apr 27 20:22:50 2007 From: myk at mozilla.org (Myk Melez) Date: Fri, 27 Apr 2007 13:22:50 -0700 Subject: Bugzilla @ MySQL Conference - booth report In-Reply-To: <20070427202029.AA2618C8001@help.trusthosting.net> References: <46311907.6040506@mozilla.org> <4631D361.20308@mozilla.org> <20070427194032.6171F8C8001@help.trusthosting.net> <20070427202029.AA2618C8001@help.trusthosting.net> Message-ID: <46325B9A.8040507@mozilla.org> Max Kanat-Alexander wrote: > On Fri, 27 Apr 2007 21:43:29 +0200 "Jochen Wiedmann" > wrote: > >> That used to be true. IMO, it is no longer the case with 3.0. Fetching >> and installing all those thousands of mail related modules to a >> machine without Internet access was a true night mare. >> > > Yes. That should become easier once those particular perl > modules are packaged by each distro. They're already available through > RPMForge for CentOS and RHEL. > I wonder if it would be useful to provide a bundle of these modules that one can drop into one's Bugzilla root directory for folks who don't have root access to add modules (or for whom doing so is troublesome). -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen.wiedmann at gmail.com Fri Apr 27 20:24:37 2007 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Fri, 27 Apr 2007 22:24:37 +0200 Subject: Bugzilla @ MySQL Conference - booth report In-Reply-To: <46325B9A.8040507@mozilla.org> References: <46311907.6040506@mozilla.org> <4631D361.20308@mozilla.org> <20070427194032.6171F8C8001@help.trusthosting.net> <20070427202029.AA2618C8001@help.trusthosting.net> <46325B9A.8040507@mozilla.org> Message-ID: On 4/27/07, Myk Melez wrote: > I wonder if it would be useful to provide a bundle of these modules that > one can drop into one's Bugzilla root directory for folks who don't have > root access to add modules (or for whom doing so is troublesome). Yes, that would be really helpful. The obvious problem is maintenance, though. Jochen -- My cats know that I am a loser who goes out for hunting every day without ever returning as much as a single mouse. Fortunately, I've got a wife who's a real champ: She leaves the house and returns within half an hour, carrying whole bags full of meal. From mkanat at bugzilla.org Fri Apr 27 20:29:16 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 27 Apr 2007 13:29:16 -0700 Subject: Bugzilla @ MySQL Conference - booth report In-Reply-To: <46325B9A.8040507@mozilla.org> References: <46311907.6040506@mozilla.org> <4631D361.20308@mozilla.org> <20070427194032.6171F8C8001@help.trusthosting.net> <20070427202029.AA2618C8001@help.trusthosting.net> <46325B9A.8040507@mozilla.org> Message-ID: <20070427203024.B8CFA8C8001@help.trusthosting.net> On Fri, 27 Apr 2007 13:22:50 -0700 Myk Melez wrote: > I wonder if it would be useful to provide a bundle of these modules > that one can drop into one's Bugzilla root directory for folks who > don't have root access to add modules (or for whom doing so is > troublesome). Some of them have C components that must be compiled, so we couldn't ship those. Otherwise I could easily generate such a bundle, since I already have code for 3.2 that can install all of the modules into the Bugzilla directory. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From myk at mozilla.org Fri Apr 27 20:30:43 2007 From: myk at mozilla.org (Myk Melez) Date: Fri, 27 Apr 2007 13:30:43 -0700 Subject: Bugzilla @ MySQL Conference - booth report In-Reply-To: <20070427203024.B8CFA8C8001@help.trusthosting.net> References: <46311907.6040506@mozilla.org> <4631D361.20308@mozilla.org> <20070427194032.6171F8C8001@help.trusthosting.net> <20070427202029.AA2618C8001@help.trusthosting.net> <46325B9A.8040507@mozilla.org> <20070427203024.B8CFA8C8001@help.trusthosting.net> Message-ID: <46325D73.1090502@mozilla.org> Max Kanat-Alexander wrote: > On Fri, 27 Apr 2007 13:22:50 -0700 Myk Melez wrote: > >> I wonder if it would be useful to provide a bundle of these modules >> that one can drop into one's Bugzilla root directory for folks who >> don't have root access to add modules (or for whom doing so is >> troublesome). >> > > Some of them have C components that must be compiled, so we > couldn't ship those. > Are any of these in the "required modules" list? Could we ship them as source packages that we automatically compile before installing? -myk -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkanat at bugzilla.org Fri Apr 27 20:33:52 2007 From: mkanat at bugzilla.org (Max Kanat-Alexander) Date: Fri, 27 Apr 2007 13:33:52 -0700 Subject: Bugzilla @ MySQL Conference - booth report In-Reply-To: <46325D73.1090502@mozilla.org> References: <46311907.6040506@mozilla.org> <4631D361.20308@mozilla.org> <20070427194032.6171F8C8001@help.trusthosting.net> <20070427202029.AA2618C8001@help.trusthosting.net> <46325B9A.8040507@mozilla.org> <20070427203024.B8CFA8C8001@help.trusthosting.net> <46325D73.1090502@mozilla.org> Message-ID: <20070427203500.CB0F58C8001@help.trusthosting.net> On Fri, 27 Apr 2007 13:30:43 -0700 Myk Melez wrote: > Are any of these in the "required modules" list? Could we ship them > as source packages that we automatically compile before installing? Yeah, possibly. We could ship two packages, one with all modules pre-installed and one that's just Bugzilla. This could be a good idea. -Max -- http://www.everythingsolved.com/ Competent, Friendly Bugzilla Services. And Everything Else, too. From bugzilla at glob.com.au Mon Apr 30 00:40:02 2007 From: bugzilla at glob.com.au (byron) Date: Mon, 30 Apr 2007 08:40:02 +0800 Subject: Bugzilla @ MySQL Conference - booth report In-Reply-To: <20070427194032.6171F8C8001@help.trusthosting.net> References: <46311907.6040506@mozilla.org> <4631D361.20308@mozilla.org> <20070427194032.6171F8C8001@help.trusthosting.net> Message-ID: <20070430004002.GA10529@bur.st> > > On the support list, I've been noticing most of the installation > > questions come from Windows users. Do other people sense that too? > > Yes, and that's mostly because we come from a Linux background. > That is, to us it's natural to install a bunch of dependencies like > MySQL, Apache, and perl, because those will probably already be on our > systems anyway and if they're not, they're available through the > package manager. agreed; windows users are used to a simple wizard based installer. this won't be possible with bugzilla due to licensing restrictions - you can't redistribute mysql unless it's packaged with a GPL product. i guess it would be possible to create an gui based installer for windows that prompted you at the appropiate times, and shelled out to install the required modules as required... a stub installer that downloaded the latest versions as required. my only concern about that would be the ongoing support required to maintain it. -byron begin-base64 644 signature.gif R0lGODlhbQAHAIAAAABPo////ywAAAAAbQAHAAACfAxuGAnch+Bibkn7FL1p XgVl4Ig1jjlZRoqybgun2Cur5uOunq7u/Ipq7WIyIc7XG9JquEgumPzdlhTf h0O83kDJaXEm8mRHwXKJy5sac7qYOpT+gtv0n+0ujQOfdqh16caWt0foBViH N1PRMXimiLUGt3ElVimlgbllWAAAOw== From dwilliss at microimages.com Mon Apr 30 19:24:17 2007 From: dwilliss at microimages.com (Dave Williss) Date: Mon, 30 Apr 2007 14:24:17 -0500 Subject: Perl Modules [was: Bugzilla @ MySQL Conference - booth report] In-Reply-To: References: <46311907.6040506@mozilla.org> <4631D361.20308@mozilla.org> <20070427194032.6171F8C8001@help.trusthosting.net> Message-ID: <46364261.7030601@microimages.com> Jochen Wiedmann wrote: > On 4/27/07, Max Kanat-Alexander wrote: > >> Yes, and that's mostly because we come from a Linux background. >> That is, to us it's natural to install a bunch of dependencies like >> MySQL, Apache, and perl, because those will probably already be on our >> systems anyway and if they're not, they're available through the >> package manager. > > That used to be true. IMO, it is no longer the case with 3.0. Fetching > and installing all those thousands of mail related modules to a > machine without Internet access was a true night mare. I know this was a hassle for us. Our bugzilla is on a private LAN which is physically isolated from the Internet. As far as distros eventually coming with the packages installed: this may be true, but you can't expect that somebody setting up bugzilla (or upgrading it) is going to install a new OS just so they have all the standard modules. I expect the next time we upgrade to the next version of Bugzilla that there will be some new Perl module that we don't have on that machine. I would like to see either a single .tar.gz that can be downloaded with Bugzilla which has the latest versions of all the Perl modules it depends on, or a page which lists the ones needed with links to the CPAN download site for each one. At least that way, they're all in one place and easy to find. I do like that the check setup script tells you up front all the modules you're missing. For comparison, I was trying to build the latest version of Gnome this weekend, and every 15 min it stopped and told me I needed a new version of Python or ImageMagick or some library I'd never even heard of. From justdave at bugzilla.org Mon Apr 30 22:54:25 2007 From: justdave at bugzilla.org (David Miller) Date: Mon, 30 Apr 2007 18:54:25 -0400 Subject: Perl Modules [was: Bugzilla @ MySQL Conference - booth report] In-Reply-To: <46364261.7030601@microimages.com> References: <46311907.6040506@mozilla.org> <4631D361.20308@mozilla.org> <20070427194032.6171F8C8001@help.trusthosting.net> <46364261.7030601@microimages.com> Message-ID: <463673A1.1090600@bugzilla.org> Dave Williss wrote on 4/30/07 3:24 PM: > I would like to see either a single .tar.gz that can be downloaded with > Bugzilla which has the latest versions of all the Perl modules it > depends on, or a page which lists the ones needed with links to the CPAN > download site for each one. At least that way, they're all in one place > and easy to find. Someone already posted a page like this for Ubuntu packages on the wiki... I just renamed and expanded on the page to include other distributions and CPAN, though it's still a bit incomplete. If anyone wants to fill in the blanks before I get a chance to get back to it, feel free. :) http://wiki.mozilla.org/Bugzilla:Prerequisites -- Dave Miller http://www.justdave.net/ System Administrator, Mozilla Corporation http://www.mozilla.com/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/