. I'm about to attach a new patch that implements this idea. Sticking with a table here makes things work better for less capable browers, IMHO. The single table can easily be replaced by a div later. I also cleaned up the id names and removed all reference to my choose-product patch, in which the class names were poorly thought out. Cory 'G' Watson "The universal aptitude for ineptitude makes any human accomplishment an incredible miracle." - Dr. John Paul Stapp From jay at veggiespam.com Sat Dec 6 19:45:23 2003 From: jay at veggiespam.com (jay ball) Date: Sat, 6 Dec 2003 14:45:23 -0500 Subject: Bug 69654 In-Reply-To: <1531AACE-2821-11D8-8D60-0003939CCA58@cafes.net> References: <20031206123324.GA854@async.com.br> <1531AACE-2821-11D8-8D60-0003939CCA58@cafes.net> Message-ID: i'm happy that bugzilla is adding CSS support. it'll make customization to corporate colours much easier. heck, you can even client side change the style sheet on the fly, so we can have a "print me" button at the top which load a plain, small font, tree wasting css file. CSS will also allow for future fun, like hidden HTML (which will be non-hidden on NS4 and lynx automatically). we can hide all of the advanced options on the search page and the user clicks on "advanced" and they magically appear. all slick, easily implemented, enterprise desired beautiful functions. I suggest a quick glance at http://www.alistapart.com/articles/slashdot/ . This was somebody's attempt at removing all of the customized hacky HTML 3.2 code from a slashcode page and replacing it with a fully CSS aware page which looks exactly the same. The author remove most of the tables - even using

instead in places that i would have never thought, like the header of images. He also gives a walk though of how he did it all of it, with the interim web pages. It'd be an excellent skim if you're leery of changing the bugzilla pages and might help us avoid pitfalls that he encountered. there is also a nice side effect to using CSS - lower bandwidth. in the slashdot example, it was 9k per page request. i don't know what b.m.o's costs are per month, but that might help push for a CSS change. -j From jth at mikrobitti.fi Sat Dec 6 22:13:38 2003 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Sun, 07 Dec 2003 00:13:38 +0200 Subject: Bug 69654 In-Reply-To: <20031206123324.GA854@async.com.br> Message-ID: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> At 10:33 6.12.2003 -0200, you wrote: >I actually like the direction the patch is going. Any patch enhancing CSS support is a step in the right direction. Most of the issues I raised in the bug are relatively small things; the important ingredient is that we have people ready to work for this. Kiko described my last comment in 69654 as "apocalyptic" - didn't mean to sound that bad :-) Right now, I suggest we stop posting patches to 69654 and file new bugs (to keep 69654 as a meta bug). The banner stuff already posted on the bug is an excellent start. Then, we should discuss the main issues with BZ CSSification here, so that we're at least aware of all the problems, even if we can't find the solutions for all of them. Although this will probably get messy, here are some ideas on various issues (sorry, it's rather long, and my brain is already nigh-asleep): >As for the

/

issue, I can accept your rationale for having the >organization's identification up there. So we would have, for a sample >query.cgi, contrasting vanilla bugzilla with a pseudo-branded bugzilla: >

Bugzilla Main Page Gozilla.org: Family-Approved Sprockets >

Bugzilla Version XXX Bug Tracking (Bugzilla XXX) >

