Closed Bug 160347 (layout) Opened 22 years ago Closed 22 years ago

Split Browser: Layout component into managable pieces

Categories

(bugzilla.mozilla.org :: Administration, task)

Product:
bugzilla.mozilla.org
Component:
Administration
Type:
task
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: timeless, Assigned: timeless)

References

Details

this is a note to self, attinasi left netscape. Current candidates for layout traige: dbaron@fas.harvard.edu bzbarsky@mit.edu Eventually this component should get a new assignee
While we're on the topic, I think the Layout component should be split, since it's become too large a component for a single person to triage. A possible split would be something like: "Fonts" "Layout: General", or perhaps just "Layout" [ for triage, reduction, and reassignment to other components ] "Layout: Block & Inline" "Layout: R & A Pos" [ short for relative and absolute positioning; an intentionally cryptic name to discourage bugs from people who don't know what they're doing ] "Layout: Other" [ for code-level bugs in things like the pres shell, etc. ] (and perhaps some others that I'm forgetting right now) (At the same time, HTMLTables could be renamed to "Layout: Tables" if we wanted the consistency. Perhaps the same for form controls, although I'm not sure.)
Summary: Browser: Layout is orphanned (attinasi left) → Split Browser: Layout component into managable pieces
Do we want float-related bugs in a separate component, also? Or under block & inline?
CC: list, can you all please chime in. If we break this up to make it more managable will you all take ownership of the smaller parts? Who will own what?
I think there are two separate problems. Triage of incoming bugs and ownership of bugs after they are triaged. The biggest issue I have encountered is ownership after they are triaged. There are not enough engineers to take ownership of the volume of layout bugs that are generated. Breaking layout up into additional modules will not help this unless there are additional engineers to take ownership of these bugs. Over time the volume of the layout bugs has increased substantially, while the number of engineers available to own these bugs has shrunk. In addition, one of the main reasons layout is assigned so may bugs is that most people don't have a clue where the bug actually belongs so they throw it in the most general category. In many instances, it is difficult to know which of the layout sub-modules the bug belongs without doing some investigation. If we simply assign these bugs to existing engineers who already have large bug lists they will quickly reach a saturation point where the number of email messages that are sent as bugmail exceeds their capacity to keep up and do any real work if they actually read their mail. This is what happened with Marc Attinasi. He had to resort to using a secondary email address in his existing bugs that he filtered to a folder that he *never* looked at. There are currently 887 bugs assigned to attinasi@netscape.com. If we reassign these bugs to existing layout engineers we will substantially increase their bugload which I don't think will be productive. Even more daunting is the incoming rate. With 50-100 new bugs being assigned each week, we will quickly reach saturation point for all engineers. existing bug counts ------------------- 338: karnaze 475: rods 191: dcone 223: kin 212: jkeiser 161: kmcclusk 136: alexsavulov Currently, Layout QA and I go through the un-milestoned layout module bugs several times during the week and assign P1-P5 priorities to each bug and set the milestone to future to indicate they have been triaged. I pull from the P1 list and reassigning to engineers. With QA's help I have been able to keep up with the incoming layout bugs. The problem with this approach that Asa discovered is that there isn't an automatic way to get blockers and critical bugs on the radar. The only way to get it quickly on the radar is to cc' me or one of the layout engineers in the bug. I think the most important issue is to get the most critical/blocker bugs worked on. The current model of bug ownership does not scale well given the number of people we have generating bug reports and commenting in bugs relative to those fixing bugs. I think a better model for high volume modules would be to make the default owner something like layout@mozilla.org, but have the critical and blocker bugs directly assigned to a layout owner. This would make it clear to people commenting in bugs assigned to layout@mozilla.org that the bug has not yet been assigned to an owner who will take responsibility for fixing it. Critical and blocker bugs need to be triaged quickly, but other bugs could be triaged with a potential 1 or 2 day lag. I don't want to see layout engineers spending even more time managing the bug system. Managing the bug system already consumes a large part of their time. I would rather have them spend more time fixing the most important bugs and less time responding to comments made in non-critical bugs if possible. Layout isn't the only module that has this problem however. Browser-General also has a large bug volume, so any solution we come up with here may also apply there.
Kevin, I think that the split would be more beneficial to the triage effort than the development effort. Bugs that are obviously bugs in one of the areas involved could be reassigned to one of the sub-components by the QA volunteers (and Netscape QA, should they wish to, of course). Bugs without testcases or those that are just generally untriaged would stay in "Layout: General" until they were triaged. "Fonts" bugs could get people familiar with fonts (eg intl) cced on them. And so forth. In fact, I would be quite happy with making the owners of _all_ these components owned by relevant dummy addresses (layout_general@m.o, layout_block_inline@m.o, etc.) that could be watched by people interested in working on bugs in that area as they saw fit. As you said, critical/blocker bugs would need to be assigned to real engineers asap instead of being funneled with the rest. Does that make sense?
"Does that make sense?" Yes. Sounds good.
Status: NEW → ASSIGNED
*** Bug 167788 has been marked as a duplicate of this bug. ***
I'd like to see the original reported bug fixed in a relative hurry, and the breakdown in comment #2 implemented in a more leisurely manner. Right now I'm scared that some good bug reports stand an increased chance of falling not only between the cracks, but on dead, dead eyes.
And who are you volunteering for this unpaind 10-20 hour per week job?
nobody@mozilla.org, if that makes things clearer all-round.
Ok. Back to comment 1. I would be willing to own the "positioned stuff" component once I finish moving and have a net connection again. Any other takers for parts of this beast?
Change Component Description/Assignee: "Layout" For triage, reduction, and reassignment to other components assi: karnaze@netscape.com qa: petersen@netscape.com Rename "HTMLTables" to "Layout: Tables" Core layout and geometry for HTML tables. "HTMLFrames" to "Layout: Frames" "HTML Form Controls" to "Layout: Form Controls" For problems with FORM elements: buttons, edit fields, passwords, file upload controls (but not the file upload dialog, that's xp toolkit/widgets) Add Components: "Fonts and Text Display" For problems with enumerating and rendering system fonts, glyph substitution, fallbacks when specified font not available and legibility. assi: bstell@ix.netcom.com qa: ruixu@netscape.com "Layout: Block & Inline" Core layout and geometry for basic block and line elements. assi: dbaron@fas.harvard.edu qa: petersen@netscape.com "Layout: R & A Pos" Relative, Absolute, and Fixed positioning, except when printing. If you don't know what this is then please don't move bugs here, instead select "Layout" assi: bzbarsky@mit.edu "Layout: Misc Code" For code-level bugs in things like the pres shell, etc. assi: kin@netscape.com qa: <empty> (no one qa's this stuff) for fun, i checked presshell (counting cvs revs to people's names), mjudge should own it ;-) 32 kipp%netscape.com 36 dbaron%fas.harvard.edu 38 nisheeth%netscape.com 46 mjudge%netscape.com 57 troy%netscape.com 6 kin%netscape.com
To get this rolling, how about if we break of the layout module, assign QA contacts for each layout module, and assign ownership to nobody@mozilla.org. Madhur: Can you provide the QA contact for each module?
Before I go ahead and provide QA contacts for the each module, i'd like to clarify that I got all the sub components right : 1. Layout : General 2. Layout : Tables 3. Layout : Frames 4. Layout : Form Controls 5. Layout : Forms and Text Display 6. Layout : Block & Inline 7. Layout : R & A Pos 8. Layout : Misc Code 9. Layout : Others ???? Am I missing out on any module?
Madhur Bhatia wrote: > Before I go ahead and provide QA contacts for the each module, i'd like to > clarify that I got all the sub components right : > 1. Layout : General 10. Layout: Printing // for all (mainly crossplatform) issues in layout/
If we are going to rename "HTMLFrames" to "Layout: Frames" we should make it Layout:IFrame/Frameset otherwise people will confuse it with nsFrame base class used by layout objects
Do we want a separate floats component, or not? I'd rather call "Layout: General" just "Layout". "Forms and Text Display" should be "Fonts and Text Display". We already have a "Printing" component. If we want a separate "Layout: Printing" component we need very clear descriptions of what goes in each. I think "Layout: Frames" is clear enough.
David Baron wrote: > We already have a "Printing" component. If we want a separate "Layout: > Printing" component we need very clear descriptions of what goes in each. The problem I see is that there is no clean seperation between which bugs are crossplatform issues, which are specific to one OS/platform or specific to one print module. We have tons of wild combinations in BugZilla which makes it hard to narrow-down things with bugzilla queries, and sometimes it's even hard to figure out on which OS the reporter is trying to print on. In theory "Layout: Printing" would be for crossplatform printing issues which have their origin in layout/ code... ... but I am not sure whether this approach works in real life since a bug about "wrong table layout while printing" would match "Layout: Tables", too... ... any suggestions ?
so the final sub-components are ........
For triaging purposes, we need several QA engineers to be looking at the flow of incoming bugs, not just petersen (default QA for Layout). We'd like to encourage incoming bugs to be reported into the different components as appropriate, instead of trying to collect them all in the Layout : General (or just Layout) component. With this in mind, it would be more appropriate to have Layout : Others, instead of Layout : General (or just Layout). The word General is very generic and it would attract a lot of bugs, while Others will attract just those bugs that do not fall in any other component -- it'll force reporters to think where the bug needs to go.
What percentage of reporters will understand the difference? I'd rather have bugs filed on a general component when the reporter doesn't understand the difference than have them all misfiled on the subcomponents. I'd also rather not force reporters to use Browser-General if they don't know which layout sub-component to file against.
Come on!... If someone doesn't know which component a Layout bug belongs to, it's very likely he'd file it in Layout : Others --we're talking about common sense here! I don't think these bugs would end up in Browser-General. Having the majority of incoming bugs reported in a single component (i.e. Layout) doesn't help us to triage bugs efficiently, because a single QA engineer will be swamped with bugs, and this defeats what we're trying to achieve --namely, improved triaging efficiency. We would rather have bugs distributed among several components, with different default QA owners. Each QA owner would be triaging and reassigning bugs to the right component.
I agree with gerardok. It is clear that Layout-other is where a layout bug would go if the reporter doesn't know which layout sub-category it should go into. Reporters seem to go for first category that they think fits and often don't search beyond that. If we can at least make them think a little bit when filing the bug this would help.
Here are the QA contacts for the proposed modules :- 1. Layout : Others (or Layout : General, or Layout) ---- petersen@netscape.com 2. Layout : Tables ------------------------------------- amar@netscape.com 3. Layout : IFrame/Frameset (or Layout : Frames) ------- amar@netscape.com 4. Layout : Form Controls ------------------------------ tpreston@netscape.com 5. Layout : Fonts and Text Display --------------------- ruixu@netscape.com 6. Layout : Block & Inline ----------------------------- moied@netscape.com 7. Layout : R & A Pos ---------------------------------- madhur@netscape.com 8. Layout : Misc Code ---------------------------------- nobody@mozilla.org Open issues from the above comments:- (9) Layout : Float ??? (10) Layout : Printing ??? Are these still on the proposal table ?
OK -- if we go with the Others idea, I'd prefer "Layout: Other" over "Layout: Others". If we want something other than "Layout: Frames" I'd prefer "Layout: HTML Frames". If "Layout: Floats" doesn't exist it would be a part of "Layout: Block and Inline", so perhaps it should have the same QAC?
I think there are enough float specific issues to justify having it as a layout sub-module. So how about the following as the final list? Module/QA Contact 1. Layout : Other -------------------------------------- petersen@netscape.com 2. Layout : Tables ------------------------------------- amar@netscape.com 3. Layout : HTMLFrames ----------------------------------amar@netscape.com 4. Layout : Form Controls ------------------------------ tpreston@netscape.com 5. Layout : Fonts and Text Display --------------------- ruixu@netscape.com 6. Layout : Block & Inline ----------------------------- moied@netscape.com 7. Layout : R & A Pos ---------------------------------- madhur@netscape.com 8. Layout : Misc Code ---------------------------------- nobody@mozilla.org 9. Layout : Floats ------------------------------------- moied@netscape.com All ownership set to nobody@mozilla.org
That list looks good to me, except I'd really like the ownership set to dummy "watchable" addresses at the very least. Something like: layout_other@mozilla.org layout_floats@mozilla.org etc. Also, tables already has a module owner, and unless karnaze really wants to get rid of it...
Yes, multiple addresses are good. This allows multiple people to watch a single area, which is not currently possible unless you watch the area's owner, in which case you get all his other mail too.
The list in comment 26 looks good to me, except for the owners. I agree that they should be dummy addresses (unless people want to step up to be a single real owner). (One nit: perhaps "Fonts and Text Display" should just be "Fonts and Text".)
OK. So sounds like: Module -- Owner/QA Contact 1. Layout : Other -----------layout_other@mozilla.org petersen@netscape.com 2. Layout : Tables ----------layout_tables@mozilla.org amar@netscape.com 3. Layout : HTMLFrames ------layout_frames@mozilla.org amar@netscape.com 4. Layout : Form Controls ---layout_forms@mozilla.org tpreston@netscape.com 5. Layout : Fonts and Text -layout_fonts@mozilla.org ruixu@netscape.com 6. Layout : Block & Inline --layout_block_inline@mozilla.org moied@netscape.com 7. Layout : R & A Pos -------layout_positioned@mozilla.org madhur@netscape.com 8. Layout : Misc Code -------layout_misc@mozilla.org nobody@mozilla.org 9. Layout : Floats ----------layout_float@mozilla.org moied@netscape.com should be happy with everyone? If so, let's do this, please.
Could you please change a QA contact as followings? 5. Layout : Fonts and Text -layout_fonts@mozilla.org ylong@netscape.com Also see bug 172042.
Is this OK with mozilla.org mail-handling folks?
you don't want to run this mail through mozilla.org. I recommend finding some other email addresses.
Fundamentally, these need not be real mail addresses that go anywhere... they just need to be something that people can watch... Aren't there reserved hostnames that we could use for this purpose?
*** Bug 174783 has been marked as a duplicate of this bug. ***
Change peterson to gerardok@netscape.com -- You have reached this web page by typing "example.com", "example.net", or "example.org" into your web browser. These domain names are reserved for use in documentation and are not available for registration. -- Unfortunately these aren't so great because mailing them results in undeliverable notifications from your mail server. Instead we should pick names and use data/nomail to prevent mail from being sent. Endico can do this. 1. Layout : Other ----------- other@layout.bugs gerardok@netscape.com 2. Layout : Tables ---------- table@layout.bugs amar@netscape.com 3. Layout : HTMLFrames ------ frame@layout.bugs amar@netscape.com 4. Layout : Form Controls --- form@layout.bugs tpreston@netscape.com 5. Layout : Fonts and Text - font@layout.bugs ruixu@netscape.com 6. Layout : Block & Inline -- block_inline@layout.bugs moied@netscape.com 7. Layout : R & A Pos ------- position@layout.bugs madhur@netscape.com 8. Layout : Misc Code ------- misc@layout.bugs nobody@mozilla.org 9. Layout : Floats ---------- float@layout.bugs moied@netscape.com We can use layout.bugs because as long as we don't include a final '.' we aren't claiming it is a top level domain and it can be interpretted as relative to some domain (perhaps to mozilla.org, perhaps not). How this works: endico creates these bugzilla accounts and then adds them to data/nomail. As long as the entries are in data/nomail they shouldn't generate any email but people should be able to watch them.
Asa authorized me to makes the changes. fwiw, Layout: Other sorted into a bad place, so I left it as Layout, this way people who don't know what they're looking for can use the first one, and people who triage from there can simply scroll down to a more specific component.
Assignee: asa → timeless
Status: ASSIGNED → NEW
QA Contact: timeless → asa
Thanks to endico for the bugzilla accounts. If people want other changes, they should file new bugs. Here's the final list: Layout other@layout.bugs gerardok@netscape.com For triage, reduction, and reassignment to other layout components. Layout: Block & Inline block_inline@layout.bugs moied@netscape.com Core layout and geometry for basic block and line elements. Layout: Floats float@layout.bugs moied@netscape.com Issues with CSS floats or left/right aligned images. Layout: Fonts and Text font@layout.bugs ylong@netscape.com For problems with enumerating and rendering system fonts, glyph substitution, fallbacks when specified font not available and legibility. Layout: Form Controls form@layout.bugs tpreston@netscape.com For problems with HTML Form Elements: buttons, images, edit fields, passwords, file controls, submit buttons, selects, and textareas. NOT for file upload dialog problems, those belong in xp toolkit/widgets. Layout: HTMLFrames frame@layout.bugs amar@netscape.com This is HTML framesets -- layout and rendering. HTMLFrames == html frame/frameset/iframe tag handling. Layout: Misc Code misc@layout.bugs nobody@mozilla.org For code-level bugs in things like the pres shell, etc. Layout: R & A Pos position@layout.bugs madhur@netscape.com Relative, Absolute, and Fixed positioning, except when printing. If you don't know what this is then please don't move bugs here, instead select "Layout". Layout: Tables table@layout.bugs amar@netscape.com This is HTML Tables -- layout and rendering.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
timeless, we've decided to have a "Layout: Other" component, not just "Layout". Please update according to what has been agreed upon. If you have a different take on it, feel free to add your comments to this report, but please do not change the component names unilateraly. Thanks!
I think we should stick to "Layout" rather than "Layout:Other", at least for the short term. I un-retract my suggestion earlier that we do that, since I want these new sub-components to have less noise. (More later...have to run now.)
The reason to not do layout:other for now is that bugzilla can't sort in non-alphabetical order, apparently... As it is, the "Layout" component is the first in the list of layout-related stuff. So users who don't know better will file bugs there, as they should.
Same here, "Layout" seems just fine to me. All we really want it for is as a container for bugs we don't know about and if naming it this makes it easier to get to, it has served its purpose.
I'm curious as to why nobody cc'ed me on this bug, but anyway. The "Complex Text Layout" component should join the Layout fold as "Layout: CTL". Similarly, "BiDi Hebrew & Arabic" should become "Layout: UNICODE Bidi" or some such. cc'ing relevant people. The block_inline@layout.bugs e-mail address would be better without an underscore, as in block-and-inline@layout.bugs. The current description for "Layout: Fonts and Text" doesn't explain why "Text" is in the title name. "HTMLFrames" should be "HTML Frames", with a space. The description shouldn't have two hyphens or two equal signs (the following is a better description: "For rendering and layout issues with frames (<iframe>, <frame> and <frameset> elements in HTML)."). "Layout: Misc Code" would probably be better as "Layout: Internal". The description for the tables component does little more than describe the title, the following would be better: "For bugs in the CSS and HTML table layout and rendering code. For example bugs with the HTML 'rules' attribute or the CSS 'border-collapse' property belong here." The proposed QA contacts are not (with the exception of madhur) very active in the Mozilla layout community, and shouldn't in my opinion be made QA contacts without first demonstrating that they understand CSS layout. I hereby volunteer for QA of the Layout, Layout: Block & Inline, Layout: Floats, Layout: Fonts and Text, Layout: HTML Frames, and Layout: R & A Pos components, since I believe I currently do more work in those areas of Mozilla QA than the currently assigned QA contacts. Reopening to deal with these issues.
Alias: layout
Severity: major → normal
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Ian 'Hixie' Hickson wrote: > The "Complex Text Layout" component should join the Layout fold as "Layout: > CTL". Similarly, "BiDi Hebrew & Arabic" should become "Layout: UNICODE Bidi" > or some such. cc'ing relevant people. "Complex Text Layout" isn't really about "layout", this is more a kind of "text shaping" and sits in another layer than our normal "layout" stuff. I doubt it belongs into the "layout"-family of bugzilla components. Same applied to "BiDi", too...
hi, I believe Bidi has layout issues although CTL is more of text shaping, rendering and positioning than "layout" prabhat
i fixed tables and frames with bz's concurrence. dbaron who suggested fonts and text said to leave it alone, bz concurred. bz disagreed on changing misc. that leaves: * bidi/ctl, which i feel should be handled in another bug (I suggested Layout to gisburn earlier and he disagreed). * the email address. hixie: just contact dawn. * QA contacts. i'm inclined to support giving most of them to hixie, but that's well beyond my authority and can be handled in bug 176140.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
> "Complex Text Layout" isn't really about "layout" well then it really should have another name, shouldn't it... Anyway, "Layout" in a Mozilla sense does include painting, compositing, and rendering. Indeed, "Views" probably should be moved to "Layout: Views" as well.
...and bidi is definitely layout related, it affects the very guts of the inline box model. But ok, let's deal with that in another bug.
>> "Complex Text Layout" isn't really about "layout" >well then it really should have another name, shouldn't it... What can you do: "Complex Text Layout" is the accepted term for it, even if "Layout" isn't being used in the Mozilla sense, just as HTML frameset frames are always in danger of being confused with Mozilla layout frames. Bidi is partly about layout (in the Mozilla sense), partly about CTL, and partly font and character issues that really belong in Internationalization. Those that are about layout should all be dependencies of bug 137995.
Given the "Layout: Fonts and Text" component, I think all font issues fall pretty well into Layout: *, but whatever, it's only a component name...
verified I can follow bugmail about positioned stuff without going insane because of all the float bugs.
Status: RESOLVED → VERIFIED
Component: Bugzilla: Keywords & Components → Administration
Product: mozilla.org → bugzilla.mozilla.org
You need to log in before you can comment on or make changes to this bug.