Search for bugs Search for bugs > (free) (free) This Hx organization is a hard one. For me, the intuitive solution is to have the whole banner as an H1. Now, you can argue that "Bugzilla version xxx" is really a subheading and the version text is only a placeholder. However, we can also approach this the other way around. The page headings don't have to reflect real world relationships totally: a company with divisions and country-level units would hardly format (or even mentally think about) their web pages with heading hierarchies like h1: Megacorp Ltd h2: European division h3: Finnish unit h4: Press information More likely, this would be reduced to a h1 "Megacorp Ltd, Europe / Finland" and a "Press information" h2. I don't see a problem with "Gozilla.org Bug tracking tool v2.17" being the semantic "first-level heading". The fact that it's all marked up as h1 is fine with me; people can customize different parts of h1's to look different. The ugly but trivial example is
Acne Corp - fleshing out your face
. There is also the point of possible repetition of a certain heading level. It doesn't sound too good to have levels H1-H3 fixed to be once per page only, because then we're left with pretty few usable levels. H5 and H6 have horrible default renderings (sometimes smaller than body text, and non-graphic browsers have a hard time separating them from higher heading levels), so it would probably be good to stick to first four levels as much as we can. So, >For request.cgi: > >
Bugzilla Main Page Gozilla.org: Family-Approved Sprockets >
Bugzilla Version XXX Bug Tracking (Bugzilla XXX) >
Request Queue Request Queue >
Flag: approval Flag: whatever > Flag: review Flag: hassle > (free) (free) I'd go for
Gozilla.org bug tracking (Bugzilla XXX)
Request Queue
Flag: approval (free) >
Bugzilla Bug YYY Bug YYY > > ui: need more electrons ui: need more electrons > > changed 2003-08-31 changed 2003-08-31 > (free) (free) Now, what's the point of having a semantic markup and then slipping with stuff like "subheading" and "subsubheading"? (you probably mean class instead of id anyway) Or maybe the names of the classes were just badly selected? They should probably be something natural such as "bugsummary", right? >I'm not 100% those subheading spans shouldn't be divs, so we can quibble >over that if people like. This is a can of worms, but we don't probably have to care. Majority of the most useful CSS rules are applicable for both blocks and inlines, and you can always customize with display: block/inline. The correct default simply comes from our needs wrt the default layout. For the most part, it's probably going to be div for separately positioned elements. Moving on from the Hx issue, we have the question on naming CSS classes. It's been suggested that all classes should start with bz_ to avoid namespace collisions. Theoretically I agree, but are there any namespace collisions to avoid in practice? Should we care? Having a prefix makes things more awkward to use. In what sort of case could somebody reasonably mix non-Bugzilla style sheets into this? Maybe if you have a site-wide element that you want to copy into Bugzilla, but then you're best off by giving your separate element an id and forming all CSS rules with syntax like "#commonlogobanner .email { blah }" to force rule containment. Then there is the capitalization and naming style issue. "requestHeading", "RequestHeading", "request_heading" or what? Underscores have been formally allowed for class names for some time now, but may cause problems with really old browsers. This is probably a non-issue since our current styles have underscores as well, and we haven't heard many complaints. I prefer names like "requestHeading", but anything goes. Indentation is related; I prefer 2 spaces as already done in HTML templates. Classically, pixels and percentages don't mix. To some extent, mixing relative and absolute units still causes pain - mostly with IE, whose font scaling bugs are worth a volume in themselves. It's a lot easier to use fixed font sizes like "13px" and "17px", but that may not be in the best interest of the user. Does anyone have a strong opinion on this? NS 4 support: I'd say let's hide all CSS from NS4 and strive to keep our markup as semantically valid as possible. That will leave pages readable, but it probably will drastically change the look of some pages (show_bug mostly) in the course of time. Excluding NS4 will cut down development time a lot. Should we, during the transition to CSS, aim for a strict doctype? This is a relevant question, as rendering mode changes particularly on IE6 causes interesting issues when changing the doctype. Most important of these issues is the different calculation of box width wrt paddings and margins. I'd consider moving towards strict, although it's a real strain with some things. Should we aim for lots of classes and simple selectors (.queryform_cclist_checkbox) or fewer classes and more hierarchical selectors (#queryform #cclist input.checkbox)? I prefer the more hierarchical model, but it will take some effort in the design phase. CSS files end up lot more readable though. Multiclassing HTML elements is a related issue, but it's perhaps not the time to start that discussion here (especially if we end up excluding NS4 anyway). What's our attitude towards CSS2 selector stuff? Selectors like |input[type=checkbox]| aren't really supported that well, but they possibly will be in the future. Currently, using advanced CSS2 selectors would probably make Bugzilla look better on Mozilla than on IE. This may or may not be a problem. I don't know; I'm not too keen to rush into CSS2 stuff just yet. And then there is the questions of splitting the CSS rules physically across files. I believe layout-heavy pages such as the query form should have their own CSS files. This may prove tricky, though, as the query form is a separate template and the included CSS files must be known at the start of page; it's not sufficient to code the CSS file requirements to specific templates, but they also need to be governed from the cgi's calling the header template. This is a strong point for a single-file approach (or more specifically, an approach where the same set of css rules is imported for every Bugzilla page). All right, those are some questions and thoughts on them. Stuff like setting fonts and colors with CSS are relatively easy to do once some of those basic decisions are made. CSS layout is of course going to be much harder and require much more thought. All discussion is warmly welcomed :-) Jouni From gerv at mozilla.org Sun Dec 7 16:58:36 2003 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 07 Dec 2003 16:58:36 +0000 Subject: Bug 69654 In-Reply-To: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> Message-ID: <3FD35C3C.8010403@mozilla.org> Jouni Heikniemi wrote: > Any patch enhancing CSS support is a step in the right direction. Indeed; but Jouni is right. When we started doing templates, Myk and I had a very good understanding about how we wanted them coded. The result of that is that most of the templates are very consistent in style and approach. This is a big bonus. We could do with the same thing for CSS. Ideally, one person would sit down, think through all the issues and come up with a proposal, rather than doing it inch-by-inch on this list. This would include conventions for naming classes, how we split up the CSS for each page, and what CSS we should use and not use, based on current browser support. More specific comments: > This Hx organization is a hard one. For me, the intuitive solution is to > have the whole banner as an H1. Before we went with "This is Bugzilla", the banner was an image. I think it's far from certain that whatever a customiser replaces it with will be text. I feel that this is a poor use of H1. Imagine a screen reader. "What's this page about?", asks the blind user. "This is Bugzilla", replies the reader, when it should really be replying "Bug 12345" or "Search for bugs". > Now, you can argue that "Bugzilla > version xxx" is really a subheading and the version text is only a > placeholder. The version text isn't a heading either, it's sort of a colophon. It's an annotation, not an important part of the semantic structure of the page. > Moving on from the Hx issue, we have the question on naming CSS classes. > It's been suggested that all classes should start with bz_ to avoid > namespace collisions. Theoretically I agree, but are there any namespace > collisions to avoid in practice? Should we care? Having a prefix makes > things more awkward to use. Indeed. The only possible reason is user stylesheets - and we can namespace those by having a id="bugzilla" on the element. > Indentation is related; I prefer 2 spaces as already done in HTML > templates. Sounds good. > Classically, pixels and percentages don't mix. To some extent, mixing > relative and absolute units still causes pain - mostly with IE, whose > font scaling bugs are worth a volume in themselves. It's a lot easier to > use fixed font sizes like "13px" and "17px", but that may not be in the > best interest of the user. Does anyone have a strong opinion on this? We've just been round this block with the new www.mozilla.org website. Ideally, we wouldn't scale the user's font size at all. > Should we, during the transition to CSS, aim for a strict doctype? This > is a relevant question, as rendering mode changes particularly on IE6 > causes interesting issues when changing the doctype. Most important of > these issues is the different calculation of box width wrt paddings and > margins. I'd consider moving towards strict, although it's a real strain > with some things. What's the benefit of Strict? > What's our attitude towards CSS2 selector stuff? Selectors like > |input[type=checkbox]| aren't really supported that well, but they > possibly will be in the future. Currently, using advanced CSS2 selectors > would probably make Bugzilla look better on Mozilla than on IE. This may > or may not be a problem. I don't know; I'm not too keen to rush into > CSS2 stuff just yet. My view is IE5.0+, Mozilla1.0+, recent Opera, Safari 1.0 (inc. Konqueror) and Lynx. > And then there is the questions of splitting the CSS rules physically > across files. I believe layout-heavy pages such as the query form should > have their own CSS files. This may prove tricky, though, as the query > form is a separate template and the included CSS files must be known at > the start of page; Normally, there's a "wrapper" page which includes the fragments it wants to make up the compound page; it will just have to make sure it also includes the relevant css files. > it's not sufficient to code the CSS file requirements > to specific templates, but they also need to be governed from the cgi's > calling the header template. This is a strong point for a single-file > approach (or more specifically, an approach where the same set of css > rules is imported for every Bugzilla page). I'm not so keen on a single file, just from a maintainability perspective. If you have some odd CSS interaction, would you rather look through 20 rules to see what's weird, or 200? Gerv From gphat at loggerithim.org Sun Dec 7 19:47:18 2003 From: gphat at loggerithim.org (Cory 'G' Watson) Date: Sun, 7 Dec 2003 13:47:18 -0600 Subject: Bug 69654 In-Reply-To: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> Message-ID: <2A3D3E91-28EE-11D8-9492-0003939CCA58@loggerithim.org> On Dec 6, 2003, at 4:13 PM, Jouni Heikniemi wrote: > At 10:33 6.12.2003 -0200, you wrote: > Any patch enhancing CSS support is a step in the right direction. Most > of the issues I raised in the bug are relatively small things; the > important ingredient is that we have people ready to work for this. > Kiko described my last comment in 69654 as "apocalyptic" - didn't mean > to sound that bad :-) I think it sounds just fine. The benefit of this open development crap is that we get lots of eyes. I get caught up in the actual modification and start giving my styles bad names, and you help me catch them. ;) You also bring up lots of good choices that need to be made. > Right now, I suggest we stop posting patches to 69654 and file new > bugs (to keep 69654 as a meta bug). The banner stuff already posted on > the bug is an excellent start. Then, we should discuss the main > issues with BZ CSSification here, so that we're at least aware of all > the problems, even if we can't find the solutions for all of them. Absolutely. > Now, what's the point of having a semantic markup and then slipping > with stuff like "subheading" and "subsubheading"? (you probably mean > class instead of id anyway) Or maybe the names of the classes were > just badly selected? They should probably be something natural such as > "bugsummary", right? But that is not always a 'bugsummary', just like it's not 'rightAligned' (from a your patch comment). I'm not big on using all through the document, I'd prefer to break the page up with
s, but that's just MHO. I'm pretty happy with my latest patch. > This is a can of worms, but we don't probably have to care. Majority > of the most useful CSS rules are applicable for both blocks and > inlines, and you can always customize with display: block/inline. The > correct default simply comes from our needs wrt the default layout. > For the most part, it's probably going to be div for separately > positioned elements. The problem with changing blocks to inlines is that things look different in older browsers. > > Then there is the capitalization and naming style issue. > "requestHeading", "RequestHeading", "request_heading" or what? > Underscores have been formally allowed for class names for some time > now, but may cause problems with really old browsers. This is probably > a non-issue since our current styles have underscores as well, and we > haven't heard many complaints. I prefer names like "requestHeading", > but anything goes. I'm a studlyCaps guy when it comes to CSS names. > Indentation is related; I prefer 2 spaces as already done in HTML > templates. I'm a tab guy in CSS, since it's separate code. I'm not married to it, however. > > Classically, pixels and percentages don't mix. To some extent, mixing > relative and absolute units still causes pain - mostly with IE, whose > font scaling bugs are worth a volume in themselves. It's a lot easier > to use fixed font sizes like "13px" and "17px", but that may not be in > the best interest of the user. Does anyone have a strong opinion on > this? Not I. > > NS 4 support: I'd say let's hide all CSS from NS4 and strive to keep > our markup as semantically valid as possible. That will leave pages > readable, but it probably will drastically change the look of some > pages (show_bug mostly) in the course of time. Excluding NS4 will cut > down development time a lot. Yes. ;) > Should we, during the transition to CSS, aim for a strict doctype? > This is a relevant question, as rendering mode changes particularly on > IE6 causes interesting issues when changing the doctype. Most > important of these issues is the different calculation of box width > wrt paddings and margins. I'd consider moving towards strict, although > it's a real strain with some things. I would prefer to do that. > Should we aim for lots of classes and simple selectors > (.queryform_cclist_checkbox) or fewer classes and more hierarchical > selectors (#queryform #cclist input.checkbox)? I prefer the more > hierarchical model, but it will take some effort in the design phase. > CSS files end up lot more readable though. Multiclassing HTML elements > is a related issue, but it's perhaps not the time to start that > discussion here (especially if we end up excluding NS4 anyway). I prefer hierarchical, but as you point out, it requires alot more thought up front. My problem is that I do not know bugzilla's innards very well, and I tend to do such work iteratively. We may have to rework existing styles on the third of fourth template into the work because of some Epiphany of Elegance (my term for coming up with a much nicer way to get the same results in HTML/CSS). > What's our attitude towards CSS2 selector stuff? Selectors like > |input[type=checkbox]| aren't really supported that well, but they > possibly will be in the future. Currently, using advanced CSS2 > selectors would probably make Bugzilla look better on Mozilla than on > IE. This may or may not be a problem. I don't know; I'm not too keen > to rush into CSS2 stuff just yet. Me either. > And then there is the questions of splitting the CSS rules physically > across files. I believe layout-heavy pages such as the query form > should have their own CSS files. This may prove tricky, though, as the > query form is a separate template and the included CSS files must be > known at the start of page; it's not sufficient to code the CSS file > requirements to specific templates, but they also need to be governed > from the cgi's calling the header template. This is a strong point for > a single-file approach (or more specifically, an approach where the > same set of css rules is imported for every Bugzilla page). If we go as hierarchical as possible, I think we can stick with a single file. > > All right, those are some questions and thoughts on them. Stuff like > setting fonts and colors with CSS are relatively easy to do once some > of those basic decisions are made. CSS layout is of course going to be > much harder and require much more thought. All discussion is warmly > welcomed :-) Yes, the actual work will be easy once the details are pounded into a fine grit ;) Cory 'G' Watson "The universal aptitude for ineptitude makes any human accomplishment an incredible miracle." - Dr. John Paul Stapp From jth at mikrobitti.fi Sun Dec 7 20:28:25 2003 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Sun, 7 Dec 2003 22:28:25 +0200 (EET) Subject: Bug 69654 In-Reply-To: <3FD35C3C.8010403@mozilla.org> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> Message-ID: On Sun, 7 Dec 2003, Gervase Markham wrote: > We could do with the same thing for CSS. Ideally, one person would sit > down, think through all the issues and come up with a proposal, rather > than doing it inch-by-inch on this list. Let's hope there will be a moment when a capable person will have both the sufficient information and the time to do this. I think throwing some ideas around first is a good idea, though. > Imagine a screen reader. "What's this page about?", asks the blind user. > "This is Bugzilla", replies the reader, when it should really be > replying "Bug 12345" or "Search for bugs". Actually, while what you say is true, I disagree. If you click a link on some page and end up on something called "Bug 34567", you're pretty much baffled. While it's true that when navigating inside Bugzilla the first really interesting heading is the page title, I still don't think we can skip the heading describing the particular installation. Screen readers have all sorts of problems, and we're not going to be able to solve all of them here. At this point, I feel that having a meaningful page outline (auto-constructed from the Hx elements) is the best we can do. An H1 of "bugzilla.mozilla.org: Bug reporting system for Mozilla and related products" and a H2 of "Bug 23134: Yadda yadda" is pretty good in this sense. > We've just been round this block with the new www.mozilla.org website. > Ideally, we wouldn't scale the user's font size at all. Or, more practically speaking, we should at least avoid scaling the default body font (fine-tuning heading sizes et al is usually more acceptable). It's very easy to convince me to that, but people usually view the default font sizes as way too large. This is not too bad with serif fonts, though; Arial and especially Verdana suffer from this far more. > > Should we, during the transition to CSS, aim for a strict doctype? This > What's the benefit of Strict? Apart from the concept of "The Right Thing" (which is arguable, sure), strict doctype tends to eliminate quirk modes, thus giving us less hassle with misinterpretations of certain rules. Take a look at for a small sample of what I'm talking about. > > And then there is the questions of splitting the CSS rules physically > > across files. I believe layout-heavy pages such as the query form should > > have their own CSS files. This may prove tricky, though, as the query > > form is a separate template and the included CSS files must be known at > > the start of page; > Normally, there's a "wrapper" page which includes the fragments it wants > to make up the compound page; it will just have to make sure it also > includes the relevant css files. The problem here is that it's potentially hard for the wrapper pages to know all required css file references. It takes quite a bit of work to figure out which style sheets could be necessary in all possible parameter combinations. For example, if some new popup-based UI feature gets checked in and used in several pages (like our current user selector), it can be potentially hard for all pages to include exactly the proper combination of css files. > I'm not so keen on a single file, just from a maintainability > perspective. If you have some odd CSS interaction, would you rather look > through 20 rules to see what's weird, or 200? 20, of course. But if it's 200 in ten files or 200 in a single file, the difference isn't that great. I'd still pick 200 in ten parts, but mostly I'd rely on DOM inspector to see where the bug is before I fire up my text editor at all. The previous is not to push an opinion on the split issue. I haven't thought about this enough to really say. It's probably possible to do the split using some relatively natural structure (something like "general.css", "buglist.css", "query.css", "admin.css", "show_bug.css" comes to mind). But we're going to have to be flexible with this, of course. Jouni From jth at mikrobitti.fi Sun Dec 7 20:59:58 2003 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Sun, 7 Dec 2003 22:59:58 +0200 (EET) Subject: Bug 69654 In-Reply-To: <2A3D3E91-28EE-11D8-9492-0003939CCA58@loggerithim.org> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <2A3D3E91-28EE-11D8-9492-0003939CCA58@loggerithim.org> Message-ID: On Sun, 7 Dec 2003, Cory 'G' Watson wrote: > > Now, what's the point of having a semantic markup and then slipping > > with stuff like "subheading" and "subsubheading"? (you probably mean > > class instead of id anyway) Or maybe the names of the classes were > > just badly selected? They should probably be something natural such as > > "bugsummary", right? > But that is not always a 'bugsummary', just like it's not > 'rightAligned' (from a your patch comment). Mm, yeah, I didn't mean a blind replace of "subsubheading" with "bugsummary". But when the content of subsubheading is a bug summary, the class name could reflect it. When it's something else, let's reflect that then. We are not supposed to assume that all subsubheadings are created equal (on style level), right? > I'm not big on using all through the document, I'd prefer to break > the page up with
s, but that's just MHO. Since HTML's headings don't really define containment, those two ideas work well together. Using Hx makes text-browsing and NS4 (CSSless) life easier, and it also gives the pages structure (outline). Let's remember that while
is an essential part of CSS layout, it's still nothing but a block container without defined semantics. Whenever something forms a natural text paragraph, it should be marked up as a
. The flexibility of div (the ability to have %flow content, mostly) shouldn't be abused, or we easily lose lot of usability when dealing with browsers that practically ignore divs. Anyway, something like the following is usable:
MyBugzilla

Query for bugs

Bug status

...

Bug resolution

...

The example above sucks, and I wouldn't strain things like H3 that far; the point is simply in co-operative use of Hx elements and (possibly stylistic) divs. > The problem with changing blocks to inlines is that things look > different in older browsers. How old browsers do you refer to? It's a pain, I agree, but display: xxx works surprisingly well if you're ready to accept reasonable variance in the UI. Anyway, we shouldn't base our default UI on the ability to alter the box model on the fly. When we want something inline, let's use something that's innately inline; when we want something rendered as a block, let's use a block element. Those who want to override our selections can work out the browser issues. > I'm a tab guy in CSS, since it's separate code. I'm not married to it, > however. If I could erase tabs from the face of the coding world, I'd do it. :-) > I prefer hierarchical, but as you point out, it requires alot more > thought up front. My problem is that I do not know bugzilla's innards > very well, and I tend to do such work iteratively. We may have to > rework existing styles on the third of fourth template into the work > because of some Epiphany of Elegance (my term for coming up with a much > nicer way to get the same results in HTML/CSS). Yes. The problem with iterative development is that it's not particularly well suited to our reasonably heavy-weight review/approval system. But still, getting a couple of iterations done is probably the nature of the beast; it's not like anyone of us could really shake out a working CSS infrastructure out of his sleeve. As long as we stay within one release cycle, I don't think changing class names is a catastrophe. It would seem we still have quite some time left before 2.18, so it's probably possible to get the basics in. Re your problem: Knowing Bugzilla innards isn't really that critical. Sure, you're going to have to know your way around and understand templates, but at least equally critical is understanding the UI and the user's view of it. The whole reviewer posse has good working knowledge on the internal issues, so what you said about many eyes applies again. Jouni From gphat at loggerithim.org Sun Dec 7 22:19:15 2003 From: gphat at loggerithim.org (Cory 'G' Watson) Date: Sun, 7 Dec 2003 16:19:15 -0600 Subject: Bug 69654 In-Reply-To: References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> Message-ID: <64B5CF88-2903-11D8-8533-0003939CCA58@loggerithim.org> On Dec 7, 2003, at 2:28 PM, Jouni Heikniemi wrote: > > Let's hope there will be a moment when a capable person will have both > the > sufficient information and the time to do this. I think throwing some > ideas around first is a good idea, though. I will hopefully have quite a few bursts of time to work on this. I bounce back and forth between 'irritated at the slowness', and 'excited by the yield' of the review/patch/comment process ;) > Screen readers have all sorts of problems, and we're not going to be > able > to solve all of them here. At this point, I feel that having a > meaningful > page outline (auto-constructed from the Hx elements) is the best we can > do. An H1 of "bugzilla.mozilla.org: Bug reporting system for Mozilla > and > related products" and a H2 of "Bug 23134: Yadda yadda" is pretty good > in > this sense. Users of a screen reader will be so disgusted by the accessibility features of the web that they will have dropped the stuff before they get to Bugzilla. ;) I suppose we should make an effort to help them, to be different. > Or, more practically speaking, we should at least avoid scaling the > default body font (fine-tuning heading sizes et al is usually more > acceptable). It's very easy to convince me to that, but people usually > view the default font sizes as way too large. This is not too bad with > serif fonts, though; Arial and especially Verdana suffer from this far > more. I agree. We can fiddle with headers and footers, but body fonts we should pretty much leave alone. >> I'm not so keen on a single file, just from a maintainability >> perspective. If you have some odd CSS interaction, would you rather >> look >> through 20 rules to see what's weird, or 200? > > 20, of course. But if it's 200 in ten files or 200 in a single file, > the > difference isn't that great. I'd still pick 200 in ten parts, but > mostly > I'd rely on DOM inspector to see where the bug is before I fire up my > text > editor at all. Being not so keen on a single file for maintainability reasons seems oxymoronic. I think they key to style leak is to have a watchdog over any new styles, and to be a but flexible in the UI. Cory 'G' Watson "The universal aptitude for ineptitude makes any human accomplishment an incredible miracle." - Dr. John Paul Stapp From gphat at loggerithim.org Sun Dec 7 22:31:10 2003 From: gphat at loggerithim.org (Cory 'G' Watson) Date: Sun, 7 Dec 2003 16:31:10 -0600 Subject: Bug 69654 In-Reply-To: References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <2A3D3E91-28EE-11D8-9492-0003939CCA58@loggerithim.org> Message-ID: <0E7E331A-2905-11D8-8533-0003939CCA58@loggerithim.org> On Dec 7, 2003, at 2:59 PM, Jouni Heikniemi wrote: > Mm, yeah, I didn't mean a blind replace of "subsubheading" with > "bugsummary". But when the content of subsubheading is a bug summary, > the > class name could reflect it. When it's something else, let's reflect > that > then. We are not supposed to assume that all subsubheadings are created > equal (on style level), right? I was under the impressions that being that generic was precisely the goal. If you call it 'bugsummary', you've pretty much made it impossible to use anywhere else. > The example above sucks, and I wouldn't strain things like H3 that far; > the point is simply in co-operative use of Hx elements and (possibly > stylistic) divs. I like the example, actually. I've never used where X > 3 for anything before. :/ > How old browsers do you refer to? It's a pain, I agree, but display: > xxx > works surprisingly well if you're ready to accept reasonable variance > in > the UI. Anyway, we shouldn't base our default UI on the ability to > alter > the box model on the fly. When we want something inline, let's use > something that's innately inline; when we want something rendered as a > block, let's use a block element. Those who want to override our > selections can work out the browser issues. Absolutely. I was referring back to a few of Christian's suggestions for using for elements of the heading, which need to be inline to stay horizontal. > Yes. The problem with iterative development is that it's not > particularly > well suited to our reasonably heavy-weight review/approval system. But > still, getting a couple of iterations done is probably the nature of > the > beast; it's not like anyone of us could really shake out a working CSS > infrastructure out of his sleeve. As long as we stay within one release > cycle, I don't think changing class names is a catastrophe. It would > seem > we still have quite some time left before 2.18, so it's probably > possible > to get the basics in. Yes. Changing class names would be Bad for anyone who was doing the exact thing we are trying to enable: simply making mods to a stylesheet, rather than huge CSS mods. > Re your problem: Knowing Bugzilla innards isn't really that critical. > Sure, you're going to have to know your way around and understand > templates, but at least equally critical is understanding the UI and > the > user's view of it. The whole reviewer posse has good working knowledge > on > the internal issues, so what you said about many eyes applies again. I voiced this mainly because I've not looked into what crazy CSS will be required for other pages. I spend my of my patch time on the bug info page. I'm not qualified to devise a set of classes and such that Just Work everywhere. Cory 'G' Watson "The universal aptitude for ineptitude makes any human accomplishment an incredible miracle." - Dr. John Paul Stapp From kiko at async.com.br Sun Dec 7 22:47:50 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Sun, 7 Dec 2003 20:47:50 -0200 Subject: Bug 69654 In-Reply-To: <0E7E331A-2905-11D8-8533-0003939CCA58@loggerithim.org> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <2A3D3E91-28EE-11D8-9492-0003939CCA58@loggerithim.org> <0E7E331A-2905-11D8-8533-0003939CCA58@loggerithim.org> Message-ID: <20031207224749.GA1174@async.com.br> On Sun, Dec 07, 2003 at 04:31:10PM -0600, Cory 'G' Watson wrote: > > On Dec 7, 2003, at 2:59 PM, Jouni Heikniemi wrote: > >Mm, yeah, I didn't mean a blind replace of "subsubheading" with > >"bugsummary". But when the content of subsubheading is a bug summary, > >the > >class name could reflect it. When it's something else, let's reflect > >that > >then. We are not supposed to assume that all subsubheadings are created > >equal (on style level), right? > > I was under the impressions that being that generic was precisely the > goal. If you call it 'bugsummary', you've pretty much made it > impossible to use anywhere else. Just to clarify, in that specific case, the only thing we can infer for the subheading and subsubheading is the fact that they are level-2 and level-3 headings -- the template doesn't tell global/header.html.tmpl anything beyond `hx = "foo foo foo"'. So I do think that subheading and subsubheading apply here. Nothing prevents, however, the template itself in adding an element that allows us to distinguish what it is (
or whatever). > Absolutely. I was referring back to a few of Christian's suggestions > for using for elements of the heading, which need to be inline > to stay horizontal. In hindsight, it was probably a silly suggestion, but I actually meant
. I know . > I voiced this mainly because I've not looked into what crazy CSS will > be required for other pages. I spend my of my patch time on the bug > info page. I'm not qualified to devise a set of classes and such that > Just Work everywhere. You'll probably be surprised; our content is quite uniformy "plain". The more complicated pages are search and show_bug. Once we've got header and footer sorted out, we can tackle the individual pages as we go (buglist is probably a good candidate for cleanups!) Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From kiko at async.com.br Sun Dec 7 22:54:23 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Sun, 7 Dec 2003 20:54:23 -0200 Subject: Bug 69654 In-Reply-To: <64B5CF88-2903-11D8-8533-0003939CCA58@loggerithim.org> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> <64B5CF88-2903-11D8-8533-0003939CCA58@loggerithim.org> Message-ID: <20031207225423.GB1174@async.com.br> > On Dec 7, 2003, at 2:28 PM, Jouni Heikniemi wrote: > >Let's hope there will be a moment when a capable person will have > >both the sufficient information and the time to do this. I think > >throwing some ideas around first is a good idea, though. > > I will hopefully have quite a few bursts of time to work on this. I > bounce back and forth between 'irritated at the slowness', and 'excited > by the yield' of the review/patch/comment process ;) It's always different to work with a distributed team on a project. You can focus on the negative aspects (difficult to grab people's attention, more explaining and consensus necessary, harder to established the required consensus, lost work because of miscommunication, slow review and approval process) or on the positive aspects (having the opportunity to work with people with a variety of backgrounds and experience, a group almost inherently unbiased, the stability that results from thorough (and potentially slow) review and approval process, personal development resulting from the exposure to people with varied abilities []). It's the balance of the good and bad that defines how good it feels to contribute to a project, and in the long-term does more to define the success of the project than anything else. [] As an added incentive, if you hack Bugzilla and come to Brazil, you automatically get free lodging in 3 different cities Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From gerv at mozilla.org Sun Dec 7 23:20:45 2003 From: gerv at mozilla.org (Gervase Markham) Date: Sun, 07 Dec 2003 23:20:45 +0000 Subject: Bug 69654 In-Reply-To: References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> Message-ID: <3FD3B5CD.4030506@mozilla.org> Jouni Heikniemi wrote: > On Sun, 7 Dec 2003, Gervase Markham wrote: >>Imagine a screen reader. "What's this page about?", asks the blind user. >>"This is Bugzilla", replies the reader, when it should really be >>replying "Bug 12345" or "Search for bugs". > > Actually, while what you say is true, I disagree. If you click a link on > some page and end up on something called "Bug 34567", you're pretty much > baffled. Well, presumably you wouldn't be baffled if the preceding page had explained what was going on, and why it had that particular link as part of it :-) > While it's true that when navigating inside Bugzilla the first > really interesting heading is the page title, I still don't think we can > skip the heading describing the particular installation. You mean "This is Bugzilla"? As I said, that's not guaranteed to be there - it could be an image. In fact, it was an image in the default install up until a year or so ago. As it happens, I don't like what we've replaced it with, and when we get a logo sorted out, I'd be up for returning to an image. But the point is, it's transient - so not a good choice for our H1. > Screen readers have all sorts of problems, That was merely one concrete example ;-) >>Normally, there's a "wrapper" page which includes the fragments it wants >>to make up the compound page; it will just have to make sure it also >>includes the relevant css files. > > The problem here is that it's potentially hard for the wrapper pages to > know all required css file references. It takes quite a bit of work to > figure out which style sheets could be necessary in all possible parameter > combinations. For example, if some new popup-based UI feature gets checked > in and used in several pages (like our current user selector), it can be > potentially hard for all pages to include exactly the proper combination > of css files. I don't see this as being an issue in practice, to be honest. >>I'm not so keen on a single file, just from a maintainability >>perspective. If you have some odd CSS interaction, would you rather look >>through 20 rules to see what's weird, or 200? > > 20, of course. But if it's 200 in ten files or 200 in a single file, the > difference isn't that great. I'd still pick 200 in ten parts, but mostly > I'd rely on DOM inspector to see where the bug is before I fire up my text > editor at all. Assuming the bug manifests itself in Mozilla... Gerv From gphat at cafes.net Mon Dec 8 02:20:15 2003 From: gphat at cafes.net (gphat at cafes.net) Date: Mon, 8 Dec 2003 02:20:15 GMT Subject: Bug 69654 Message-ID: <20031208022015.6E4EE33B34F5C@mail.cafes.net> > > On Dec 7, 2003, at 2:28 PM, Jouni Heikniemi wrote: > It's always different to work with a distributed team on a project. Absolutely ;) > It's the balance of the good and bad that defines how good it feels to > contribute to a project, and in the long-term does more to define the > success of the project than anything else. The important part (to me) is that the code that comes out of this discussion will be the best ideas of quite a bright folks. With all the comments, I'm not quite sure if there's enough consensus to hack on a patch tonight, so I'll hold off. Should there be a new bug created for my stylesheet/header patch? I think my first order of business is to discern what structure we will use for the pages. In an informal test (IE6 and Moz 1.5)
looks to be 'normal' font size, but bold. Anything else is smaller than the normal text, which is obviously not what we want. Perhaps the version text (Bugzilla 2.17.6) could be an
or
, the explanatory header (bugzilla bug X) can be an
, and then we have
for any remaining header-type stuff. The 3 horizonal divisions of the page header can stay 's. Cory 'G' Watson From cbendell at point2.com Mon Dec 8 06:14:52 2003 From: cbendell at point2.com (Colin Bendell) Date: Mon, 8 Dec 2003 00:14:52 -0600 Subject: Bug 69654 Message-ID: <85339FA608200E43BA1A364F09C337D6035781AE@bruno.point2.com> Just to throw my two cents in here: If you're interested to see what real css can do, check out http://www.csszengarden.com/ (I'd also recommend checking out the resources section in the above url.) /colin -----Original Message----- From: jay ball [mailto:jay at veggiespam.com] Sent: Saturday, December 06, 2003 1:45 PM To: developers at bugzilla.org Subject: Re: Bug 69654 i'm happy that bugzilla is adding CSS support. it'll make customization to corporate colours much easier. heck, you can even client side change the style sheet on the fly, so we can have a "print me" button at the top which load a plain, small font, tree wasting css file. CSS will also allow for future fun, like hidden HTML (which will be non-hidden on NS4 and lynx automatically). we can hide all of the advanced options on the search page and the user clicks on "advanced" and they magically appear. all slick, easily implemented, enterprise desired beautiful functions. I suggest a quick glance at http://www.alistapart.com/articles/slashdot/ . This was somebody's attempt at removing all of the customized hacky HTML 3.2 code from a slashcode page and replacing it with a fully CSS aware page which looks exactly the same. The author remove most of the tables - even using
instead in places that i would have never thought, like the header of images. He also gives a walk though of how he did it all of it, with the interim web pages. It'd be an excellent skim if you're leery of changing the bugzilla pages and might help us avoid pitfalls that he encountered. there is also a nice side effect to using CSS - lower bandwidth. in the slashdot example, it was 9k per page request. i don't know what b.m.o's costs are per month, but that might help push for a CSS change. -j - To view or change your list settings, click here: From justdave at bugzilla.org Mon Dec 8 06:19:16 2003 From: justdave at bugzilla.org (David Miller) Date: Mon, 8 Dec 2003 01:19:16 -0500 Subject: Wanted: Documentation Help Message-ID: First off I'd like to take this opportunity to express a world of gratitude to Jake Steenhagen for his work on the documentation the last several months. He's taken the great foundation Matthew Barnson gave us for our documentation and made it even better. Jake was just informed today that his Army Reserve unit is getting deployed to active duty effective December 23rd (about 2 weeks from now), and although they don't know the length yet, it'll likely be 18 months. I hope you'll all join me in wishing him well on his deployment and hoping we get him back safe and sound when it's over with. What this means for Bugzilla is we'll be without a documentation owner. If you're handy with Docbook and have lots of free time you're willing to donate, we'd be interested in hearing from you. You need to be familiar with Docbook XML markup (or not afraid to learn it). Being able to describe things in such a way that the clueless folks can figure out what you're talking about is handy, but there's folks around that can help you with that if needed. You would also be responsible for keeping an eye on the checkin logs and extracting documentation from patch authors when they introduce new features or change the way something works. Hunting down old features that never got documented wouldn't hurt either. I'm sure Jake will speak up if I left out anything. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From daa at rm.incc.net Mon Dec 8 07:18:01 2003 From: daa at rm.incc.net (David Avery) Date: Mon, 8 Dec 2003 00:18:01 -0700 Subject: Bug 69654 In-Reply-To: <20031208022015.6E4EE33B34F5C@mail.cafes.net>; from gphat@cafes.net on Mon, Dec 08, 2003 at 02:20:15AM +0000 References: <20031208022015.6E4EE33B34F5C@mail.cafes.net> Message-ID: <20031208001801.A23179@daa.dyndns.org> On 08-Dec-2003, gphat at cafes.net wrote: > > the explanatory header (bugzilla bug X) can be an
, and then we > have
for any remaining header-type stuff. The 3 horizonal > divisions of the page header can stay 's. > i would like to see a setup like http://www.distributed.net/bugs not be too hard to hack on this dave From jake at bugzilla.org Mon Dec 8 07:21:20 2003 From: jake at bugzilla.org (Jake) Date: Mon, 08 Dec 2003 02:21:20 -0500 Subject: Wanted: Documentation Help In-Reply-To: References: Message-ID: <3FD42670.8050702@bugzilla.org> David Miller wrote: >I'm sure Jake will speak up if I left out anything. :) > > Well, it may be obvious, but you also have to keep an eye on the Documentation component at b.m.o :). From jth at mikrobitti.fi Mon Dec 8 07:55:39 2003 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Mon, 08 Dec 2003 09:55:39 +0200 Subject: Bug 69654 In-Reply-To: <0E7E331A-2905-11D8-8533-0003939CCA58@loggerithim.org> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <2A3D3E91-28EE-11D8-9492-0003939CCA58@loggerithim.org> Message-ID: <5.1.0.14.2.20031208093134.03953258@mikrobitti.fi> At 16:31 7.12.2003 -0600, you wrote: >On Dec 7, 2003, at 2:59 PM, Jouni Heikniemi wrote: >>Mm, yeah, I didn't mean a blind replace of "subsubheading" with >>"bugsummary". But when the content of subsubheading is a bug summary, the >>class name could reflect it. When it's something else, let's reflect that >>then. We are not supposed to assume that all subsubheadings are created >>equal (on style level), right? >I was under the impressions that being that generic was precisely the >goal. If you call it 'bugsummary', you've pretty much made it impossible >to use anywhere else. That depends heavily on what the surroundings are. If you have, say,
Bug 2314 - Foobar
you can refer to that bugsummary as "h2 bugsummary", and still refer to other bug summaries elsewhere with only "bugsummary". Being generic and specific are not mutually exclusive if you use multiclassing; markup like |blah| could combine best of both worlds. >Absolutely. I was referring back to a few of Christian's suggestions for >using for elements of the heading, which need to be inline to stay >horizontal. Or be absolutely positioned. This is a reasonable alternative, too. >I voiced this mainly because I've not looked into what crazy CSS will be >required for other pages. I spend my of my patch time on the bug info >page. I'm not qualified to devise a set of classes and such that Just >Work everywhere. Nobody else will either. I believe we'll soon be able to crank out a set of rules that will act as a good basis for doing the CSS work. Let's just be flexible and ready to change them when we realize we've made mistakes. But as Kiko said, our content is fairly simple for the most part. Jouni From jth at mikrobitti.fi Mon Dec 8 08:00:29 2003 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Mon, 08 Dec 2003 10:00:29 +0200 Subject: Bug 69654 In-Reply-To: <3FD3B5CD.4030506@mozilla.org> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> Message-ID: <5.1.0.14.2.20031208095649.03dd2f98@mikrobitti.fi> At 23:20 7.12.2003 +0000, you wrote: >You mean "This is Bugzilla"? As I said, that's not guaranteed to be there >- it could be an image. In fact, it was an image in the default install up >until a year or so ago. As it happens, I don't like what we've replaced it >with, and when we get a logo sorted out, I'd be up for returning to an >image. But the point is, it's transient - so not a good choice for our H1. What's the point? Replace it with an image or not, the function of the banner is to identify the Bugzilla installation and perhaps bring some graphical feel into the page. The fact that it may technically be an image is IMO irrelevant - I find it to be a good H1 because it _semantically_ acts as the first heading of the page. >>I'd rely on DOM inspector to see where the bug is before I fire up my text >>editor at all. >Assuming the bug manifests itself in Mozilla... Right. While this isn't particularly relevant here, I'll just say that DOM Inspector is surprisingly good help at finding CSS problems even with other browsers. Sure it can't catch rendering bugs, but it can help narrow down the problems by giving an accurate listing of which CSS rules apply and which don't. Cascade and selector recognition work mostly uniformly across browsers (as long as you exclude NS4 and don't use CSS2). Jouni From jth at mikrobitti.fi Mon Dec 8 08:02:19 2003 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Mon, 08 Dec 2003 10:02:19 +0200 Subject: Bug 69654 In-Reply-To: <20031208022015.6E4EE33B34F5C@mail.cafes.net> Message-ID: <5.1.0.14.2.20031208100108.0419ae08@mikrobitti.fi> At 02:20 8.12.2003 +0000, you wrote: >Perhaps the version text (Bugzilla 2.17.6) could be an
or
, >the explanatory header (bugzilla bug X) can be an
, and then we >have
for any remaining header-type stuff. The 3 horizonal >divisions of the page header can stay 's. The version text is not semantically a fourth-level heading, even if h4's default rendering happened to match with what we want. We can specify font sizes without Hx elements, even if our main principle is to refrain from messing with font size settings. Jouni From ludovic at pobox.com Mon Dec 8 12:41:12 2003 From: ludovic at pobox.com (Ludovic Dubost) Date: Mon, 08 Dec 2003 13:41:12 +0100 Subject: Bug 69654 In-Reply-To: <20031206123324.GA854@async.com.br> References: <20031206123324.GA854@async.com.br> Message-ID: <3FD47168.2090305@pobox.com> Let's add my 2 cents about the CSS discussion and share a little my experience with making bugzilla CSS aware. First what I was trying to do because it was not only making bugzilla CSS but also included several interface changes. - modify the core template code to be able to apply CSS and decide where to put the different actions that use to be in the footer - add a action menu bar on top instead of having the action spread throughout the page - allow the creation of a 'standard' and 'advanced' section in all pages (with optionally the advanced mode being hidden by default) - allow the creation of a switchable 'read-only' and 'edit' view for bug views - trying to have a common look accross the different features --> these changes came after 4 years of usage of bugzilla with users with less tech experience using it and having to face resistance to the usage of the tool from time to time by potential users (Marketing team, etc..) - Especially being able to have the actions in a menu bar at the top of a page is more similar with the usual experience non-tech users have with computer applications. - The hidding of the advanced mode allows new users to bugzilla to not be confuse with less critical fields easing the adoption of the tool. - Changing the look to use CSS buttons not only allows to change it more easily but gives a 'sexy' look that is quite important to easy the adoption of the tool to a resisting non-tech audience.. Typical problems/choices that occured: - Definitively using a standard way of using H1/H2/H3 for titles and sections is usefull to reduce the amount of CSS to be written. - It was impossible to completely use CSS without JS for certain effects (menu drop downs using a click or show/hide the 'advanced' block). Note that it would be nice that the CSS design allows to created drop-down even if it is not the path the the mainstream bugzilla wants to take. - Forms are definitively easier to layout using tables especially when you dynamically show/hide certain form elements. I choose to keep the table layout for each section and use DIVs for surrounding each section.. Like this: - Also using a standard naming for the 'standard' and 'advanced' DIV allows to apply the same CSS/JS code. Creating a separate div for the header of each section was a way to apply a style.
Advanced

... with form elements

A different choice could have been to put the
in the
- The footer is at the bottom of the page. The only way to get it back at the top is absolute positioning. So float positioning is kind of forbidden if you want to keep the footer at the bottom in non CSS mode. - form elements in actions (like the Find box) are a bug pain to embed in CSS buttons (big source of CSS hacking) especially when you want it to work the same way in different browsers. It is better to split them in different elements and give the and different 'id' or 'class' to allow to apply specific styles to them. - I first used
for each action, search query or admin menu item. But in fact there is a neat solution to keep the '|' as separators so that the no-style view looks like it does in the current footer. Like this:
New | Search |
with the following styles, it will create buttons: #actions a { display: block; float: left; list-style-type: none; margin: 0.2em; padding: 0.4em; background-image: url(button_c.gif); background-repeat: repeat-x; background-color: #4A946B; font-size: 11px; font-weight: normal; font-style: normal; font-family: verdana; color: white; text-decoration: none; text-align: center; } #actions span { display: none; } - One of the major issue when it comes to flexibility is the fact that all actions lists are dynamic (some actions don't always appear). This clearly forces to use a certain level of 'float' positioning and not 'absolute'.. This probably means that all layouts are not possible depending on the way the fields are named and grouped together. For example it will be painfull (and maybe impossible) to change the order of actions using CSS. - IE especially 5.x have problems with certain directives and especially block sizes.. It might be needed to use some box level hacking to counter this when creating buttons using CSS - IE 6 has a problem with the comments place before the DOCTYPE (which allows to switch IE6 to the W3C standard). See http://bugzilla.mozilla.org/show_bug.cgi?id=225938 Lastly I want to defend a little the 'skin' system that was used which Gervase commented in the bug (http://bugzilla.mozilla.org/show_bug.cgi?id=69654#c43): - It was easy to implement so I don't think there are a log of maintenance issues. - It allows to create slightly modified looks, for example for PDAs of for specific browsers when you cannot workaround a browser bug.. This was inspired by the way http://www.csszengarden.com/ allows to switch CSS styles. - I don't say that bugzilla should be delivered with many skins and that there should be a skin trading mecanism.. But it could be a way to more easily apply other peoples work on your bugzilla installation without patches.. I hope this helps in creating a CSS aware bugzilla which would allow to create different looks for bugzilla without having to patch templates.. Ludovic From kiko at async.com.br Mon Dec 8 14:15:23 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 8 Dec 2003 12:15:23 -0200 Subject: Bug 69654 In-Reply-To: <3FD35C3C.8010403@mozilla.org> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> Message-ID: <20031208141523.GB1286@async.com.br> On Sun, Dec 07, 2003 at 04:58:36PM +0000, Gervase Markham wrote: > Jouni Heikniemi wrote: > >Any patch enhancing CSS support is a step in the right direction. > > Indeed; but Jouni is right. When we started doing templates, Myk and I > had a very good understanding about how we wanted them coded. The result > of that is that most of the templates are very consistent in style and > approach. This is a big bonus. Yeah, and then we renamed .atml to .html.tmpl and reorganized the template directory structure for localizations . I don't see this as negative -- I just think we should do some planning and then try and get something workable into the tree. Any problems we have are likely to show up sooner than later, and fixing CSS problems isn't usually rocket science. (To be honest, I just want to avoid us getting bogged down in CSS class syntax!) Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From kiko at async.com.br Mon Dec 8 14:25:03 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 8 Dec 2003 12:25:03 -0200 Subject: Bug 69654 In-Reply-To: <3FD35C3C.8010403@mozilla.org> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> Message-ID: <20031208142503.GC1286@async.com.br> I'm putting together a guideline text file, which is why I'm going through all these messages again. On Sun, Dec 07, 2003 at 04:58:36PM +0000, Gervase Markham wrote: > >Moving on from the Hx issue, we have the question on naming CSS classes. > >It's been suggested that all classes should start with bz_ to avoid > >namespace collisions. Theoretically I agree, but are there any namespace > >collisions to avoid in practice? Should we care? Having a prefix makes > >things more awkward to use. > > Indeed. The only possible reason is user stylesheets - and we can > namespace those by having a id="bugzilla" on the element. Can you summarize the conclusion here so I can add it to a guideline I'm putting together? > >Classically, pixels and percentages don't mix. To some extent, mixing > >relative and absolute units still causes pain - mostly with IE, whose > >font scaling bugs are worth a volume in themselves. It's a lot easier to > >use fixed font sizes like "13px" and "17px", but that may not be in the > >best interest of the user. Does anyone have a strong opinion on this? > > We've just been round this block with the new www.mozilla.org website. > Ideally, we wouldn't scale the user's font size at all. Ditto -- I'm not entirely sure what you meant by the last phrase. Do you mean no font-size: specified at all, or relative sizes only, or..? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From kiko at async.com.br Mon Dec 8 14:50:25 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 8 Dec 2003 12:50:25 -0200 Subject: Bug 69654 In-Reply-To: References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <2A3D3E91-28EE-11D8-9492-0003939CCA58@loggerithim.org> Message-ID: <20031208145025.GE1286@async.com.br> On Sun, Dec 07, 2003 at 10:59:58PM +0200, Jouni Heikniemi wrote: > On Sun, 7 Dec 2003, Cory 'G' Watson wrote: > > I'm a tab guy in CSS, since it's separate code. I'm not married to it, > > however. > > If I could erase tabs from the face of the coding world, I'd do it. :-) Just as a followup here, code checked in to Bugzilla (and mozilla.org CVS generally speaking) is forbidden to have tabs, period, so we're not going to be arguing over that :-) Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From kiko at async.com.br Mon Dec 8 15:01:01 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 8 Dec 2003 13:01:01 -0200 Subject: Bug 69654 In-Reply-To: <3FD3B5CD.4030506@mozilla.org> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> <3FD3B5CD.4030506@mozilla.org> Message-ID: <20031208150101.GF1286@async.com.br> On Sun, Dec 07, 2003 at 11:20:45PM +0000, Gervase Markham wrote: > Jouni Heikniemi wrote: > >On Sun, 7 Dec 2003, Gervase Markham wrote: > >>Imagine a screen reader. "What's this page about?", asks the blind user. > >>"This is Bugzilla", replies the reader, when it should really be > >>replying "Bug 12345" or "Search for bugs". > > > >Actually, while what you say is true, I disagree. If you click a link on > >some page and end up on something called "Bug 34567", you're pretty much > >baffled. > > Well, presumably you wouldn't be baffled if the preceding page had > explained what was going on, and why it had that particular link as part > of it :-) Yes, but what if you're coming in from another site? You just can't guarantee that a Web user went through the expected steps here. I strongly agree with Jouni and Cory that
should be the general site identification. > >While it's true that when navigating inside Bugzilla the first > >really interesting heading is the page title, I still don't think we can > >skip the heading describing the particular installation. > > You mean "This is Bugzilla"? As I said, that's not guaranteed to be > there - it could be an image. In fact, it was an image in the default > install up until a year or so ago. As it happens, I don't like what > we've replaced it with, and when we get a logo sorted out, I'd be up for > returning to an image. But the point is, it's transient - so not a good > choice for our H1. Err, what's wrong with
holding an image? I have yet to run into a Bugzilla installation that didn't have a header describing what the site was, so I don't think it's transient -- more to the point, I do think that most sites will customize the bugzilla header to contain something organization-specific -- it's just more logical to emphasize that this is a bug tracking system for project/company X than to emphasize that this is Bugzilla the world-class bug-tracking system and that it happens to be used in this particular instance for puny company X which isn't entitled to its own header in its
area :-) This doesn't mean I'm not for a Bugzilla logo -- of course Bugzilla needs its own identity, which should go with its default install. But sites running PHP4 or Apache don't have that in their
s, and I don't think most Bugzilla sites will either. > >The problem here is that it's potentially hard for the wrapper pages to > >know all required css file references. It takes quite a bit of work to > >figure out which style sheets could be necessary in all possible parameter > >combinations. For example, if some new popup-based UI feature gets checked > >in and used in several pages (like our current user selector), it can be > >potentially hard for all pages to include exactly the proper combination > >of css files. > > I don't see this as being an issue in practice, to be honest. I agree, and I think that having separate files is a good thing. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From kiko at async.com.br Mon Dec 8 15:25:49 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 8 Dec 2003 13:25:49 -0200 Subject: Bug 69654 In-Reply-To: <3FD47168.2090305@pobox.com> References: <20031206123324.GA854@async.com.br> <3FD47168.2090305@pobox.com> Message-ID: <20031208152549.GG1286@async.com.br> On Mon, Dec 08, 2003 at 01:41:12PM +0100, Ludovic Dubost wrote: > - Especially being able to have the actions in a menu bar at the top of > a page is more similar with the usual experience non-tech users have > with computer applications. This is a really important point (though rather orthogonal to the CSS issue here) -- our footer is a usability problem for most of our pages, since the user ends up having to scroll down (many times guessing he needs to scroll down) to [find out how to] navigate through the site. However, I need to stay focused here if we want the initial CSS framework to land -- when it's in, we can work on the UI improvements. > - Changing the look to use CSS buttons not only allows to change it more > easily but gives a 'sexy' look that is quite important to easy the > adoption of the tool to a resisting non-tech audience.. You'll find that many people will be reluctant to rely on images for buttons as "menu items", but that if a decent CSS structure is devised it should be easy to add those to a site CSS file. > - Also using a standard naming for the 'standard' and 'advanced' DIV > allows to apply the same CSS/JS code. Creating a separate div for the > header of each section was a way to apply a style. > >
Advanced
>
> ... with form elements
>
>
I didn't understand your point here. > - The footer is at the bottom of the page. The only way to get it back > at the top is absolute positioning. So float positioning is kind of > forbidden if you want to keep the footer at the bottom in non CSS mode. This could be param-configurable, or we could just move the footer content to the top of the page. Again, this is a larger UI change that should happen later.. > - I first used
for each action, search query or admin menu item. > But in fact there is a neat solution to keep the '|' as separators so > that the no-style view looks like it does in the current footer. Like this: I think that
is really the way to go for the top-level actions, though, and we might be able to tolerate some visual changes to allow this. > - I don't say that bugzilla should be delivered with many skins and > that there should be a skin trading mecanism.. But it could be a way to > more easily apply other peoples work on your bugzilla installation > without patches.. > > I hope this helps in creating a CSS aware bugzilla which would allow to > create different looks for bugzilla without having to patch templates.. Well, I think template customization is still going to be an integral part of localizing Bugzilla to an organization. We can: - use CSS to help people do a popular subset of possible changes to the layout, - separate usually-customized content into separate header files to avoid problems when updatings, - improve Bugzilla's UI layout to avoid the need to local customizations and improve OOTB usability, but having templates allows us to shift the finer points of UI discussion to localized templates. It helps keep us productive :-) Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From gphat at loggerithim.org Mon Dec 8 15:49:55 2003 From: gphat at loggerithim.org (Cory 'G' Watson) Date: Mon, 8 Dec 2003 09:49:55 -0600 Subject: Bug 69654 In-Reply-To: <20031208145025.GE1286@async.com.br> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <2A3D3E91-28EE-11D8-9492-0003939CCA58@loggerithim.org> <20031208145025.GE1286@async.com.br> Message-ID: <2B2CD7D6-2996-11D8-9EBB-0003939CCA58@loggerithim.org> On Dec 8, 2003, at 8:50 AM, Christian Robottom Reis wrote: > Just as a followup here, code checked in to Bugzilla (and mozilla.org > CVS generally speaking) is forbidden to have tabs, period, so we're not > going to be arguing over that :-) I'll resubmit my patch (after you get the guidelines done) that removes the tabs from the CSS. Cory 'G' Watson "The universal aptitude for ineptitude makes any human accomplishment an incredible miracle." - Dr. John Paul Stapp From ludovic at pobox.com Mon Dec 8 15:56:14 2003 From: ludovic at pobox.com (Ludovic Dubost) Date: Mon, 08 Dec 2003 16:56:14 +0100 Subject: Bug 69654 In-Reply-To: <20031208152549.GG1286@async.com.br> References: <20031206123324.GA854@async.com.br> <3FD47168.2090305@pobox.com> <20031208152549.GG1286@async.com.br> Message-ID: <3FD49F1E.5090803@pobox.com> Christian Robottom Reis wrote: >On Mon, Dec 08, 2003 at 01:41:12PM +0100, Ludovic Dubost wrote: > > >>- Especially being able to have the actions in a menu bar at the top of >>a page is more similar with the usual experience non-tech users have >>with computer applications. >> >> > >This is a really important point (though rather orthogonal to the CSS >issue here) -- our footer is a usability problem for most of our pages, >since the user ends up having to scroll down (many times guessing he >needs to scroll down) to [find out how to] navigate through the site. > >However, I need to stay focused here if we want the initial CSS >framework to land -- when it's in, we can work on the UI improvements. > > > That's true.. we just need to make sure the CSS structure will allow to do it.. So we need to integrate a div space to receive these actions.. It could be the same as the one for the Next/Prev links in the buglist.. I called it 'navheader'.. >>- Changing the look to use CSS buttons not only allows to change it more >>easily but gives a 'sexy' look that is quite important to easy the >>adoption of the tool to a resisting non-tech audience.. >> >> > >You'll find that many people will be reluctant to rely on images for >buttons as "menu items", but that if a decent CSS structure is devised >it should be easy to add those to a site CSS file. > > > It is true.. However in the design I used, it only needs 2 very small images for all the buttons.. The power of CSS make them look like real buttons.. So it doesn't have a huge impact on speed.. Also it should be possible to have a correct interface with colors of the images are not loaded.. As you say a decent CSS structure will allow to choose.. > > - Also using a standard naming for the 'standard' and 'advanced' DIV > >>>allows to apply the same CSS/JS code. Creating a separate div for the >>>header of each section was a way to apply a style. >>> >>>
Advanced
>>>
>>>... with form elements
>>>
>>>
>>> >>> >> >>I didn't understand your point here. >> >> >> > I think my example was not clear.. My point is to use the same names > for things that have a good chance of looking the same accross pages. > For example: > -> of course the banner; the footer > -> the actions for bug views or the next/prev links in bug list > -> a section with advance fields, > > > > >>> - The footer is at the bottom of the page. The only way to get it back >>>at the top is absolute positioning. So float positioning is kind of >>>forbidden if you want to keep the footer at the bottom in non CSS mode. >>> >>> >> >>This could be param-configurable, or we could just move the footer >>content to the top of the page. Again, this is a larger UI change that >>should happen later.. >> >> >> > Param configurable would be great.. This would improve the UI > performance when you want to show the links at the top of the page. > >>> - I first used
for each action, search query or admin menu item. >>>But in fact there is a neat solution to keep the '|' as separators so >>>that the no-style view looks like it does in the current footer. Like this: >>> >>> >> >>I think that
is really the way to go for the top-level actions, >>though, and we might be able to tolerate some visual changes to allow >>this. >> >> >> > I thought it in the beginning to since the
reprensents lists and > that it makes sense for menues to be lists.. > However when I saw the result without style sheets I really didn't > like the result.. For TV terminals or PDA it is true that you will see > the items but it won't be as nice as it is now.. The following article > (sorry in French: http://openweb.eu.org/articles/initiation_display/) > showed the tric to have a better accessibility using the | as it is in > bugzilla now.. > > With the trick you get the same benefit you get with the
but keep > the current way of presenting.. I don't see any reason to not do it > this way. > > > As an example here is the current div structure I'm using which allows quite well to customize: Here is the div structure I'm using in my template which allows to customize quite well the interface to my needs.. (it only shows the divs, not what is inside).. --> For the banner

--> Content
--> Navigation Header (actions: Edit/Attach/Show Dependency Tree in Bug view, Next/Prev in buglist) --> The navheader name is used to position it always at the same place --> then the others divs are positioned relatively to the main one

--> Bug View --> The is the div structure with a template where there is a read-only mode for bugs and an edit mode switchable using a button at the top.

Summary

Advanced

Summary

Advanced

Actions

Comments

--> Navigation footer (repeats the action unless you hide them using CSS)

--> end of content
--> Footer: the javascript here allows to show/hide the drop down menu.. A default implementation would do nothing.. --> Having separate divs for the title and the items themselves allows to make a button at one place and show the list of items at another place.. --> (for example show/hide the saved queries at the bottom from a button at the top)

Actions

Admin

Log out ludovic at xpertnet.biz

Searches

Ludovic From kiko at async.com.br Mon Dec 8 16:14:34 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 8 Dec 2003 14:14:34 -0200 Subject: Bug 69654 In-Reply-To: <3FD49F1E.5090803@pobox.com> References: <20031206123324.GA854@async.com.br> <3FD47168.2090305@pobox.com> <20031208152549.GG1286@async.com.br> <3FD49F1E.5090803@pobox.com> Message-ID: <20031208161434.GJ1286@async.com.br> On Mon, Dec 08, 2003 at 04:56:14PM +0100, Ludovic Dubost wrote: > >I think my example was not clear.. My point is to use the same names > >for things that have a good chance of looking the same accross pages. > >For example: > > -> of course the banner; the footer > > -> the actions for bug views or the next/prev links in bug list > > -> a section with advance fields, Ah, you mean classes that can be used in multiple pages, and use advanced fields as an example. Gotcha. > >>I think that
is really the way to go for the top-level actions, > >>though, and we might be able to tolerate some visual changes to allow > >>this. > >> > >I thought it in the beginning to since the
reprensents lists and > >that it makes sense for menues to be lists.. > >However when I saw the result without style sheets I really didn't > >like the result.. For TV terminals or PDA it is true that you will see > >the items but it won't be as nice as it is now.. The following article > >(sorry in French: http://openweb.eu.org/articles/initiation_display/) > >showed the tric to have a better accessibility using the | as it is in > >bugzilla now.. You could use that trick in conjunction with
s -- the issue is if you want them rendered as list items when no CSS style is available. I think that screen readers would appreciate it, and that generally speaking it's the "right thing to do", but I'm not sure and would appreciate third-party comments here. > Here is the div structure I'm using in my template which allows to > customize quite well the interface to my needs.. > (it only shows the divs, not what is inside).. But I miss the tags which provide us with actual page structure. Did you not use them? The example is interesting, thanks for it. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From ludovic at pobox.com Mon Dec 8 18:11:40 2003 From: ludovic at pobox.com (Ludovic Dubost) Date: Mon, 08 Dec 2003 19:11:40 +0100 Subject: Bug 69654 In-Reply-To: <20031208161434.GJ1286@async.com.br> References: <20031206123324.GA854@async.com.br> <3FD47168.2090305@pobox.com> <20031208152549.GG1286@async.com.br> <3FD49F1E.5090803@pobox.com> <20031208161434.GJ1286@async.com.br> Message-ID: <3FD4BEDC.7010205@pobox.com> Christian Robottom Reis wrote: >On Mon, Dec 08, 2003 at 04:56:14PM +0100, Ludovic Dubost wrote: > > >>>I think my example was not clear.. My point is to use the same names >>>for things that have a good chance of looking the same accross pages. >>>For example: >>>-> of course the banner; the footer >>>-> the actions for bug views or the next/prev links in bug list >>>-> a section with advance fields, >>> >>> > >Ah, you mean classes that can be used in multiple pages, and use >advanced fields as an example. Gotcha. > > > >>>>I think that
is really the way to go for the top-level actions, >>>>though, and we might be able to tolerate some visual changes to allow >>>>this. >>>> >>>> >>>> >>>I thought it in the beginning to since the
reprensents lists and >>>that it makes sense for menues to be lists.. >>>However when I saw the result without style sheets I really didn't >>>like the result.. For TV terminals or PDA it is true that you will see >>>the items but it won't be as nice as it is now.. The following article >>>(sorry in French: http://openweb.eu.org/articles/initiation_display/) >>>showed the tric to have a better accessibility using the | as it is in >>>bugzilla now.. >>> >>> > >You could use that trick in conjunction with
s -- the issue is if you >want them rendered as list items when no CSS style is available. I think >that screen readers would appreciate it, and that generally speaking >it's the "right thing to do", but I'm not sure and would appreciate >third-party comments here. > > > With CSS you can transform almost anything, but there is only one default look without CSS used by older browsers and possibly by browsers with less capacity like PDA browsers.. So I belive it is better to have something acceptable that comes out without CSS.. >>Here is the div structure I'm using in my template which allows to >>customize quite well the interface to my needs.. >>(it only shows the divs, not what is inside).. >> >> > >But I miss the tags which provide us with actual page structure. >Did you not use them? > > > I did.. Here is the full header output:

Bugzilla Version 2.17.6

Bugzilla Task 1

Test

Last modified: 2003-12-08 16:33

I've also used h1 and h2 in the section title like this:
Advanced
I've not been very consistent and this of course deserves to be changed.. I agree that inside the page we should not use h1 but may h2.. You can check out the output of my CSS based installation at http://bzdev.xpertnet.biz/bzdemo/show_bug.cgi?id=1 Ludovic >The example is interesting, thanks for it. > >Take care, >-- >Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 >- >To view or change your list settings, click here: > > > > > > From jth at mikrobitti.fi Mon Dec 8 19:46:37 2003 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Mon, 8 Dec 2003 21:46:37 +0200 (EET) Subject: Bug 69654 In-Reply-To: <20031208142503.GC1286@async.com.br> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> <20031208142503.GC1286@async.com.br> Message-ID: On Mon, 8 Dec 2003, Christian Robottom Reis wrote: > > Indeed. The only possible reason is user stylesheets - and we can > > namespace those by having a id="bugzilla" on the element. > Can you summarize the conclusion here so I can add it to a guideline I'm > putting together? My summarization would be that there will be no prefixes to cover for namespace issues. Should we consider it necessary at some point, let's add an id attribute into the element. > > >best interest of the user. Does anyone have a strong opinion on this? > > We've just been round this block with the new www.mozilla.org website. > > Ideally, we wouldn't scale the user's font size at all. > Ditto -- I'm not entirely sure what you meant by the last phrase. Do you > mean no font-size: specified at all, or relative sizes only, or..? I understood Gerv's opinion (and the following discussion) mostly as supporting the approach where no font-size is defined for body text, but where relative _header_ (and similar special-case) font sizes can be set by % units. Jouni From gerv at mozilla.org Mon Dec 8 20:23:49 2003 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 08 Dec 2003 20:23:49 +0000 Subject: Bug 69654 In-Reply-To: References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> <20031208142503.GC1286@async.com.br> Message-ID: <3FD4DDD5.9020506@mozilla.org> Jouni Heikniemi wrote: > My summarization would be that there will be no prefixes to cover for > namespace issues. Should we consider it necessary at some point, let's add > an id attribute into the element. I'd turn that round. Let's an an id to the element, as it may be useful at some point for namespacing. I actually think it's pretty likely to be useful for user stylesheets. > I understood Gerv's opinion (and the following discussion) mostly as > supporting the approach where no font-size is defined for body text, but > where relative _header_ (and similar special-case) font sizes can be set > by % units. Yep. Of course, it remains to be seen how well this pure approach works in the real world. Gerv From gphat at loggerithim.org Mon Dec 8 13:26:46 2003 From: gphat at loggerithim.org (Cory 'G' Watson) Date: Mon, 8 Dec 2003 07:26:46 -0600 Subject: Bug 69654 In-Reply-To: <5.1.0.14.2.20031208093134.03953258@mikrobitti.fi> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <2A3D3E91-28EE-11D8-9492-0003939CCA58@loggerithim.org> <5.1.0.14.2.20031208093134.03953258@mikrobitti.fi> Message-ID: <2BEAE27E-2982-11D8-9EBB-0003939CCA58@loggerithim.org> On Dec 8, 2003, at 1:55 AM, Jouni Heikniemi wrote: > At 16:31 7.12.2003 -0600, you wrote: >> On Dec 7, 2003, at 2:59 PM, Jouni Heikniemi wrote: >>> Mm, yeah, I didn't mean a blind replace of "subsubheading" with >>> "bugsummary". But when the content of subsubheading is a bug >>> summary, the >>> class name could reflect it. When it's something else, let's reflect >>> that >>> then. We are not supposed to assume that all subsubheadings are >>> created >>> equal (on style level), right? >> I was under the impressions that being that generic was precisely the >> goal. If you call it 'bugsummary', you've pretty much made it >> impossible to use anywhere else. > > That depends heavily on what the surroundings are. If you have, say, > >
Bug 2314 - Foobar
> > you can refer to that bugsummary as "h2 bugsummary", and still refer > to other bug summaries elsewhere with only "bugsummary". Being generic > and specific are not mutually exclusive if you use multiclassing; > markup like |blah| could > combine best of both worlds. I'd prefer to not use two classes of the same name even if we use a more hierarchical css style. Having the same class behave differently depending on it's context will confuse people trying to make their own stylesheets. >> Absolutely. I was referring back to a few of Christian's suggestions >> for using for elements of the heading, which need to be >> inline to stay horizontal. > > Or be absolutely positioned. This is a reasonable alternative, too. Absolutely. > Nobody else will either. I believe we'll soon be able to crank out a > set of rules that will act as a good basis for doing the CSS work. > Let's just be flexible and ready to change them when we realize we've > made mistakes. But as Kiko said, our content is fairly simple for the > most part. My point exactly. Cory 'G' Watson "The universal aptitude for ineptitude makes any human accomplishment an incredible miracle." - Dr. John Paul Stapp From gphat at loggerithim.org Mon Dec 8 13:34:21 2003 From: gphat at loggerithim.org (Cory 'G' Watson) Date: Mon, 8 Dec 2003 07:34:21 -0600 Subject: Bug 69654 In-Reply-To: <5.1.0.14.2.20031208100108.0419ae08@mikrobitti.fi> References: <5.1.0.14.2.20031208100108.0419ae08@mikrobitti.fi> Message-ID: <3AC4CBE3-2983-11D8-9EBB-0003939CCA58@loggerithim.org> On Dec 8, 2003, at 2:02 AM, Jouni Heikniemi wrote: > The version text is not semantically a fourth-level heading, even if > h4's default rendering happened to match with what we want. We can > specify font sizes without Hx elements, even if our main principle is > to refrain from messing with font size settings. Ok. Then how about we use my current patch on this bug? It's got:
This is BZ...
BZ Ver...

...
is the bz header text (or image in the future),
is the version (which doesn't to be id'ed, we can just lessen the font size of
, and an id'ed table (for width) with an
(which is just bigger and bolder enough to get what we want, IMHO) and 2 cells for sub and subsub. This arrangement of header is flexible enough to allow us to exchange that table/td arrangement for a div/span or something similar in the future, if we desire. This is already a nice improvement over the existing nested tables. Cory 'G' Watson "The universal aptitude for ineptitude makes any human accomplishment an incredible miracle." - Dr. John Paul Stapp From mike.morgan at oregonstate.edu Mon Dec 8 21:51:13 2003 From: mike.morgan at oregonstate.edu (Mike Morgan) Date: Mon, 08 Dec 2003 13:51:13 -0800 Subject: Bug 69654 In-Reply-To: <3FD4DDD5.9020506@mozilla.org> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> <20031208142503.GC1286@async.com.br> <3FD4DDD5.9020506@mozilla.org> Message-ID: <3FD4F251.7020101@oregonstate.edu> Gervase Markham wrote: >> I understood Gerv's opinion (and the following discussion) mostly as >> supporting the approach where no font-size is defined for body text, but >> where relative _header_ (and similar special-case) font sizes can be set >> by % units. > > > Yep. Of course, it remains to be seen how well this pure approach works > in the real world. I think it would be best if CSS keywords were used in the place of %'s. CSS keywords represent the old-school HTML FONT scale, and those are best whenever possible. Remember FONT size="blah"? Here is a good article on CSS2, font-sizes, and font-size keywords: http://style.cleverchimp.com/font_size_intervals/altintervals.html It's old, but it gets the point across. The best part is that instead of using percentages, you can use words like "small" or "x-small" which make more sense conceptually. Using keywords also avoids nesting problems for certain user agents. Another alternative would be to use em's, but if you are going to use em's you might as well use the keywords to ensure proper size intervals (1.2x). Overall, I agree with not defining a default font-size. I am tired of sites that have 8-pt arial font just to make things look all post-modern. Consider using keywords for instances where you do need to increase or decrease size. :) Another thing to consider is what level of accessibility you want to aim for. A, AA, AAA? This would be the time to worry about accessibility stuff. This goes back to the discussion about the footer being an accessibility problem. If we put the navigation in a div, we could place it wherever we wanted dependent on what the stylesheet said. :) A good site also has a navigation skip link so users using a text-only browser or screen reader can skip redundant links and hit the content right away. Mike From gerv at mozilla.org Mon Dec 8 22:45:14 2003 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 08 Dec 2003 22:45:14 +0000 Subject: Bug 69654 In-Reply-To: <3FD4F251.7020101@oregonstate.edu> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> <20031208142503.GC1286@async.com.br> <3FD4DDD5.9020506@mozilla.org> <3FD4F251.7020101@oregonstate.edu> Message-ID: <3FD4FEFA.7060306@mozilla.org> > I think it would be best if CSS keywords were used in the place of %'s. > CSS keywords represent the old-school HTML FONT scale, and those are > best whenever possible. Remember FONT size="blah"? The one massive shoot-yourself-in-the-foot problem with these is that they are skewed one level between Mozilla/Netscape and IE. So Mozilla's "medium" is IE's "small". Gerv From gerv at mozilla.org Mon Dec 8 22:57:45 2003 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 08 Dec 2003 22:57:45 +0000 Subject: Bug 69654 In-Reply-To: <20031208150101.GF1286@async.com.br> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> <3FD3B5CD.4030506@mozilla.org> <20031208150101.GF1286@async.com.br> Message-ID: <3FD501E9.9020607@mozilla.org> Christian Robottom Reis wrote: > Yes, but what if you're coming in from another site? You just can't > guarantee that a Web user went through the expected steps here. I > strongly agree with Jouni and Cory that
should be the general site > identification. OK, then :-) > Err, what's wrong with
holding an image? Er... nothing, as I just found when I went to w3.org to see what they did. Gerv From gerv at mozilla.org Mon Dec 8 23:00:36 2003 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 08 Dec 2003 23:00:36 +0000 Subject: Bug 69654 In-Reply-To: <3FD47168.2090305@pobox.com> References: <20031206123324.GA854@async.com.br> <3FD47168.2090305@pobox.com> Message-ID: <3FD50294.2050307@mozilla.org> Ludovic Dubost wrote: > Lastly I want to defend a little the 'skin' system that was used which > Gervase commented in the bug > (http://bugzilla.mozilla.org/show_bug.cgi?id=69654#c43): > - It was easy to implement so I don't think there are a log of > maintenance issues. That doesn't necessarily follow :-) And the ease of implementation of something is unrelated to how desirable it is. > - It allows to create slightly modified looks, for example for PDAs of > for specific browsers when you cannot workaround a browser bug.. This > was inspired by the way http://www.csszengarden.com/ allows to switch > CSS styles. Client-side stylesheet switching and alternate stylesheets is a different thing to an inbuilt skin system with prefs and so on. I'm all for the first (although I don't think Bugzilla needs more than one in its CVS) but wary of the second. Gerv From mike.morgan at oregonstate.edu Mon Dec 8 23:30:05 2003 From: mike.morgan at oregonstate.edu (Mike Morgan) Date: Mon, 08 Dec 2003 15:30:05 -0800 Subject: Bug 69654 In-Reply-To: <3FD4FEFA.7060306@mozilla.org> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> <20031208142503.GC1286@async.com.br> <3FD4DDD5.9020506@mozilla.org> <3FD4F251.7020101@oregonstate.edu> <3FD4FEFA.7060306@mozilla.org> Message-ID: <3FD5097D.2060301@oregonstate.edu> I don't think it's a big deal if IE has a one-level difference. Isn't the main argument for using relative sizes the fact that size doesn't really matter, and it should be left for the user to determine it? :) Mike Gervase Markham wrote: > The one massive shoot-yourself-in-the-foot problem with these is that > they are skewed one level between Mozilla/Netscape and IE. So Mozilla's > "medium" is IE's "small". From gerv at mozilla.org Mon Dec 8 23:48:43 2003 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 08 Dec 2003 23:48:43 +0000 Subject: Bug 69654 In-Reply-To: <3FD5097D.2060301@oregonstate.edu> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> <20031208142503.GC1286@async.com.br> <3FD4DDD5.9020506@mozilla.org> <3FD4F251.7020101@oregonstate.edu> <3FD4FEFA.7060306@mozilla.org> <3FD5097D.2060301@oregonstate.edu> Message-ID: <3FD50DDB.9020209@mozilla.org> Mike Morgan wrote: > I don't think it's a big deal if IE has a one-level difference. Isn't > the main argument for using relative sizes the fact that size doesn't > really matter, and it should be left for the user to determine it? :) Font size keywords aren't relative, they are absolute - "medium", "large" etc.. Relative keywords would be "bigger" and smaller". And trust me, the difference is about 2 points, and it is really noticeable. Gerv From mike.morgan at oregonstate.edu Tue Dec 9 00:38:19 2003 From: mike.morgan at oregonstate.edu (Mike Morgan) Date: Mon, 08 Dec 2003 16:38:19 -0800 Subject: Bug 69654 In-Reply-To: <3FD50DDB.9020209@mozilla.org> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> <20031208142503.GC1286@async.com.br> <3FD4DDD5.9020506@mozilla.org> <3FD4F251.7020101@oregonstate.edu> <3FD4FEFA.7060306@mozilla.org> <3FD5097D.2060301@oregonstate.edu> <3FD50DDB.9020209@mozilla.org> Message-ID: <3FD5197B.8050007@oregonstate.edu> Gervase Markham wrote: > Font size keywords aren't relative, they are absolute - "medium", > "large" etc.. Relative keywords would be "bigger" and smaller". > > And trust me, the difference is about 2 points, and it is really > noticeable. The font-size keywords are not absolute, they are a compromise between relative and absolute. They are relative because they depend on the client's default medium font-size, and they are absolute because they do not rely on or inherit their parent element's font-size in a document's hierarchy. Although I _do_ trust you, I've seen the difference between IE and Mozilla many times, and whether it's acceptable is just a matter of opinion. My opinion is that the noticeable size difference (that mainly occurs for larger sizes, esp in IE) is minor and shouldn't be used as a reason to abandon using keywords for relative font-sizes or even worse fixed font-sizes. A lot of this is summed up in the link I presented earlier: http://style.cleverchimp.com/font_size_intervals/altintervals.html Not a formal reference by any means, but its arguments are all solid if you take the time to read them. Whatever you guys want to use I'm fine with, I'm regurgitating all of this stuff because I had to make an educated decision about all of this stupid font-size crap for tools we develop here at the university, and we ended up going with keywords because they really have _no_ disadvantages when it comes to usability, which is something you can't say for purely relative (nesting) or purely fixed (unscalable in IE) font-sizes. And when it comes to usability versus cosmetics, it's an easy choice for pages that are published by a state university or government institution. Mike From jth at mikrobitti.fi Tue Dec 9 05:58:21 2003 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Tue, 9 Dec 2003 07:58:21 +0200 (EET) Subject: Bug 69654 In-Reply-To: <3FD5197B.8050007@oregonstate.edu> References: <5.1.0.14.2.20031206220006.03ea8790@vip.mikrobitti.fi> <3FD35C3C.8010403@mozilla.org> <20031208142503.GC1286@async.com.br> <3FD4DDD5.9020506@mozilla.org> <3FD4F251.7020101@oregonstate.edu> <3FD4FEFA.7060306@mozilla.org> <3FD5097D.2060301@oregonstate.edu> <3FD50DDB.9020209@mozilla.org> <3FD5197B.8050007@oregonstate.edu> Message-ID: > Although I _do_ trust you, I've seen the difference between IE and > Mozilla many times, and whether it's acceptable is just a matter of > opinion. My opinion is that the noticeable size difference (that mainly > occurs for larger sizes, esp in IE) is minor and shouldn't be used as a > reason to abandon using keywords for relative font-sizes or even worse > fixed font-sizes. I agree with both of you. Keywords are a good method for defining font-sizes for certain types of pages. However, they aren't a particularly good solution for pages that need considerable variance in font sizes. While I'm not saying Bugzilla is exactly the most graphical of applications, I wouldn't be ready to restrict such a heavy application to the set of font combinations /properly/ definable through keywords. We may not need all the font sizes, but some customizers may; and knowing how badly units mix, choosing keywords at this point might make more rigid font-tuning more of an issue for others. Re what you say about inheritance issues with totally relative units, I agree that's a problem, but it's not impossible to work around. It does take a bit of design work to fight the issues, but the end result beats the sole dependence on keywords IMO. > disadvantages when it comes to usability, which is something you can't > say for purely relative (nesting) or purely fixed (unscalable in IE) > font-sizes. And when it comes to usability versus cosmetics, it's an Purely fixed font scalability may well change in a future version of IE (or MSN Explorer, whatever). And that, my friends, will be a day we all meet with horror. Re accessibility levels that were brought up earlier: I think our focus should be getting Bugzilla to work with CSS and allow customization. When we want to move on to trimming our markup and make a dash for accessibility, we need to reconsider some structural issues as well. Anyway, even level A is a tall order with pages as complex as some in Bugzilla... Of course, when writing whatever CSS we're going to write, we should pay attention to keeping our markup as good (semantic) as possible. That will be an excellent basis for future work with accessibility. Jouni From gerv at mozilla.org Tue Dec 9 13:57:40 2003 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 09 Dec 2003 13:57:40 +0000 Subject: Template versioning Message-ID: <3FD5D4D4.8010505@mozilla.org> Hmm. We appear to have forgotten about our cunning scheme for template versioning. (See http://bugzilla.mozilla.org/show_bug.cgi?id=140527) So what's the plan? Do we do an assessment before the 2.18 release and bump the version numbers appropriately on every template? Sort of the "big bang" approach? Gerv From tobias.burnus at physik.fu-berlin.de Tue Dec 9 14:44:33 2003 From: tobias.burnus at physik.fu-berlin.de (Tobias Burnus) Date: Tue, 9 Dec 2003 15:44:33 +0100 Subject: Template versioning In-Reply-To: <3FD5D4D4.8010505@mozilla.org> References: <3FD5D4D4.8010505@mozilla.org> Message-ID: <20031209144432.GA811@physik.fu-berlin.de> Hello, On Tue, Dec 09, 2003 at 01:57:40PM +0000, Gervase Markham wrote: > Hmm. We appear to have forgotten about our cunning scheme for template > versioning. (See http://bugzilla.mozilla.org/show_bug.cgi?id=140527) > > So what's the plan? Do we do an assessment before the 2.18 release and > bump the version numbers appropriately on every template? Sort of the > "big bang" approach? As a translator, I really would like to see this. But one has to ensure that the version data is always updated. Otherwise automatic solutions (w/o having this nice major/minor distinction) have some pros (e.g. CVS's '$Revision$'/'$Revision: 1.1 $'). Setting all changed templates (= all?) to 2.0 or to 2.0/1.1 would be fine with me. Tobias From kiko at async.com.br Tue Dec 9 14:55:09 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Tue, 9 Dec 2003 12:55:09 -0200 Subject: Template versioning In-Reply-To: <3FD5D4D4.8010505@mozilla.org> References: <3FD5D4D4.8010505@mozilla.org> Message-ID: <20031209145509.GA1333@async.com.br> On Tue, Dec 09, 2003 at 01:57:40PM +0000, Gervase Markham wrote: > Hmm. We appear to have forgotten about our cunning scheme for template > versioning. (See http://bugzilla.mozilla.org/show_bug.cgi?id=140527) > > So what's the plan? Do we do an assessment before the 2.18 release and > bump the version numbers appropriately on every template? Sort of the > "big bang" approach? Bradley has voiced his opinion in the past that templates will require modifications for almost any change implemented. I tend to agree, but mostly because we've been changing templates a lot, particularly now when we are evaluating CSS changes and UI modifications -- our pages just aren't stable enough. I think it makes sense to use template versioning over a stable branch, where less checkins go in and we can really restrict what goes in; we can make it a policy that all changes to templates require evaluation and version updates. For the trunk it's a lot of effort, and IMO it's not going to help customizers/localizers much given that we're still constantly whacking the pages way beyond typo fixes. This from my personal experience with running a customized site. I would like to see the version comment moved inside the declaration, though [given that it's apparently causing problems with IE, but you didn't hear that from me]. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From myk at mozilla.org Tue Dec 9 18:52:28 2003 From: myk at mozilla.org (Myk Melez) Date: Tue, 09 Dec 2003 10:52:28 -0800 Subject: Bugzilla out of service In-Reply-To: <3FD5E29B.1020309@mozdev.org> References: <20031209143259.GA1252@async.com.br> <3FD5E29B.1020309@mozdev.org> Message-ID: <3FD619EC.9080509@mozilla.org> Pete Collins wrote: > Christian Robottom Reis wrote: > >>> This link was accessed 448 times since 12:00AM last night >>> continually from the same IP. It looks like an attack or an attempt >>> to crack the >>> box. >> >> We've been having similar trouble over at bmo, so you might want to talk >> to Myk or Justdave about it. > Indeed, we've had at least two DOS attacks since Saturday, the last one from 66.98.208.4. >>> We blocked the IP. Any thoughts on how best to deal w/ this kind of >>> crap? >> That's what we've been doing as well. We used to use mod_throttle to limit connections per minute from any given IP. We should do that again. > Should I upgrade to 2.17? 2.17 is pretty good and has some very useful features. I would recommend upgrading to the latest release of it. > It seems that there should be a page limit for queries that are huge > so attacks like this can never happen. Just limit the query to say 50 > itmes, per page and then let the user click forward if they want more > data. I'm not sure how much of an effect that would have. Output generation is just one cost of querying. If you limited output, DOSers could still construct queries with a high query execution cost and use up your server's resources that way. > Myke any quick fixes I can add to bugzilla to prevet an attacker from > scripting http GET's like the one I found in my log files below, that > can be used as a DOS/CRACK attack? You could change query.cgi's query form from a GET to a POST and then block GET requests in buglist.cgi, but this makes Bugzilla less usable (f.e. users can't bookmark queries or modify them via the URL) and is thus unpalatable. I suggest a suitably configured mod_throttle as the best defense. -myk From bugzilla at chimpychompy.org Wed Dec 10 16:07:03 2003 From: bugzilla at chimpychompy.org (GavinS) Date: Wed, 10 Dec 2003 16:07:03 +0000 Subject: Template versioning In-Reply-To: <3FD5D4D4.8010505@mozilla.org> References: <3FD5D4D4.8010505@mozilla.org> Message-ID: <16343.17575.140468.68252@offsite.i418.iplbath.com> Also related to template versioning is bug#186866 http://bugzilla.mozilla.org/show_bug.cgi?id=186866 which is the one about checking for outdated or changed versions of templates. When I asked about template versioning a few months ago, the reply was that template versioning wasn't necessary or being done until that bug was resolved. Personally, I'd vote for starting to change the template version numbers now, as described in bug 186866 and 140527, so that people can get used to both doing it and reviewing it. (We would also see if it does cause an unmanageable number of cvs conflicts, as some fear it may do.) Translators may also be able to start using (but not relying on!) the system, see if it helps them, and provide feedback. Gavin >>>>> "Gervase" == Gervase Markham writes: Gervase> Hmm. We appear to have forgotten about our cunning scheme for Gervase> template versioning. (See Gervase> http://bugzilla.mozilla.org/show_bug.cgi?id=140527) Gervase> So what's the plan? Do we do an assessment before the 2.18 Gervase> release and bump the version numbers appropriately on every Gervase> template? Sort of the "big bang" approach? Gervase> Gerv Gervase> - To view or change your list settings, click here: Gervase> From matty at chariot.net.au Sat Dec 13 10:10:50 2003 From: matty at chariot.net.au (MattyT) Date: Sat, 13 Dec 2003 20:40:50 +1030 Subject: removing domains from emails/logins In-Reply-To: References: <87ED4812394BA14980CC352C3A7483CC47F3AA@tatara.tatarasystems.com> Message-ID: <1071298809.13918.8.camel@megagerbil> On Tue, 2003-11-11 at 06:00, David Miller wrote: > UPDATE profiles SET login_name = REPLACE(login_name,'@tatarasystems.com',''); Another good reason for distinguishing login name from email address. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From mattyt-spam at tpg.com.au Sat Dec 13 10:14:29 2003 From: mattyt-spam at tpg.com.au (MattyT) Date: Sat, 13 Dec 2003 20:44:29 +1030 Subject: Please Help : Developers' Guide Update Message-ID: <1071310468.14635.30.camel@megagerbil> The developers' guide is getting somewhat outdated now. It quite incomplete, and even incorrect in places now. I've caught up somewhat so I'll be taking a look at updating it, before I look at getting my other Bugzilla commitments under control. Can everyone please look through it and let me know what needs to be changed. I know Gerv was complaining about this and I probably haven't fixed his concerns, but besides this there have been few complaints - this makes me somewhat nervous - it is there to be read. Also, I've been trawling through about 10k messages of bugmail, developers and so on and have made a list of issues I'm looking at maybe including. Please comment on them: Win32 Programming - What needs to be avoided? What is pipe open syntax? Path issues? Non-existent binaries? Examples? There seem to have been extra filters added. What are they, how do they work? Examples? Security implications? What needs to be done to not break mod_perl? What's the new review procedure that arose out of the new flags system? Do we have a CSS style policy yet? Some high level documentation about the new modules, especially how the new DB stuff replaces the old stuff. Module conventions? Module naming? File naming? Paths? Does the use of OO in the new modules warrant any style conventions being added? Are we using exceptions yet? Are we using placeholders yet? If so, any restrictions? If not, why not? Is $vars still in use? Any changes? More comments on performance? What to avoid? use diagnostics -> warnings? What perf testing tools and techniques are available? What's the latest deal on bad URL parameters - code or user error? What's the latest policy on multi-line SQL formatting? What's the latest policy on prototypes? When should they be used? If they shouldn't, why not? Can we use transactions yet? What's the latest deal with template versioning? Anything to add about PRE and POST chomp? When should INTERFACE comments be used? Any style? Brief description about the mailing lists ... etiquette? How has the testing suite been expanded? Are we using any email templates yet? If not, have we decided on any stylistic issues, or is there anything important to add? -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From mattyt-spam at tpg.com.au Sat Dec 13 10:11:20 2003 From: mattyt-spam at tpg.com.au (MattyT) Date: Sat, 13 Dec 2003 20:41:20 +1030 Subject: bugzilla 3.0... In-Reply-To: <3FB90C05.2070504@mozilla.org> References: <3FB90C05.2070504@mozilla.org> Message-ID: <1071309275.14929.28.camel@megagerbil> On Tue, 2003-11-18 at 04:27, Gervase Markham wrote: > Perhaps there should be - but what milestone could we pass that would be > worthy of the jump? We've done so much in the past in small increments > that it might seem odd. > > Perhaps one of: > - full templatisation > - running under mod_perl > > might be suitable... I think if you need to think about whether a feature is appropriate for bumping to 3.0, it isn't. We've got so much going on that I don't think arbitrarily choosing a feature is a good idea. Why do we need to bump the version number to 3.0 anyway? Sounds like a cheap marketing ploy to me. We should be happy to release 2.88 if we're lucky enough to get that far. I think that 3.0 should not be related to the feature set, so much as an opportunity to drop a large amount of backward compatibility cruft. IIRC, the bump to 2.0 was due to either the rewrite to Perl or the release to the public. Neither of these is feature based. By backward compatibility, I don't mean so much any user-facing page cruft, but administrator things like old schema support in checksetup, and direct sendmail support. What I mean by checksetup is that the only acceptable way to upgrade from 2.X to 3.X is via an upgrade from 2.last to 3.X. This means we can drop a large amount of schema upgrade code in checksetup, all the code that goes from 2. References: <1071310468.14635.30.camel@megagerbil> Message-ID: On Sat, 13 Dec 2003, MattyT wrote: > The developers' guide is getting somewhat outdated now. It quite > incomplete, and even incorrect in places now. I've caught up somewhat > so I'll be taking a look at updating it, before I look at getting my > other Bugzilla commitments under control. Excellent :-) This is really needed. > Win32 Programming - What needs to be avoided? What is pipe open > syntax? Path issues? Non-existent binaries? Examples? Some simple points: 1) Avoid stuff that's only meaningful on x. Trivial examples include: - chown, chmod - getgrnam, $< et al. - stty - sendmail :-) (84876) - signal handling (see bugs 143490, 224476, 154601 for some ideas) Most of the time, it suffices when you think these things through and, if necessary, add OS checks to bypass Unix-only code. I'll assist in coming up with Win32 alternatives when necessary. 2) Avoid features that are not supported by ActiveState Perl O:-) - fork() is definitely out of bounds; this isn't directly used, but bug 183753 has an example on a very tricky issue w/ this. - "open (DOT, '-|') or exec (stuff);" is the pipe open beast. (I'm still looking for a good alternative for this, so don't have a recommendation yet) - Any execs are subject to limitations mentioned in 129401; it's probably worth the effort to go through the cases one-by-one, since we have so few cases of external execution. 3) Taint mode stuff - IIS forces all files to run under taint mode. - This is mostly irrelevant in the dg, though; admin files are getting taint-checked while we templatize, and after that we're fine. Nothing beats testing! IIS in particular is a good test platform, as it prints CGI warnings to stdout instead of an error log :-) I'll add details, should I remember some more. > Do we have a CSS style policy yet? No. Kiko has been writing up a draft, he promised he'll post it really soon now. (it'll probably take a few patches of practice before it develops into a decent policy, though) > Brief description about the mailing lists ... etiquette? Shouldn't this be on the discussion page instead of dev guide? A couple of other points worth mentioning, although I'm not the resident guru on these: - Template naming (see discussion a few weeks ago on reviewers@). The current text on this is fairly close to the consensus reached, though. - Using filterexceptions.pl (see bug 225703 comments 19-21) - Maintaining customizable terms: We now have "[% terms.Bug %] instead of "Bug" and so on. Discuss the reasons and best practices. Jouni From gerv at mozilla.org Sat Dec 13 21:43:39 2003 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 13 Dec 2003 21:43:39 +0000 Subject: Template versioning In-Reply-To: <20031209145509.GA1333@async.com.br> References: <3FD5D4D4.8010505@mozilla.org> <20031209145509.GA1333@async.com.br> Message-ID: <3FDB880B.60405@mozilla.org> Christian Robottom Reis wrote: > I think it makes sense to use template versioning over a stable branch, > where less checkins go in and we can really restrict what* goes in; we > can make it a policy that all changes to templates require evaluation > and version updates. That seems like a very sensible idea. So just before each major stable release, we bump the major number of the template versions on every template which has changed at all (which will be most or all of them.) After that, we use minor numbers on the branch. How does that sound? Gerv From gerv at mozilla.org Sat Dec 13 22:05:53 2003 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 13 Dec 2003 22:05:53 +0000 Subject: bugzilla 3.0... In-Reply-To: <1071309275.14929.28.camel@megagerbil> References: <3FB90C05.2070504@mozilla.org> <1071309275.14929.28.camel@megagerbil> Message-ID: <3FDB8D41.2070300@mozilla.org> MattyT wrote: > I think that 3.0 should not be related to the feature set, so much as > an opportunity to drop a large amount of backward compatibility cruft. > IIRC, the bump to 2.0 was due to either the rewrite to Perl or the > release to the public. Neither of these is feature based. Hey - perhaps we'll bump it to 3.0 when we rewrite Bugzilla in Java. ;-) > By backward compatibility, I don't mean so much any user-facing page > cruft, but administrator things like old schema support in checksetup, > and direct sendmail support. What I mean by checksetup is that the only > acceptable way to upgrade from 2.X to 3.X is via an upgrade from 2.last > to 3.X. This means we can drop a large amount of schema upgrade code in > checksetup, all the code that goes from 2. move it into another script. Is there ever any reason to do that, apart from the fact that it now takes my editor 15 seconds to parse checksetup.pl for syntax highlighting? Gerv From justdave at bugzilla.org Sun Dec 14 07:00:00 2003 From: justdave at bugzilla.org (David Miller) Date: Sun, 14 Dec 2003 02:00:00 -0500 Subject: Landfill collectstats Message-ID: Just FYI, since I saw it mentioned on a bug somewhere the other day, I got off my @$$ and set up the cron jobs for collectstats.pl on all of the "public demo" status Bugzillas (the ones listed on the landfill home page at the top), so there should be useful charting data on those installations soon to be able to see what the charts do. I also used the --regenerate option on the ones that were new enough to have it (2.17.6 and cvs-tip) so those should have a decent history of statistics to chart from. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From kiko at async.com.br Mon Dec 15 17:24:06 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 15 Dec 2003 15:24:06 -0200 Subject: Template versioning In-Reply-To: <3FDB880B.60405@mozilla.org> References: <3FD5D4D4.8010505@mozilla.org> <20031209145509.GA1333@async.com.br> <3FDB880B.60405@mozilla.org> Message-ID: <20031215172406.GA670@async.com.br> On Sat, Dec 13, 2003 at 09:43:39PM +0000, Gervase Markham wrote: > So just before each major stable release, we bump the major number of > the template versions on every template which has changed at all (which > will be most or all of them.) After that, we use minor numbers on the > branch. > > How does that sound? Perfect to me. I really don't feel we should spend time worrying about template versioning in the trunk, and making it a review/approval-time requirement only for the stable branch is both effective and a whole lot easier. Dave, how do you feel about this? Jouni? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From justdave at bugzilla.org Mon Dec 15 18:05:16 2003 From: justdave at bugzilla.org (David Miller) Date: Mon, 15 Dec 2003 13:05:16 -0500 Subject: Template versioning In-Reply-To: <20031215172406.GA670@async.com.br> References: <3FD5D4D4.8010505@mozilla.org> <20031209145509.GA1333@async.com.br> <3FDB880B.60405@mozilla.org> <20031215172406.GA670@async.com.br> Message-ID: On 12/15/2003 3:24 PM -0200, Christian Robottom Reis wrote: > On Sat, Dec 13, 2003 at 09:43:39PM +0000, Gervase Markham wrote: >> So just before each major stable release, we bump the major number of >> the template versions on every template which has changed at all (which >> will be most or all of them.) After that, we use minor numbers on the >> branch. >> >> How does that sound? > > Perfect to me. I really don't feel we should spend time worrying about > template versioning in the trunk, and making it a review/approval-time > requirement only for the stable branch is both effective and a whole lot > easier. > > Dave, how do you feel about this? Jouni? My primary concern with it is it be useful for customizers and localizers. If the localizers like it I'll go for it. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From jth at mikrobitti.fi Mon Dec 15 19:49:38 2003 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Mon, 15 Dec 2003 21:49:38 +0200 (EET) Subject: Template versioning In-Reply-To: <20031215172406.GA670@async.com.br> References: <3FD5D4D4.8010505@mozilla.org> <20031209145509.GA1333@async.com.br> <3FDB880B.60405@mozilla.org> <20031215172406.GA670@async.com.br> Message-ID: On Mon, 15 Dec 2003, Christian Robottom Reis wrote: > > So just before each major stable release, we bump the major number of > > the template versions on every template which has changed at all (which > > will be most or all of them.) After that, we use minor numbers on the > > branch. > Perfect to me. I agree that it sounds like a usable solution. Though, do I understand correctly that the semantics assigned for major and minor version numbers* would then no longer apply? Because there's no way to guarantee that changes in a stable branch wouldn't be interface-breaking... Jouni ) From bug 140527 comment 1: "If the major part changes, that means the interface to this template is incompatible with the interface to previous templates. Bugzilla will note this incompatibility and tell you about it. If the minor part changes, the interface is backwardly-compatible, but there are some changes you should investigate and consider also making in your custom templates." From kiko at async.com.br Mon Dec 15 20:20:30 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 15 Dec 2003 18:20:30 -0200 Subject: Template versioning In-Reply-To: References: <3FD5D4D4.8010505@mozilla.org> <20031209145509.GA1333@async.com.br> <3FDB880B.60405@mozilla.org> <20031215172406.GA670@async.com.br> Message-ID: <20031215202029.GB1470@async.com.br> On Mon, Dec 15, 2003 at 09:49:38PM +0200, Jouni Heikniemi wrote: > > > So just before each major stable release, we bump the major number of > > > the template versions on every template which has changed at all (which > > > will be most or all of them.) After that, we use minor numbers on the > > > branch. > > I agree that it sounds like a usable solution. Though, do I understand > correctly that the semantics assigned for major and minor version numbers > would then no longer apply? Because there's no way to guarantee that > changes in a stable branch wouldn't be interface-breaking... Really? I would think all changes in the stable branch would be backwards-compatible, to ensure that customized templates would work over the whole branch's lifetime. Doesn't our 2.16 experience confirm this? > ) From bug 140527 comment 1: > > "If the major part changes, that means the interface to this template is > incompatible with the interface to previous templates. Bugzilla will note > this incompatibility and tell you about it. > > If the minor part changes, the interface is backwardly-compatible, but > there are some changes you should investigate and consider also making in > your custom templates." My suggestion for this is the following: We push up version numbers for template changes inside the stable branch. The changes accepted should only be minor changes. When the devel branch ships [] -- IOW, when it becomes the next stable branch -- push the major version up one notch from the current stable version's major. If by any chance a catastrophic situation arises on the stable branch which requires incompatible changes to templates, push up the template's major number and live with the broken pieces. This is a last-resort measure, to be sure, to be avoided at all costs. [] We could do this when the devel branch opened. However, this will make it impossible* to increment the major version in the stable branch without creating serious confusion. This does leave a loophole resulting from incompatible changes done to a previous stable version when the next stable version has shipped. I think the policy should be that these changes are forbidden, and users wanting a fix should move on to the new stable version. In practice, this implies the following actions: - When reviewing or approving a template change on the stable branch, ask the patch author if the template version should be updated, and if not, why not. - When shipping a new stable branch, do a major template version update over all previously shipped templates. Sounds acceptable? Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From Habers at pbworld.com Mon Dec 15 20:46:39 2003 From: Habers at pbworld.com (Habers, Mark) Date: Mon, 15 Dec 2003 15:46:39 -0500 Subject: How do I make $isprivate true by default on all new and AppendComments? Message-ID: <2BAAFCCCE018A447877157AFCED9734402F9BB33@nycmrmt2.corp.pbwan.net> Hi Everyone, I have what are probably 2 really simple questions based on the knowledge most of you have. I am running BugZilla 2.17.4 on Windows with an IIS front end (my apologies in advance). Our project loves the tool and I have used it for many years with previous companies on UNIX variants. Getting to the point, we are going to open up BugZilla for all of our users (8000+ of them) and we want them to be able to see the issues, and add new ones, but not be able to see what some would consider to be our offensive comments on these issues. The natural assumption on my part is that we need to start using the insidergroup, give our team members membership to that group and and then start marking our non-politically correct comments as private. The problem is that our developers will forget to do this first of all, and second, I have thousands of issues containing these offensive comments. I need to do 2 things to protect the innocent. First, I would like to globally change every pre-existing comment from isprivate = 0 to isprivate =1(yes) in mySQL, could someone help me with a quick and dirty script to do this? Second, I would like to make the 'Private' checkbox, seen whenever a user is adding a comment on a new or pre-existing bug, default to selected. This way our developers, and myself for that matter can choose which comments we want made public in the future (if any) without worrying about all of the garbage we currently cannot let our users, managers and executive officers see. Thanks in Advance Mark Habers -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Mon Dec 15 21:58:03 2003 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 15 Dec 2003 21:58:03 +0000 Subject: How do I make $isprivate true by default on all new and AppendComments? In-Reply-To: <2BAAFCCCE018A447877157AFCED9734402F9BB33@nycmrmt2.corp.pbwan.net> References: <2BAAFCCCE018A447877157AFCED9734402F9BB33@nycmrmt2.corp.pbwan.net> Message-ID: <3FDE2E6B.6050501@mozilla.org> Habers, Mark wrote: > Hi Everyone, Hi Mark. This sort of support question (and any followup question) is generally better asked in the newsgroup :-) > I need to do 2 things to protect the innocent. First, I would like to > globally change every pre-existing comment from isprivate = 0 to > isprivate =1(yes) in mySQL, could someone help me with a quick and dirty > script to do this? UPDATE longdescs SET isprivate = 1; > Second, I would like to make the ?Private? checkbox, > seen whenever a user is adding a comment on a new or pre-existing bug, > default to selected. template/en/default/attachment/create.html.tmpl, "isprivate" checkbox, add "checked" to the tag. /usr/src/bugzilla/template/en/default/bug/edit.html.tmpl, around line 450, "commentprivacy" checkbox, add "checked" to the tag. Gerv From Habers at pbworld.com Mon Dec 15 23:24:19 2003 From: Habers at pbworld.com (Habers, Mark) Date: Mon, 15 Dec 2003 18:24:19 -0500 Subject: How do I make $isprivate true by default on all new and AppendComments? Message-ID: <2BAAFCCCE018A447877157AFCED97344022F9650@nycmrmt2.corp.pbwan.net> Thanks Gerv, Sorry for the spam and thanks for your help. It worked perfectly. No question :) -----Original Message----- From: developers-owner at bugzilla.org [mailto:developers-owner at bugzilla.org] On Behalf Of Gervase Markham Sent: Monday, December 15, 2003 2:58 PM To: developers at bugzilla.org Subject: Re: How do I make $isprivate true by default on all new and AppendComments? Habers, Mark wrote: > Hi Everyone, Hi Mark. This sort of support question (and any followup question) is generally better asked in the newsgroup :-) > I need to do 2 things to protect the innocent. First, I would like to > globally change every pre-existing comment from isprivate = 0 to > isprivate =1(yes) in mySQL, could someone help me with a quick and dirty > script to do this? UPDATE longdescs SET isprivate = 1; > Second, I would like to make the 'Private' checkbox, > seen whenever a user is adding a comment on a new or pre-existing bug, > default to selected. template/en/default/attachment/create.html.tmpl, "isprivate" checkbox, add "checked" to the tag. /usr/src/bugzilla/template/en/default/bug/edit.html.tmpl, around line 450, "commentprivacy" checkbox, add "checked" to the tag. Gerv - To view or change your list settings, click here: From gerv at mozilla.org Mon Dec 15 23:34:48 2003 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 15 Dec 2003 23:34:48 +0000 Subject: Template versioning In-Reply-To: <20031215202029.GB1470@async.com.br> References: <3FD5D4D4.8010505@mozilla.org> <20031209145509.GA1333@async.com.br> <3FDB880B.60405@mozilla.org> <20031215172406.GA670@async.com.br> <20031215202029.GB1470@async.com.br> Message-ID: <3FDE4518.8070903@mozilla.org> Christian Robottom Reis wrote: > Really? I would think all changes in the stable branch would be > backwards-compatible, to ensure that customized templates would work > over the whole branch's lifetime. Doesn't our 2.16 experience confirm > this? Indeed. Being able to keep the same templates over an entire stable branch's lifetime should be a hard goal. >>"If the major part changes, that means the interface to this template is >>incompatible with the interface to previous templates. Bugzilla will note >>this incompatibility and tell you about it. >> >>If the minor part changes, the interface is backwardly-compatible, but >>there are some changes you should investigate and consider also making in >>your custom templates." In one sense, yes, what we are suggesting is a slight modification to the original scheme. But I think we've conclusively proved that getting people to update template versions at the time they patch is not workable. But then, if each stable release is going to have a new template version, where's the benefit of versioning in this way at all? The template version is tied to the Bugzilla version. OK, we can get some benefit by flagging which templates have changed on the stable branch - if we write code that actually does this - but we could just as easily do that in the release notes. Gerv From gerv at mozilla.org Mon Dec 15 23:58:30 2003 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 15 Dec 2003 23:58:30 +0000 Subject: Landfill collectstats In-Reply-To: References: Message-ID: <3FDE4AA6.5010606@mozilla.org> David Miller wrote: > Just FYI, since I saw it mentioned on a bug somewhere the other day, I got > off my @$$ and set up the cron jobs for collectstats.pl on all of the > "public demo" status Bugzillas (the ones listed on the landfill home page > at the top), so there should be useful charting data on those installations > soon to be able to see what the charts do. Thanks :-) Gerv From jth at mikrobitti.fi Tue Dec 16 06:05:40 2003 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Tue, 16 Dec 2003 08:05:40 +0200 (EET) Subject: Template versioning In-Reply-To: <20031215202029.GB1470@async.com.br> References: <3FD5D4D4.8010505@mozilla.org> <20031209145509.GA1333@async.com.br> <3FDB880B.60405@mozilla.org> <20031215172406.GA670@async.com.br> <20031215202029.GB1470@async.com.br> Message-ID: On Mon, 15 Dec 2003, Christian Robottom Reis wrote: > Really? I would think all changes in the stable branch would be > backwards-compatible, to ensure that customized templates would work > over the whole branch's lifetime. Doesn't our 2.16 experience confirm > this? Our 2.16 experience isn't IMO very much to confirm anything, though - it's just one version after all. Of course you're right in that maintaining template interfaces throughout a stable branch must be very high on our target list, but there are some situations where the template interface _must_ be changed in order fix something. A reasonably trivial example would be printing out something that used to be html filtered in the template, but now gets some html pushed into it from Perl. The interface must now change, not by variable names, but by type semantics. Instead of template var foo being a "string", it is now a "prepared html string", html re-filtering of which causes the user to see markup. Although I don't think this is bound to happen often (that sort of changes are rarely involved in security/functionality fixes that stable branches get), it would suck if it broke the versioning scheme totally. Thought wandering a bit elsewhere, here: Our stable branches have been fairly locked up, but is this because there's nobody to maintain the stable ones or is it because we really think it's a good idea to totally freeze the stable versions? I was thinking, if the Bugzilla developer base grows significantly, I don't see it as impossible that we may some day have a "stable dev group", who integrate the best patches from trunk into stable versions. This would allow us to make it easy for those using the stable branch to get the best minor enhancements and most important bug fixes without getting the instability of heavy structural rewrites that occur in the trunk. I'm by no means advocating founding such a stable team, but it might not be a good idea to weld ourselves into a model where stable branches only get security fixes. There are plenty of users who will never get a dev release, but who probably would enjoy many of 2.17-series' new features. The partial name user matching is a prime example. Jouni From justdave at bugzilla.org Tue Dec 16 06:21:55 2003 From: justdave at bugzilla.org (David Miller) Date: Tue, 16 Dec 2003 01:21:55 -0500 Subject: Template versioning In-Reply-To: References: <3FD5D4D4.8010505@mozilla.org> <20031209145509.GA1333@async.com.br> <3FDB880B.60405@mozilla.org> <20031215172406.GA670@async.com.br> <20031215202029.GB1470@async.com.br> Message-ID: On 12/16/2003 8:05 AM +0200, Jouni Heikniemi wrote: > I was thinking, if the Bugzilla developer base grows significantly, I > don't see it as impossible that we may some day have a "stable dev group", > who integrate the best patches from trunk into stable versions. This would > allow us to make it easy for those using the stable branch to get the > best minor enhancements and most important bug fixes without getting the > instability of heavy structural rewrites that occur in the trunk. > > I'm by no means advocating founding such a stable team, but it might not > be a good idea to weld ourselves into a model where stable branches only > get security fixes. There are plenty of users who will never get a dev > release, but who probably would enjoy many of 2.17-series' new features. > The partial name user matching is a prime example. We've already started doing this to a limited extent. There were several non-security related bugfixes in 2.16.4, and there's already been several checked into or targeted for the 2.16 branch since 2.16.4. Enough that there will probably be a 2.16.5 by the new year or shortly thereafter, whether we have any security fixes to put in it or not. We have 7 bugs currently targeted at 2.16.5, 3 of which are marked fixed already. My basic criteria at this point is that it be either high-impact or obvious, and be low-risk. I'm not too keen on adding features to the 2.16 branch (part of being "stable" is not having new things pop up that'll confuse your users), but low-risk bug fixes are fair game. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From hitao at clusterfs.com Tue Dec 16 10:21:54 2003 From: hitao at clusterfs.com (hitao) Date: Tue, 16 Dec 2003 18:21:54 +0800 Subject: groups have groups as member, will this be hard? Message-ID: <017301c3c3be$75f6b190$0c01a8c0@cfsc8hf7h1aac2> I want to modify bugzilla so that we can define groups as member of other groups to gain more flexible access controls. Will it be hard and is there anybody have experience on this to share? Wish you a nice day! Hitao From justdave at bugzilla.org Tue Dec 16 10:26:14 2003 From: justdave at bugzilla.org (David Miller) Date: Tue, 16 Dec 2003 05:26:14 -0500 Subject: groups have groups as member, will this be hard? In-Reply-To: <017301c3c3be$75f6b190$0c01a8c0@cfsc8hf7h1aac2> References: <017301c3c3be$75f6b190$0c01a8c0@cfsc8hf7h1aac2> Message-ID: On 12/16/2003 6:21 PM +0800, hitao wrote: > I want to modify bugzilla so that we can define groups as member of other > groups to gain more flexible access controls. Will it be hard and is there > anybody have experience on this to share? Bugzilla already does that. :) Requires version 2.17.1 or later. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From chicks at chicks.net Tue Dec 16 19:04:58 2003 From: chicks at chicks.net (Christopher Hicks) Date: Tue, 16 Dec 2003 14:04:58 -0500 (EST) Subject: Of CSS and XHTML (was: Re: J2EE) In-Reply-To: Message-ID: On Thu, 4 Dec 2003, David Miller wrote: > We have a member of the Bugzilla reviewer team that still uses it, and > he complains very loudly when we do anything that breaks it. He claims > his computer is too old and won't run any newer browsers. Firebird runs on slow machines quite snappily. I haven't run it head-to-head against NS4, but in my experience NS4 wasn't all that speedy anyway. -- No, no, you're not thinking, you're just being logical. -Niels Bohr, physicist (1885-1962) From mattyt-spam at tpg.com.au Wed Dec 17 04:19:32 2003 From: mattyt-spam at tpg.com.au (MattyT) Date: Wed, 17 Dec 2003 14:49:32 +1030 Subject: Please Help : Developers' Guide Update In-Reply-To: References: <1071310468.14635.30.camel@megagerbil> Message-ID: <1071634771.1392.16.camel@megagerbil> On Sun, 2003-12-14 at 08:01, Jouni Heikniemi wrote: > Most of the time, it suffices when you think these things through > and, if necessary, add OS checks to bypass Unix-only code. I'll > assist in coming up with Win32 alternatives when necessary. I need some more details with this. What is the proper way of doing OS checks? What is the proper way of distinguishing ActiveState and cygwin? >> Brief description about the mailing lists ... etiquette? > Shouldn't this be on the discussion page instead of dev guide? This was referring more to developer specific etiquette. > A couple of other points worth mentioning, although I'm not the resident > guru on these: > - Template naming (see discussion a few weeks ago on reviewers@). The > current text on this is fairly close to the consensus reached, though. I caught up by using my eyes a bit and the delete key a lot. Could someone please tell me, what, if anything needs to be changed here. > - Using filterexceptions.pl (see bug 225703 comments 19-21) I will add this under a new section about the filter tests. > - Maintaining customizable terms: We now have "[% terms.Bug %] instead of > "Bug" and so on. Discuss the reasons and best practices. I already have something along these lines locally, as I've already been through the test suite. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From mattyt-spam at tpg.com.au Wed Dec 17 06:20:07 2003 From: mattyt-spam at tpg.com.au (MattyT) Date: Wed, 17 Dec 2003 16:50:07 +1030 Subject: New Guide Uploaded In-Reply-To: <1071310468.14635.30.camel@megagerbil> References: <1071310468.14635.30.camel@megagerbil> Message-ID: <1071642006.1392.18.camel@megagerbil> On Sat, 2003-12-13 at 20:44, MattyT wrote: > The developers' guide is getting somewhat outdated now. It quite > incomplete, and even incorrect in places now. I've caught up somewhat > so I'll be taking a look at updating it, before I look at getting my > other Bugzilla commitments under control. I've uploaded a new version, but there's still plenty of work to do. I still need most of my points answered. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From justdave at bugzilla.org Wed Dec 17 06:22:22 2003 From: justdave at bugzilla.org (David Miller) Date: Wed, 17 Dec 2003 01:22:22 -0500 Subject: New Guide Uploaded In-Reply-To: <1071642006.1392.18.camel@megagerbil> References: <1071310468.14635.30.camel@megagerbil> <1071642006.1392.18.camel@megagerbil> Message-ID: On 12/17/2003 4:50 PM +1030, MattyT wrote: > On Sat, 2003-12-13 at 20:44, MattyT wrote: > >> The developers' guide is getting somewhat outdated now. It quite >> incomplete, and even incorrect in places now. I've caught up somewhat >> so I'll be taking a look at updating it, before I look at getting my >> other Bugzilla commitments under control. > > I've uploaded a new version, but there's still plenty of work to do. I > still need most of my points answered. That's http://www.bugzilla.org/developerguide.html for those that are wondering. :) (Also available from the bottom half of the documentation page on the website) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From jth at mikrobitti.fi Wed Dec 17 07:08:24 2003 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Wed, 17 Dec 2003 09:08:24 +0200 Subject: Please Help : Developers' Guide Update In-Reply-To: <1071634771.1392.16.camel@megagerbil> References: <1071310468.14635.30.camel@megagerbil> Message-ID: <5.1.0.14.2.20031217090158.02bd2920@mikrobitti.fi> At 14:49 17.12.2003 +1030, you wrote: >I need some more details with this. What is the proper way of doing OS >checks? if ($^O ~= /MSWin/) > What is the proper way of distinguishing ActiveState and >cygwin? if ($^O ~= /cygwin/) "MSWin" is returned by Activestate, Cygwin returns "cygwin". So far we haven't had the need to check for cygwin anywhere; all the Win32 checks have been made for Activestate. Also see bug 224588; I'm going to unify this stuff someday. > - Template naming (see discussion a few weeks ago on reviewers@). The > > current text on this is fairly close to the consensus reached, though. >I caught up by using my eyes a bit and the delete key a lot. Could >someone please tell me, what, if anything needs to be changed here. Myk summarized it by the following: - multiple related templates grouped together in a subdirectory; - template names non-redundant with the subdirectory name; - multiple words separated by dashes; - names indicating action in verb-noun form; - consistent with other template names or inconsistent for good reason. ... which was fairly well accepted. You can check out the list archive if you need more details. Jouni From gerv at mozilla.org Wed Dec 17 08:28:26 2003 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 17 Dec 2003 08:28:26 +0000 Subject: [Fwd: [Bug 1637] New: Spider hole filled with dictator] Message-ID: <3FE013AA.9080206@mozilla.org> Gerv -------- Original Message -------- Subject: [Bug 1637] New: Spider hole filled with dictator Date: Tue, 16 Dec 2003 07:15:32 -0800 From: bugzilla-daemon at landfill.office.mozilla.org To: gerv at mozilla.org http://landfill.bugzilla.org/bugzilla-tip/show_bug.cgi?id=1637 Summary: Spider hole filled with dictator Product: Spider Secretions Version: unspecified Platform: Macintosh OS/Version: Linux Status: NEW Severity: normal Priority: P1 Component: Venom AssignedTo: gerv at mozilla.org ReportedBy: t2dave at yahoo.com Estimated Hours: 0.0 Spider hole found to be filled with dictator. From bikash.x.karmakar at verizon.com Wed Dec 17 09:35:48 2003 From: bikash.x.karmakar at verizon.com (bikash.x.karmakar at verizon.com) Date: Wed, 17 Dec 2003 03:35:48 -0600 Subject: Bugzilla Help needed Message-ID: Hi All I am trying to install Bugzilla on linux . I am getting an error 'Premature End of script headers' when trying to invoke the cgi from the browser.but the same cgi works well when invoked from shell prompt(No compilation errors). The contents of the file are as follows #!/usr/bin/perl -w << -w! print "Content-type: text/html\n\n"; $x="10+20"; print "$x"; print "Hello!
" x 10; Please help me ...... Thanks and Regards Bikash Karmakar Verizon Data Services India. From justdave at bugzilla.org Wed Dec 17 09:57:35 2003 From: justdave at bugzilla.org (David Miller) Date: Wed, 17 Dec 2003 04:57:35 -0500 Subject: Bugzilla Help needed In-Reply-To: References: Message-ID: On 12/17/2003 3:35 AM -0600, bikash.x.karmakar at verizon.com wrote: > I am trying to install Bugzilla on linux . I am getting an error 'Premature > End of script headers' when trying to invoke the cgi from the browser.but > the same cgi works well when invoked from shell prompt(No compilation > errors). What's it say in the webserver's error log? -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bikash.x.karmakar at verizon.com Wed Dec 17 10:26:10 2003 From: bikash.x.karmakar at verizon.com (bikash.x.karmakar at verizon.com) Date: Wed, 17 Dec 2003 04:26:10 -0600 Subject: Bugzilla Help needed Message-ID: David The apache logs contains this ......i am trying to run test.cgi from the browser . [Tue Dec 16 18:38:10 2003] [notice] caught SIGTERM, shutting down [Tue Dec 16 18:38:14 2003] [notice] Apache/1.3.23 (Unix) (Red-Hat/Linux) mod_python/2.7.6 Python/1.5.2 mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26 mod_throttle/3.1.2 configured -- resuming normal operations [Tue Dec 16 18:38:14 2003] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Dec 16 18:38:14 2003] [notice] Accept mutex: sysvsem (Default: sysvsem) [Wed Dec 17 15:01:35 2003] [error] (13)Permission denied: exec of /root/bugtracker/temp/bugzilla-2.16.4/test.cgi failed [Wed Dec 17 15:01:35 2003] [error] [client 127.0.0.1] Premature end of script headers: /root/bugtracker/temp/bugzilla-2.16.4/test.cgi Thanks and Regards Bikash Karmakar Verizon Data Services India "David Miller" cc: Sent by: Subject: Re: Bugzilla Help needed developers-owner at b ugzilla.org 12/17/2003 03:57 AM Please respond to developers On 12/17/2003 3:35 AM -0600, bikash.x.karmakar at verizon.com wrote: > I am trying to install Bugzilla on linux . I am getting an error 'Premature > End of script headers' when trying to invoke the cgi from the browser.but > the same cgi works well when invoked from shell prompt(No compilation > errors). What's it say in the webserver's error log? -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ - To view or change your list settings, click here: From andreas.hoefler at bearingpoint.com Wed Dec 17 10:34:15 2003 From: andreas.hoefler at bearingpoint.com (=?ISO-8859-1?Q?Andreas_H=F6fler?=) Date: Wed, 17 Dec 2003 11:34:15 +0100 Subject: Bugzilla Help needed In-Reply-To: References: Message-ID: <3FE03127.3090807@bearingpoint.com> bikash.x.karmakar at verizon.com wrote: > The apache logs contains this ......i am trying to run test.cgi from the > browser . > > Re: Bugzilla Help needed > > [Tue Dec 16 18:38:10 2003] [notice] caught SIGTERM, shutting down > [Tue Dec 16 18:38:14 2003] [notice] Apache/1.3.23 (Unix) (Red-Hat/Linux) > mod_python/2.7.6 Python/1.5.2 mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 > PHP/4.1.2 mod_perl/1.26 mod_throttle/3.1.2 configured -- resuming normal > operations > [Tue Dec 16 18:38:14 2003] [notice] suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > [Tue Dec 16 18:38:14 2003] [notice] Accept mutex: sysvsem (Default: > sysvsem) > [Wed Dec 17 15:01:35 2003] [error] (13)Permission denied: exec of > /root/bugtracker/temp/bugzilla-2.16.4/test.cgi failed > You don't make a cgi-script with root-privileges accessible from network do you??? Is the executable-bit set for this cgi-file? chmod u+x /root/bugtracker/temp/bugzilla-2.16.4/test.cgi best regards, Andreas From justdave at bugzilla.org Wed Dec 17 10:35:55 2003 From: justdave at bugzilla.org (David Miller) Date: Wed, 17 Dec 2003 05:35:55 -0500 Subject: Bugzilla Help needed In-Reply-To: References: Message-ID: On 12/17/2003 4:26 AM -0600, bikash.x.karmakar at verizon.com wrote: > David > The apache logs contains this ......i am trying to run test.cgi from the > browser . > > [Tue Dec 16 18:38:10 2003] [notice] caught SIGTERM, shutting down > [Tue Dec 16 18:38:14 2003] [notice] Apache/1.3.23 (Unix) (Red-Hat/Linux) > mod_python/2.7.6 Python/1.5.2 mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 > PHP/4.1.2 mod_perl/1.26 mod_throttle/3.1.2 configured -- resuming normal > operations > [Tue Dec 16 18:38:14 2003] [notice] suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > [Tue Dec 16 18:38:14 2003] [notice] Accept mutex: sysvsem (Default: > sysvsem) > [Wed Dec 17 15:01:35 2003] [error] (13)Permission denied: exec of > /root/bugtracker/temp/bugzilla-2.16.4/test.cgi failed > [Wed Dec 17 15:01:35 2003] [error] [client 127.0.0.1] Premature end of > script headers: /root/bugtracker/temp/bugzilla-2.16.4/test.cgi Permission denied about sums it up. Set the permissions on the file so the webserver can see and run it. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bikash.x.karmakar at verizon.com Wed Dec 17 10:42:37 2003 From: bikash.x.karmakar at verizon.com (bikash.x.karmakar at verizon.com) Date: Wed, 17 Dec 2003 04:42:37 -0600 Subject: Bugzilla Help needed Message-ID: Andreas The executable-bit is set for this cgi-file and the error logs is as follows [Wed Dec 17 16:10:10 2003] [error] (13)Permission denied: exec of /root/bugtracker/temp/bugzilla-2.16.4/test.cgi failed [Wed Dec 17 16:10:10 2003] [error] [client 127.0.0.1] Premature end of script headers: /root/bugtracker/temp/bugzilla-2.16.4/test.cgi Can you please help me out with this.... Thanks and Regards Bikash Karmakar Verizon Data Services "Andreas H?fler" cc: Sent by: Subject: Re: Bugzilla Help needed developers-owner at bugzil la.org 12/17/2003 04:34 AM Please respond to developers bikash.x.karmakar at verizon.com wrote: > The apache logs contains this ......i am trying to run test.cgi from the > browser . > > Re: Bugzilla Help needed > > [Tue Dec 16 18:38:10 2003] [notice] caught SIGTERM, shutting down > [Tue Dec 16 18:38:14 2003] [notice] Apache/1.3.23 (Unix) (Red-Hat/Linux) > mod_python/2.7.6 Python/1.5.2 mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 > PHP/4.1.2 mod_perl/1.26 mod_throttle/3.1.2 configured -- resuming normal > operations > [Tue Dec 16 18:38:14 2003] [notice] suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > [Tue Dec 16 18:38:14 2003] [notice] Accept mutex: sysvsem (Default: > sysvsem) > [Wed Dec 17 15:01:35 2003] [error] (13)Permission denied: exec of > /root/bugtracker/temp/bugzilla-2.16.4/test.cgi failed > You don't make a cgi-script with root-privileges accessible from network do you??? Is the executable-bit set for this cgi-file? chmod u+x /root/bugtracker/temp/bugzilla-2.16.4/test.cgi best regards, Andreas - To view or change your list settings, click here: From bikash.x.karmakar at verizon.com Wed Dec 17 10:44:50 2003 From: bikash.x.karmakar at verizon.com (bikash.x.karmakar at verizon.com) Date: Wed, 17 Dec 2003 04:44:50 -0600 Subject: Bugzilla Help needed Message-ID: David The permission is set . But still i get the same error. The error log now shows [Wed Dec 17 16:15:40 2003] [error] (13)Permission denied: exec of /root/bugtracker/temp/bugzilla-2.16.4/test.cgi failed [Wed Dec 17 16:15:40 2003] [error] [client 127.0.0.1] Premature end of script headers: /root/bugtracker/temp/bugzilla-2.16.4/test.cgi Thnaks and Regards Bikash Karmakar Verizon Data Services "David Miller" cc: Sent by: Subject: Re: Bugzilla Help needed developers-owner at b ugzilla.org 12/17/2003 04:35 AM Please respond to developers On 12/17/2003 4:26 AM -0600, bikash.x.karmakar at verizon.com wrote: > David > The apache logs contains this ......i am trying to run test.cgi from the > browser . > > [Tue Dec 16 18:38:10 2003] [notice] caught SIGTERM, shutting down > [Tue Dec 16 18:38:14 2003] [notice] Apache/1.3.23 (Unix) (Red-Hat/Linux) > mod_python/2.7.6 Python/1.5.2 mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 > PHP/4.1.2 mod_perl/1.26 mod_throttle/3.1.2 configured -- resuming normal > operations > [Tue Dec 16 18:38:14 2003] [notice] suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > [Tue Dec 16 18:38:14 2003] [notice] Accept mutex: sysvsem (Default: > sysvsem) > [Wed Dec 17 15:01:35 2003] [error] (13)Permission denied: exec of > /root/bugtracker/temp/bugzilla-2.16.4/test.cgi failed > [Wed Dec 17 15:01:35 2003] [error] [client 127.0.0.1] Premature end of > script headers: /root/bugtracker/temp/bugzilla-2.16.4/test.cgi Permission denied about sums it up. Set the permissions on the file so the webserver can see and run it. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ - To view or change your list settings, click here: From Sankalp.Ahuja at tietoenator.com Wed Dec 17 10:45:14 2003 From: Sankalp.Ahuja at tietoenator.com (Sankalp.Ahuja at tietoenator.com) Date: Wed, 17 Dec 2003 12:45:14 +0200 Subject: Bugzilla Help needed Message-ID: <60532B15DF92FD4693AA89B2F7E01D8F6EA011@tmex02> Check the file permissions Sankalp -----Original Message----- From: bikash.x.karmakar at verizon.com [mailto:bikash.x.karmakar at verizon.com] Sent: 17. December 2003 12:26 To: developers at bugzilla.org Subject: Re: Bugzilla Help needed David The apache logs contains this ......i am trying to run test.cgi from the browser . [Tue Dec 16 18:38:10 2003] [notice] caught SIGTERM, shutting down [Tue Dec 16 18:38:14 2003] [notice] Apache/1.3.23 (Unix) (Red-Hat/Linux) mod_python/2.7.6 Python/1.5.2 mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 PHP/4.1.2 mod_perl/1.26 mod_throttle/3.1.2 configured -- resuming normal operations [Tue Dec 16 18:38:14 2003] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Dec 16 18:38:14 2003] [notice] Accept mutex: sysvsem (Default: sysvsem) [Wed Dec 17 15:01:35 2003] [error] (13)Permission denied: exec of /root/bugtracker/temp/bugzilla-2.16.4/test.cgi failed [Wed Dec 17 15:01:35 2003] [error] [client 127.0.0.1] Premature end of script headers: /root/bugtracker/temp/bugzilla-2.16.4/test.cgi Thanks and Regards Bikash Karmakar Verizon Data Services India "David Miller" cc: Sent by: Subject: Re: Bugzilla Help needed developers-owner at b ugzilla.org 12/17/2003 03:57 AM Please respond to developers On 12/17/2003 3:35 AM -0600, bikash.x.karmakar at verizon.com wrote: > I am trying to install Bugzilla on linux . I am getting an error 'Premature > End of script headers' when trying to invoke the cgi from the browser.but > the same cgi works well when invoked from shell prompt(No compilation > errors). What's it say in the webserver's error log? -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ - To view or change your list settings, click here: - To view or change your list settings, click here: From Sankalp.Ahuja at tietoenator.com Wed Dec 17 10:48:26 2003 From: Sankalp.Ahuja at tietoenator.com (Sankalp.Ahuja at tietoenator.com) Date: Wed, 17 Dec 2003 12:48:26 +0200 Subject: Bugzilla Help needed Message-ID: <60532B15DF92FD4693AA89B2F7E01D8F6EA012@tmex02> Also check the permission on "Bugs" database for user 'bugs' if u are using default settings for ur installation. -----Original Message----- From: bikash.x.karmakar at verizon.com [mailto:bikash.x.karmakar at verizon.com] Sent: 17. December 2003 12:45 To: developers at bugzilla.org Cc: developers at bugzilla.org; developers-owner at bugzilla.org Subject: Re: Bugzilla Help needed David The permission is set . But still i get the same error. The error log now shows [Wed Dec 17 16:15:40 2003] [error] (13)Permission denied: exec of /root/bugtracker/temp/bugzilla-2.16.4/test.cgi failed [Wed Dec 17 16:15:40 2003] [error] [client 127.0.0.1] Premature end of script headers: /root/bugtracker/temp/bugzilla-2.16.4/test.cgi Thnaks and Regards Bikash Karmakar Verizon Data Services "David Miller" cc: Sent by: Subject: Re: Bugzilla Help needed developers-owner at b ugzilla.org 12/17/2003 04:35 AM Please respond to developers On 12/17/2003 4:26 AM -0600, bikash.x.karmakar at verizon.com wrote: > David > The apache logs contains this ......i am trying to run test.cgi from the > browser . > > [Tue Dec 16 18:38:10 2003] [notice] caught SIGTERM, shutting down > [Tue Dec 16 18:38:14 2003] [notice] Apache/1.3.23 (Unix) (Red-Hat/Linux) > mod_python/2.7.6 Python/1.5.2 mod_ssl/2.8.7 OpenSSL/0.9.6b DAV/1.0.3 > PHP/4.1.2 mod_perl/1.26 mod_throttle/3.1.2 configured -- resuming normal > operations > [Tue Dec 16 18:38:14 2003] [notice] suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > [Tue Dec 16 18:38:14 2003] [notice] Accept mutex: sysvsem (Default: > sysvsem) > [Wed Dec 17 15:01:35 2003] [error] (13)Permission denied: exec of > /root/bugtracker/temp/bugzilla-2.16.4/test.cgi failed > [Wed Dec 17 15:01:35 2003] [error] [client 127.0.0.1] Premature end of > script headers: /root/bugtracker/temp/bugzilla-2.16.4/test.cgi Permission denied about sums it up. Set the permissions on the file so the webserver can see and run it. :) -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ - To view or change your list settings, click here: - To view or change your list settings, click here: From andreas.hoefler at bearingpoint.com Wed Dec 17 10:50:07 2003 From: andreas.hoefler at bearingpoint.com (=?ISO-8859-1?Q?Andreas_H=F6fler?=) Date: Wed, 17 Dec 2003 11:50:07 +0100 Subject: Bugzilla Help needed In-Reply-To: References: Message-ID: <3FE034DF.5030407@bearingpoint.com> An HTML attachment was scrubbed... URL: From kiko at async.com.br Wed Dec 17 11:50:58 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Wed, 17 Dec 2003 09:50:58 -0200 Subject: Bugzilla Help needed In-Reply-To: <3FE034DF.5030407@bearingpoint.com> References: <3FE034DF.5030407@bearingpoint.com> Message-ID: <20031217115058.GA537@async.com.br> On Wed, Dec 17, 2003 at 11:50:07AM +0100, Andreas H?fler wrote: > Quick guess: > perhaps one or more of the directories are unaccessible > for the webserver-user Why is this being discussed on the developer list? Please, use the newsgroups. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From kiko at async.com.br Wed Dec 17 12:34:14 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Wed, 17 Dec 2003 10:34:14 -0200 Subject: New Guide Uploaded In-Reply-To: References: <1071310468.14635.30.camel@megagerbil> <1071642006.1392.18.camel@megagerbil> Message-ID: <20031217123414.GB810@async.com.br> On Wed, Dec 17, 2003 at 01:22:22AM -0500, David Miller wrote: > That's http://www.bugzilla.org/developerguide.html for those that are > wondering. :) (Also available from the bottom half of the documentation > page on the website) Oh, pleased to meet you. In what format is that kept? It would be really nice if it was broken into smaller, more manageable (and readable) sections. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From kiko at async.com.br Wed Dec 17 12:59:57 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Wed, 17 Dec 2003 10:59:57 -0200 Subject: New Guide Uploaded In-Reply-To: References: <1071310468.14635.30.camel@megagerbil> <1071642006.1392.18.camel@megagerbil> Message-ID: <20031217125957.GC810@async.com.br> Random bits from perusing the text: On Wed, Dec 17, 2003 at 01:22:22AM -0500, David Miller wrote: > >> The developers' guide is getting somewhat outdated now. It quite > >> incomplete, and even incorrect in places now. I've caught up somewhat > >> so I'll be taking a look at updating it, before I look at getting my > >> other Bugzilla commitments under control. Ah, there's the bits on Licensing that I discussed with Gerv a while back here, related to templatizing: when templatizing a file [] the original CGI file's copyright assignee should be the assignee of the new template, and the developer hacking the template should be added to the list of contributors. It would be nice to have a link from there to a boilerplate that could be browsed and cut-n-pasted. CVS and Submitting your patch should be merged. Does cvs diff -p manage to get Perl function names correctly? If so, it's nice to add. -N is relevant too. Perhaps a tip about cvsdo which allows you to produce diffs with added files without write access. A proposed subdivision for the document: # Introduction # Perl - General - Style - SQL # Templates - General - Web/HTML (Web Technologies) - Style # Contributing Code - Licensing - Process - Patches - Testing # Security I gave Vladd a tip the other day for testing HTML compliance of non-public pages -- after changing a template, generate the HTML code and run it through the W3C validator. Yes, we have Email Templates now, check out templates ending with .txt, specifically: ./account/cancel-token.txt.tmpl ./account/email/change-new.txt.tmpl ./account/email/change-old.txt.tmpl ./account/password/forgotten-password.txt.tmpl ./bug/create/comment-guided.txt.tmpl ./bug/create/comment.txt.tmpl ./request/email.txt.tmpl There should be a note suggesting the use of DBI wherever new SQL code is written. Hmmm, there's something emerging in the realm of cookies and authentication that Dave, Bradley and I were discussing, but I don't have it solid enough to be able to suggest a section, but I will once it is. [] such as the onslaught of edit*.cgi templates that Vladd's going to perform in the next couple of days Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From mkanat at kerio.com Thu Dec 18 21:29:40 2003 From: mkanat at kerio.com (Maxwell Kanat-Alexander) Date: Thu, 18 Dec 2003 13:29:40 -0800 Subject: DevGuide Comments Message-ID: <1071782979.10545.36.camel@localhost.localdomain> Hey, the DevGuide looks great! The styles are excellent. A few comments: + Typo: "You should only you these if you have ensured the platform isn't ActiveState." -- "you these" + That INNER JOIN comment isn't valid anymore: yes, INNER JOIN is legal now because we now require a new enough version of MySQL that supports it. in fact, it's preferred in most cases, because the SQL is easier to read and parse :) + In the HTML Templates section, it says that template output should start with [print "Content-type: text/html\n\n";]. I don't see that in cvs-tip cgi's... Isn't it something like "print $cgi->header()"? + In the "submitting your patch" section, you might want to mention about what directory level to run a diff -Nru from, if it spans multiple directories. It would mean that people applying patches wouldn't have to worry about whether it was -p0 or -p1 or no -p at all. + "first-review" and "second-review" are "review" and "super-review" now, aren't they? + Typo: (same sentence as above) "and there is no other reasons" -- should be "are" instead of "is" -M -- Maxwell Kanat-Alexander 2nd Level Tech Support Engineer, USA Kerio Technologies, Inc. 2041 Mission College Blvd. Suite 100 Santa Clara, CA 95054 Phone: (408) 496-4500 x23 Fax: (408) 496-6902 Web: http://www.kerio.com/support.html From mattyt-spam at tpg.com.au Fri Dec 19 05:55:01 2003 From: mattyt-spam at tpg.com.au (MattyT) Date: Fri, 19 Dec 2003 16:25:01 +1030 Subject: DevGuide Comments In-Reply-To: <1071782979.10545.36.camel@localhost.localdomain> References: <1071782979.10545.36.camel@localhost.localdomain> Message-ID: <1071813297.897.32.camel@megagerbil> On Fri, 2003-12-19 at 07:59, Maxwell Kanat-Alexander wrote: > + Typo: "You should only you these if you have ensured the platform > isn't ActiveState." -- "you these" Fixed on my HDD. > + That INNER JOIN comment isn't valid anymore: > yes, INNER JOIN is legal now > because we now require a new enough version of MySQL that > supports it. > in fact, it's preferred in most cases, because the SQL is > easier to read and parse :) I have removed the part about MySQL, but the part about PgSQL is just as valid now as when I wrote it. Dave was not aware of the full ramifications of INNER JOIN, and I have not heard any discussion about changing the policy. That it's easier to read is a matter of opinion. I have updated the guide to better explain the problems of INNER JOIN. > + In the HTML Templates section, it says that template output should > start with [print "Content-type: text/html\n\n";]. I don't see that in > cvs-tip cgi's... Isn't it something like "print $cgi->header()"? Possibly this has changed, but the guide isn't changing until I hear what it should be replaced with. It's just as likely the tip is wrong. > + In the "submitting your patch" section, you might want to mention > about what directory level to run a diff -Nru from, if it spans multiple > directories. It would mean that people applying patches wouldn't have to > worry about whether it was -p0 or -p1 or no -p at all. I'm not sure we should specify this. Shouldn't it be obvious from the context? Sometimes people might have multiple changes to their tree, but only want to diff one subdirectory. Or does it work if you do it from Bugzilla root and specify a subdirectory? > + "first-review" and "second-review" are "review" and "super-review" > now, aren't they? Probably. I'll change it when I hear the full procedure outlined. > + Typo: (same sentence as above) "and there is no other reasons" -- > should be "are" instead of "is" Fixed on my HDD. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From justdave at bugzilla.org Fri Dec 19 06:11:48 2003 From: justdave at bugzilla.org (David Miller) Date: Fri, 19 Dec 2003 01:11:48 -0500 Subject: DevGuide Comments In-Reply-To: <1071813297.897.32.camel@megagerbil> References: <1071782979.10545.36.camel@localhost.localdomain> <1071813297.897.32.camel@megagerbil> Message-ID: On 12/19/2003 4:25 PM +1030, MattyT wrote: > On Fri, 2003-12-19 at 07:59, Maxwell Kanat-Alexander wrote: > >> + In the HTML Templates section, it says that template output should >> start with [print "Content-type: text/html\n\n";]. I don't see that in >> cvs-tip cgi's... Isn't it something like "print $cgi->header()"? > > Possibly this has changed, but the guide isn't changing until I hear > what it should be replaced with. It's just as likely the tip is wrong. It should be print $cgi->header();, and you can optionally specify the mime-type for the output as an argument to header(). $cgi is obtained from Bugzilla->cgi; if you don't have it in scope of your current code yet (which also means if the header is the only thing you're using $cgi for you can just do print Bugzilla->cgi->header();) We use the official Perl CGI API now for everything, although we do still have backward compatibility hacks in place to allow things like %::FORM and %::COOKIE to still work until someone gets around to replacing them all (which will have to happen before we can support mod_perl). There are a few exceptions, like setting cookies. We have convenience functions in Bugzilla::CGI which cache your cookies so you don't have to remember to pass them to header() for example. >> + In the "submitting your patch" section, you might want to mention >> about what directory level to run a diff -Nru from, if it spans multiple >> directories. It would mean that people applying patches wouldn't have to >> worry about whether it was -p0 or -p1 or no -p at all. > > I'm not sure we should specify this. Shouldn't it be obvious from the > context? Sometimes people might have multiple changes to their tree, > but only want to diff one subdirectory. Or does it work if you do it > from Bugzilla root and specify a subdirectory? Yes, it works if you specify a subdirectory. Ideally, all patches should be created from within the bugzilla directory, so that they can be applied from that directory with a -p0 argument to patch. A -p1 is also acceptable if you don't have cvs handy and have to compare two bugzilla directories (in which case you would be one level above when you make it). If you do it from one level up, make sure you say so on your attachment description for the convenience of those applying the patch. (Just "(use -p1)" on the end is fine) >> + "first-review" and "second-review" are "review" and "super-review" >> now, aren't they? > > Probably. I'll change it when I hear the full procedure outlined. We have "review" and "approval" at our disposal. Review is multiply-requestable, meaning you can request more than one. Reviews need to be made by people on the approved reviewers list (which is a little out of date at the moment - I'll get that updated soon). At least one is required, and the person granting the first one has discretion to decide if a second one is needed. A second review is mandatory for security bugs. Once a patch is reviewed and ready to check in, "approval" is requested on the bug, which can only be granted by myself or Myk. Once approval is granted, the patch author can check in the patch (or someone else if the author doesn't have cvs write access). -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From justdave at bugzilla.org Fri Dec 19 06:46:21 2003 From: justdave at bugzilla.org (David Miller) Date: Fri, 19 Dec 2003 01:46:21 -0500 Subject: Please Help : Developers' Guide Update In-Reply-To: <1071310468.14635.30.camel@megagerbil> References: <1071310468.14635.30.camel@megagerbil> Message-ID: On 12/13/2003 8:44 PM +1030, MattyT wrote: > What needs to be done to not break mod_perl? Follow the mod_perl programming guides on http://perl.apache.org/ :) Seriously, there's a lot to consider to try to explain it in our guide. The big things though, are to avoid global variables anywhere, and avoid using variables that were created outside the scope of your current sub in CGI files. (It works fine in the .pm files, but in the CGIs it'll choke bigtime because of the way mod_perl dynamically loads the files - see bug 173629 for the details on that one) > Some high level documentation about the new modules, especially how the > new DB stuff replaces the old stuff. http://www.bugzilla.org/docs/pod/ Not all the modules have documentation in them yet. If you click on a pm file and get no output, that's why. Most of the newer ones have pretty decent docs in them. > Module conventions? Module naming? File naming? Paths? Existing docs still apply for this. (There's docs somewhere, if they're not already in the guide, I've seen them) > Does the use of OO in the new modules warrant any style conventions > being added? More than likely. bbaetz would be the best person to answer that probably. > Are we using exceptions yet? No. > Are we using placeholders yet? If so, any restrictions? If not, why > not? We're planning to. We are in a few places. It's strongly recommended to whenever possible. :) It breaks things on inserts where we need to retrieve the new key that was generated on Sybase, but oh well. Sybase has a somewhat stupid implementation of placeholders. But folks who really want it reliable on Sybase will just have to work out their own problems. :) (I can document some of it for them once we get it to the point it'll be easy to modify things - Bugzilla will never run Sybase out of the box for that and a couple other reasons, but we can certainly get the Sybase support in the app to the point where the modifications needed are minimal). > Is $vars still in use? Any changes? Yes. No. > More comments on performance? What to avoid? use diagnostics -> > warnings? ALWAYS use -w. Don't |use diagnostics|. You can look up the error codes in the man page if you care about the long-winded paragraphs, and it has a substantial negative affect on compile time. > Are we using any email templates yet? There are a couple. Not all of them are yet. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Fri Dec 19 08:04:07 2003 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 19 Dec 2003 08:04:07 +0000 Subject: Template versioning In-Reply-To: References: <3FD5D4D4.8010505@mozilla.org> <20031209145509.GA1333@async.com.br> <3FDB880B.60405@mozilla.org> <20031215172406.GA670@async.com.br> <20031215202029.GB1470@async.com.br> Message-ID: <3FE2B0F7.9080703@mozilla.org> Jouni Heikniemi wrote: > Thought wandering a bit elsewhere, here: Our stable branches have been > fairly locked up, but is this because there's nobody to maintain the > stable ones or is it because we really think it's a good idea to totally > freeze the stable versions? The latter, I would say. > I was thinking, if the Bugzilla developer base grows significantly, I > don't see it as impossible that we may some day have a "stable dev group", > who integrate the best patches from trunk into stable versions. This would > allow us to make it easy for those using the stable branch to get the > best minor enhancements and most important bug fixes without getting the > instability of heavy structural rewrites that occur in the trunk. I think we need to deal with the problem in another way suggested recently - and that's to make stable releases more often, with fewer new features. That's the best way to get new features out to the masses IMO. Gerv From gerv at mozilla.org Fri Dec 19 08:28:56 2003 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 19 Dec 2003 08:28:56 +0000 Subject: New Guide Uploaded In-Reply-To: <1071642006.1392.18.camel@megagerbil> References: <1071310468.14635.30.camel@megagerbil> <1071642006.1392.18.camel@megagerbil> Message-ID: <3FE2B6C8.9040003@mozilla.org> MattyT wrote: > I've uploaded a new version, but there's still plenty of work to do. I > still need most of my points answered. Looking good. I don't have time to comment further now, but it could do with more links (e.g. to variables.none.tmpl in LXR), and some of the coding stuff (e.g. $::user) needs updating to say e.g. Bugzilla->user instead. Gerv From mattyt-spam at tpg.com.au Fri Dec 19 10:12:44 2003 From: mattyt-spam at tpg.com.au (MattyT) Date: Fri, 19 Dec 2003 20:42:44 +1030 Subject: Suggestions for additions to DevGuide. Message-ID: <1071824764.896.34.camel@megagerbil> What does everyone think of these as new bits for the DevGuide: Addition of "XXX" as the standard for FIXME comments. Preferring "LEFT JOIN" over "LEFT OUTER JOIN" and so on. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From mattyt-spam at tpg.com.au Fri Dec 19 10:16:20 2003 From: mattyt-spam at tpg.com.au (MattyT) Date: Fri, 19 Dec 2003 20:46:20 +1030 Subject: DevGuide Comments In-Reply-To: References: <1071782979.10545.36.camel@localhost.localdomain> <1071813297.897.32.camel@megagerbil> Message-ID: <1071825472.896.47.camel@megagerbil> On Fri, 2003-12-19 at 16:41, David Miller wrote: > although we do still have backward compatibility > hacks in place to allow things like %::FORM and %::COOKIE to still work > until someone gets around to replacing them all (which will have to happen > before we can support mod_perl). There are a few exceptions, like setting > cookies. We have convenience functions in Bugzilla::CGI which cache your > cookies so you don't have to remember to pass them to header() for example. OK, it's probably worthwhile tutorialising these APIs somewhere online, but I probably can't be bothered until it's mod_perl and no-CGI.pl settled. Everything else here is dealt with on my HDD I think. -- Matthew Tuck: Software Developer & All-Round Nice Guy My Short Autobiography: 1985 Grade Bin Monitor 1990 Class Clown Award 1992 Awarded Most Likely To Spontaneously Combust 1996 Crowned Galactic Emperor 1998 Released From Smith Psychiatric Hospital From colin at ogilvie.fsnet.co.uk Fri Dec 19 14:27:16 2003 From: colin at ogilvie.fsnet.co.uk (Colin S. Ogilvie) Date: Fri, 19 Dec 2003 14:27:16 +0000 Subject: DevGuide Comments In-Reply-To: <1071782979.10545.36.camel@localhost.localdomain> References: <1071782979.10545.36.camel@localhost.localdomain> Message-ID: <3FE30AC4.5050806@ogilvie.fsnet.co.uk> Maxwell Kanat-Alexander wrote: > Hey, the DevGuide looks great! The styles are excellent. > > A few comments: > Have one from me as well: "Curly Braces - The opening brace of a block should be on the same line as the statement that is causing the block and the closing brace should be at the same indentation level as that statement, for example: | if ($var) { print "The variable is true"; } else { print "Try again"; } | instead of this: | if ($var) { print "The variable is true"; } else { print "Try again"; }" Unless I am missing something really obvious, the Example and the Instead of are the same in this section? Regards, Colin | From justdave at bugzilla.org Fri Dec 19 17:51:47 2003 From: justdave at bugzilla.org (David Miller) Date: Fri, 19 Dec 2003 12:51:47 -0500 Subject: DevGuide Comments In-Reply-To: <3FE30AC4.5050806@ogilvie.fsnet.co.uk> References: <1071782979.10545.36.camel@localhost.localdomain> <3FE30AC4.5050806@ogilvie.fsnet.co.uk> Message-ID: On 12/19/2003 2:27 PM +0000, Colin S. Ogilvie wrote: > Maxwell Kanat-Alexander wrote: > > | if ($var) { > print "The variable is true"; > } > else { > print "Try again"; > } | > > instead of this: > > | if ($var) { > print "The variable is true"; > } else { > print "Try again"; > }" > > Unless I am missing something really obvious, the Example and the > Instead of are the same in this section? You're missing something obvious. :) Notice how the braces are wrapped around the "else". One of them has the braces on the same line, one has it linewrapped between them. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From bugzilla at ogilvie.fsnet.co.uk Fri Dec 19 18:03:17 2003 From: bugzilla at ogilvie.fsnet.co.uk (Colin S. Ogilvie) Date: Fri, 19 Dec 2003 18:03:17 +0000 Subject: DevGuide Comments In-Reply-To: References: <1071782979.10545.36.camel@localhost.localdomain> <3FE30AC4.5050806@ogilvie.fsnet.co.uk> Message-ID: <200312191803.17995.bugzilla@ogilvie.fsnet.co.uk> On Friday 19 Dec 2003 5:51 pm, you wrote: > You're missing something obvious. :) Notice how the braces are wrapped > around the "else". One of them has the braces on the same line, one has it > linewrapped between them. D'oh. No matter how long I stared at it I didn't notice it. -- Colin S. Ogilvie colin at ogilvie.fsnet.co.uk From kiko at async.com.br Mon Dec 22 17:24:35 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Mon, 22 Dec 2003 15:24:35 -0200 Subject: DevGuide Comments In-Reply-To: <1071813297.897.32.camel@megagerbil> References: <1071782979.10545.36.camel@localhost.localdomain> <1071813297.897.32.camel@megagerbil> Message-ID: <20031222172435.GD1284@async.com.br> This is redundant, but it was stuck in my queue so here it goes. On Fri, Dec 19, 2003 at 04:25:01PM +1030, MattyT wrote: > > + In the "submitting your patch" section, you might want to mention > > about what directory level to run a diff -Nru from, if it spans multiple > > directories. It would mean that people applying patches wouldn't have to > > worry about whether it was -p0 or -p1 or no -p at all. > > I'm not sure we should specify this. Shouldn't it be obvious from the > context? Sometimes people might have multiple changes to their tree, > but only want to diff one subdirectory. Or does it work if you do it > from Bugzilla root and specify a subdirectory? Patches should always be generated from the Bugzilla root -- otherwise, you'll need to futz with -pX to ensure it applies without prompts. Yes, it works when you do a cvs diff from the Bugzilla root and specify a subdir -- in fact, it's the right way to do it! > > + "first-review" and "second-review" are "review" and "super-review" > > now, aren't they? > > Probably. I'll change it when I hear the full procedure outlined. Actually, it's review and approval. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From bugreport at peshkin.net Tue Dec 23 01:39:24 2003 From: bugreport at peshkin.net (Joel Peshkin) Date: Mon, 22 Dec 2003 17:39:24 -0800 Subject: SOAP Message-ID: <3FE79CCC.3040301@peshkin.net> Hi All: I have been looking at SOAP and it looks like the right way to let javascript functions access databases so that mid-air checks can happen earliers, user matching can be done while editing (replacing wildcards and drop-down user pickers) and a whole lot more. Has anyone looked at this?? -Joel [ Aren't you glad you use SOAP, don't you wish everybody did?? ] From gerv at mozilla.org Tue Dec 23 08:38:54 2003 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 23 Dec 2003 08:38:54 +0000 Subject: SOAP In-Reply-To: <3FE79CCC.3040301@peshkin.net> References: <3FE79CCC.3040301@peshkin.net> Message-ID: <3FE7FF1E.5000905@mozilla.org> Joel Peshkin wrote: > I have been looking at SOAP and it looks like the right way to let > javascript functions access databases so that mid-air checks can happen > earliers, user matching can be done while editing (replacing wildcards > and drop-down user pickers) and a whole lot more. A few thoughts: What's the particular advantage of SOAP (which, as I understand it, is an XML wrapper format for wrapping more XML), given that browsers mostly don't support it natively? I think Moz might, a little bit, but IE doesn't as far as I know. Such checking could only be done in really modern browsers, anyway - older ones don't support JS fetching arbitrary documents without a page reload of some sort. Is it worth all the effort and added complexity that it would require? What is your "whole lot more"? :-) Mid-air checks can't be done earlier with 100% accuracy, of course, because if you check at some point before submission, you have to check again on submission anyway. Gerv From jth at mikrobitti.fi Tue Dec 23 09:10:48 2003 From: jth at mikrobitti.fi (Jouni Heikniemi) Date: Tue, 23 Dec 2003 11:10:48 +0200 Subject: SOAP In-Reply-To: <3FE7FF1E.5000905@mozilla.org> References: <3FE79CCC.3040301@peshkin.net> <3FE79CCC.3040301@peshkin.net> Message-ID: <5.1.0.14.2.20031223104614.04b6e008@mikrobitti.fi> At 08:38 23.12.2003 +0000, you wrote: >What's the particular advantage of SOAP (which, as I understand it, is an >XML wrapper format for wrapping more XML), given that browsers mostly >don't support it natively? I think Moz might, a little bit, but IE doesn't >as far as I know. SOAP itself is basically just a wrapper format, but related technologies form a framework that allows fairly straightforward remote method calls ("Web Services") in a standard way. Don't confuse those two: it's like judging WWW based on what HTTP is. >Is it worth all the effort and added complexity that it would require? >What is your "whole lot more"? :-) SOAP beats most of the other possible external API solutions because of its well-formalized and modern nature. This helps development enermously. Take .net framework for example: You just type in a url for the soap service and a developer tool generates a native language proxy class for the service (so your code doesn't even really know it's a remote call). For browsers, the situation isn't so great quite yet. Things are most likely getting better, though. As for code complexity, we should examine before we slash it. If an existing SOAP interface module for Perl suits our needs (as I'd expect to), the result may turn out very clean and efficient. I agree with Joel that SOAP is future, but don't have much ideas to help here. Designing proper Web service interfaces takes work and thought, and I haven't had the extra time (despite the fact that I've been wanting to create an experimental "mostRecentBugs" SOAP service for quite some time - I really could use that). Anyway, if you come up with something, I'll do my best to help. Jouni From kiko at async.com.br Tue Dec 23 15:16:03 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Tue, 23 Dec 2003 13:16:03 -0200 Subject: SOAP In-Reply-To: <3FE7FF1E.5000905@mozilla.org> References: <3FE79CCC.3040301@peshkin.net> <3FE7FF1E.5000905@mozilla.org> Message-ID: <20031223151603.GB1027@async.com.br> On Tue, Dec 23, 2003 at 08:38:54AM +0000, Gervase Markham wrote: > What's the particular advantage of SOAP (which, as I understand it, is > an XML wrapper format for wrapping more XML), given that browsers mostly > don't support it natively? I think Moz might, a little bit, but IE > doesn't as far as I know. Would it be a better or worse alternative to using XML-RPC, which is much simpler than SOAP? It would have the advantage of being very easily usable from many programming languages, and this is a subject that has been discussed before. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331 From bugreport at peshkin.net Tue Dec 23 16:44:01 2003 From: bugreport at peshkin.net (Joel Peshkin) Date: Tue, 23 Dec 2003 08:44:01 -0800 Subject: SOAP In-Reply-To: <20031223151603.GB1027@async.com.br> References: <3FE79CCC.3040301@peshkin.net> <3FE7FF1E.5000905@mozilla.org> <20031223151603.GB1027@async.com.br> Message-ID: <3FE870D1.1030106@peshkin.net> I guess I should broaden the question a bit and not focus so narrowly on SOAP. Currently, there are lots of places where the UI has to wait until the user submits, then let the server side check with the DB, then prompt the user. Take the following examples.... 1) User-picker 2) Filling in default owner of newly selected component before asking the user if a bug should be reassigned to that owner 3) Early mid-air detection 4) Selecting new component and version on product change 5) Early validation of bug numbers in dependencies, etc... While each of these would still need to have a non-javascript dependent mechanism as well, the UI could be made better if the javascript running in the browser had a way of getting the information it needed. Currently, we either take pains to avoid needing the information or we pre-load the information in large arrays. If the javascript could ask a queation of the server during editing, this would be a lot smoother. I am not familier with browser support for XML-RPC. Which technology permitting javascript to dynamically query a server is most available? From justdave at bugzilla.org Tue Dec 23 16:40:46 2003 From: justdave at bugzilla.org (David Miller) Date: Tue, 23 Dec 2003 11:40:46 -0500 Subject: Wanted: Documentation Help In-Reply-To: References: Message-ID: On 12/8/2003 1:19 AM -0500, David Miller wrote: > First off I'd like to take this opportunity to express a world of gratitude > to Jake Steenhagen for his work on the documentation the last several > months. He's taken the great foundation Matthew Barnson gave us for our > documentation and made it even better. > > Jake was just informed today that his Army Reserve unit is getting deployed > to active duty effective December 23rd (about 2 weeks from now), and > although they don't know the length yet, it'll likely be 18 months. I hope > you'll all join me in wishing him well on his deployment and hoping we get > him back safe and sound when it's over with. > > What this means for Bugzilla is we'll be without a documentation owner. If > you're handy with Docbook and have lots of free time you're willing to > donate, we'd be interested in hearing from you. We did get three people volunteer to help out, but nobody actually wants to be in charge yet. :) Lacking an official "component owner" I have set up a "fake" Bugzilla account for documentation at bugzilla.org, and will shortly be reassigning all of Jake's documentation bugs to that account. Anyone who's interesting in helping out should add documentation at bugzilla.org to your watch list in your email preferences. -- Dave Miller Project Leader, Bugzilla Bug Tracking System http://www.justdave.net/ http://www.bugzilla.org/ From gerv at mozilla.org Tue Dec 23 16:50:24 2003 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 23 Dec 2003 16:50:24 +0000 Subject: SOAP In-Reply-To: <3FE870D1.1030106@peshkin.net> References: <3FE79CCC.3040301@peshkin.net> <3FE7FF1E.5000905@mozilla.org> <20031223151603.GB1027@async.com.br> <3FE870D1.1030106@peshkin.net> Message-ID: <3FE87250.2080309@mozilla.org> Joel Peshkin wrote: > I am not familier with browser support for XML-RPC. Which technology > permitting javascript to dynamically query a server is most available? The gifs-and-cookies hack ;-) http://www.vboston.com/DepressedPress/Content/ColdFusion/Essays/GIFAsPipe/Index.cfm Dude, if any such usable technology were significantly available, we'd see a lot of better-designed websites... Gerv From cbendell at point2.com Tue Dec 23 16:49:05 2003 From: cbendell at point2.com (Colin Bendell) Date: Tue, 23 Dec 2003 10:49:05 -0600 Subject: SOAP Message-ID: IE also has support for soap via non standard means since IE5.0. Check out: http://msdn.microsoft.com/library/default.asp?url=/workshop/author/webservice/overview.asp /colin ________________________________ From: developers-owner at bugzilla.org on behalf of Gervase Markham Sent: Tue 2003-12-23 2:38 AM To: developers at bugzilla.org Subject: Re: SOAP Joel Peshkin wrote: > I have been looking at SOAP and it looks like the right way to let > javascript functions access databases so that mid-air checks can happen > earliers, user matching can be done while editing (replacing wildcards > and drop-down user pickers) and a whole lot more. A few thoughts: What's the particular advantage of SOAP (which, as I understand it, is an XML wrapper format for wrapping more XML), given that browsers mostly don't support it natively? I think Moz might, a little bit, but IE doesn't as far as I know. Such checking could only be done in really modern browsers, anyway - older ones don't support JS fetching arbitrary documents without a page reload of some sort. Is it worth all the effort and added complexity that it would require? What is your "whole lot more"? :-) Mid-air checks can't be done earlier with 100% accuracy, of course, because if you check at some point before submission, you have to check again on submission anyway. Gerv - To view or change your list settings, click here: -------------- next part -------------- A non-text attachment was scrubbed... Name: winmail.dat Type: application/ms-tnef Size: 4825 bytes Desc: not available URL: From prasad_kadbane at hotmail.com Tue Dec 30 07:51:18 2003 From: prasad_kadbane at hotmail.com (prasad kadbane) Date: Tue, 30 Dec 2003 07:51:18 +0000 Subject: No subject Message-ID: Respected sir, I am a student doing Bachelor of computer Engg in Pune university, India. I am in the final year of degree course and I am doing a project based on Bugzilla software. The aim of my project is to link Bugzilla with test case repository. Every bug entered in the Bugzilla will have a corresponding test case associated with it. The bug can be reproduced or demonstrated by running the associated test case. I want your guidance for the project. So please guide me regarding how and where to modify the source code to establish connectivity between Bugzilla and test case repository. _________________________________________________________________ Send DD, pay no commission. http://server1.msn.co.in/msnleads/suvidha/dec03.asp?type=hottag Click here. From asmodai at wxs.nl Tue Dec 30 08:07:14 2003 From: asmodai at wxs.nl (Jeroen Ruigrok/asmodai) Date: Tue, 30 Dec 2003 09:07:14 +0100 Subject: your mail In-Reply-To: References: Message-ID: <20031230080714.GH59039@nexus.ninth-circle.org> Namaste-ji Prasad, aap kaise hai? -On [20031230 08:52], prasad kadbane (prasad_kadbane at hotmail.com) wrote: >I am a student doing Bachelor of computer Engg in Pune university, >India. I am in the final year of degree course and I am doing a >project based on Bugzilla software. The aim of my project is to link >Bugzilla with test case repository. Every bug entered in the Bugzilla >will have a corresponding test case associated with it. The bug can be >reproduced or demonstrated by running the associated test case. I am speaking from memory here since I haven't had a chance to mess with the codebase in a while now (should hopefully change soon): - you would need to extend the schema with a separate table for the test cases (if you could make it non-MySQL specific it would be even better) - the main issue is the 'running' part, not every Linux or Unix (let alone Windows) machine has the same paths and such for running certain scripts, so does 'running' mean you can take the testcase and download it to your local box and run it, or is it meant to be run on a main testcase/build server? So I would like to hear your ideas about this. :) > I want your guidance for the project. So please guide me regarding how and >where to modify the source code to establish connectivity between Bugzilla >and test case repository. It all depends on your approach to be honest. (btw you might want to check the recent archives, since I remember some postings about this very same subject in the not too distant past.) -- Jeroen Ruigrok van der Werven / asmodai / kita no mono PGP fingerprint: 2D92 980E 45FE 2C28 9DB7 9D88 97E6 839B 2EAC 625B http://www.tendra.org/ | http://diary.in-nomine.org/ When I see beings of wicked nature, pressed by violent sin and affliction, may I hold these rare ones dear as if I had found a precious treasure... From kiko at async.com.br Tue Dec 30 13:18:45 2003 From: kiko at async.com.br (Christian Robottom Reis) Date: Tue, 30 Dec 2003 11:18:45 -0200 Subject: your mail In-Reply-To: <20031230080714.GH59039@nexus.ninth-circle.org> References: <20031230080714.GH59039@nexus.ninth-circle.org> Message-ID: <20031230131845.GA779@async.com.br> On Tue, Dec 30, 2003 at 09:07:14AM +0100, Jeroen Ruigrok/asmodai wrote: > -On [20031230 08:52], prasad kadbane (prasad_kadbane at hotmail.com) wrote: > >I am a student doing Bachelor of computer Engg in Pune university, > >India. I am in the final year of degree course and I am doing a > >project based on Bugzilla software. The aim of my project is to link > >Bugzilla with test case repository. Every bug entered in the Bugzilla > >will have a corresponding test case associated with it. The bug can be > >reproduced or demonstrated by running the associated test case. > > I am speaking from memory here since I haven't had a chance to mess > with the codebase in a while now (should hopefully change soon): There have been two [separate?] testcase efforts discussed here on the list; in particular Ed Fuentetaja and Myk have been looking at this. It might make sense to look at their work before starting anew. Take care, -- Christian Robottom Reis | http://async.com.br/~kiko/ | [+55 16] 261 2331

with a table inside it (which I'm not sure is actually legal) we should have the a table with an

*inside* it (for the primary page heading). You can leave the secondary and tertiary headings marked with simple spans, and allow

-

to be used by the actual page content. As for the

/

issue, I can accept your rationale for having the organization's identification up there. So we would have, for a sample query.cgi, contrasting vanilla bugzilla with a pseudo-branded bugzilla:

Bugzilla Main Page Gozilla.org: Family-Approved Sprockets

Bugzilla Version XXX Bug Tracking (Bugzilla XXX)

Bugzilla Main Page Gozilla.org: Family-Approved Sprockets

Bugzilla Version XXX Bug Tracking (Bugzilla XXX)

Request Queue Request Queue

Bugzilla Main Page Gozilla.org: Family-Approved Sprockets

Bugzilla Version XXX Bug Tracking (Bugzilla XXX)

General Information

Attachments

Dependencies

Additional Comments

Status

Bugzilla Main Page Gozilla.org: Family-Approved > Sprockets >

Bugzilla Version XXX Bug Tracking (Bugzilla XXX) >

/

issue, I can accept your rationale for having the >organization's identification up there. So we would have, for a sample >query.cgi, contrasting vanilla bugzilla with a pseudo-branded bugzilla: >

Bugzilla Main Page Gozilla.org: Family-Approved Sprockets >

Bugzilla Version XXX Bug Tracking (Bugzilla XXX) >

Acne Corp - fleshing out your face

Bugzilla Main Page Gozilla.org: Family-Approved Sprockets >

Bugzilla Version XXX Bug Tracking (Bugzilla XXX) >

Request Queue Request Queue >

Gozilla.org bug tracking (Bugzilla XXX)

Request Queue

MyBugzilla

Query for bugs

Bug status

Bug resolution

looks to be 'normal' font size, but bold. Anything else is smaller than the normal text, which is obviously not what we want. Perhaps the version text (Bugzilla 2.17.6) could be an

or

, the explanatory header (bugzilla bug X) can be an

, and then we have

, and then we > have

Bug 2314 - Foobar

or

, >the explanatory header (bugzilla bug X) can be an

, and then we >have

Advanced

area :-) This doesn't mean I'm not for a Bugzilla logo -- of course Bugzilla needs its own identity, which should go with its default install. But sites running PHP4 or Apache don't have that in their

Advanced

Advanced

Summary

Advanced

Summary

Advanced

Actions

Comments

Actions

Admin

Searches

Bugzilla Task 1

Test

Last modified: 2003-12-08 16:33

Advanced

Bug 2314 - Foobar

This is BZ...

...

is the version (which doesn't to be id'ed, we can just lessen the font size of

, and an id'ed table (for width) with an

inside it (for the primary page heading). You can leave the secondary and tertiary headings marked with simple spans, and allow