From denis.roy at eclipse.org Thu Dec 3 01:31:01 2015 From: denis.roy at eclipse.org (Denis Roy) Date: Wed, 2 Dec 2015 20:31:01 -0500 Subject: Have a separate Bugzilla installation for the Bugzilla project? In-Reply-To: <565C7C30.9090303@bugzilla.org> References: <565B0CAB.5040709@gmail.com> <565C773E.4040109@mozilla.org> <565C7C30.9090303@bugzilla.org> Message-ID: <565F9B55.2070709@eclipse.org> If there's consensus, then I'd appreciate knowing what the project team needs to run. We use SuSE Linux Entreprise 12 which has everything needed to run a Bugzilla instance. Aside from the obvious Perl, MariaDB and other related bits, what is needed in terms of hardware specs? Denis On 30/11/15 11:41 AM, Dave Miller wrote: > Gervase Markham wrote: >> On 29/11/15 14:33, Fr?d?ric Buclin wrote: >>> I would suggest that >>> the Bugzilla project has its own Bugzilla installation, managed by the >>> upstream Bugzilla team itself. >> I agree that now is the time for this, particularly given the very >> generous offer from Denis and the Eclipse team. > I agree as well. I was going to say that we probably ought to wait for > BMO to finish their current upstream merge and see where that puts us, > but I think the Eclipse offer gives us a pretty good excuse to do it > anyway :) We have actually wanted it for a while, everyone's just > scared of the work involved in migrating. > From vapier at gmail.com Thu Dec 3 02:12:04 2015 From: vapier at gmail.com (vapier at gmail.com) Date: Wed, 2 Dec 2015 18:12:04 -0800 (PST) Subject: does bugzilla.mozilla.org run stock bugzilla wrt templates ? Message-ID: <9c47af93-6180-46c1-b0b7-b4e12c2c7aa5@googlegroups.com> does bugzilla.mozilla.org run vanilla bugzilla software (e.g. straight out of git) ? my interest lies in the templates used as sometimes i see things used on BMO that i'd like to use on my own installs. assuming the answer is "no", where is the exact code used to run BMO hosted ? is it public ? -mike _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From justdave at bugzilla.org Thu Dec 3 02:33:49 2015 From: justdave at bugzilla.org (Dave Miller) Date: Wed, 02 Dec 2015 21:33:49 -0500 Subject: does bugzilla.mozilla.org run stock bugzilla wrt templates ? In-Reply-To: <9c47af93-6180-46c1-b0b7-b4e12c2c7aa5@googlegroups.com> References: <9c47af93-6180-46c1-b0b7-b4e12c2c7aa5@googlegroups.com> Message-ID: <565FAA0D.4030906@bugzilla.org> vapier at gmail.com wrote: > does bugzilla.mozilla.org run vanilla bugzilla software (e.g. straight out of git) ? my interest lies in the templates used as sometimes i see things used on BMO that i'd like to use on my own installs. assuming the answer is "no", where is the exact code used to run BMO hosted ? is it public ? Nope, theirs is heavily modified. That said, they do have what they are running publicly available in a git repository. bugzilla.mozilla.org is currently based on the Bugzilla 4.2 branch I believe. Last I heard they're hoping to merge with 5.0 in the near future, and then hopefully we get some of their stuff ported upstream. Their git repo can be browsed at http://git.mozilla.org/?p=webtools/bmo/bugzilla.git;a=tree -- Dave Miller http://www.justdave.net/ IT Infrastructure Engineer, Mozilla http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From justdave at bugzilla.org Thu Dec 3 02:37:14 2015 From: justdave at bugzilla.org (Dave Miller) Date: Wed, 02 Dec 2015 21:37:14 -0500 Subject: Have a separate Bugzilla installation for the Bugzilla project? In-Reply-To: <565F9B55.2070709@eclipse.org> References: <565B0CAB.5040709@gmail.com> <565C773E.4040109@mozilla.org> <565C7C30.9090303@bugzilla.org> <565F9B55.2070709@eclipse.org> Message-ID: <565FAADA.6060203@bugzilla.org> In the grand scheme of things, the Bugzilla project is pretty small. I highly doubt we'd need anything more than a dual core server with 8GB of RAM or so. (Maybe less RAM, depends on how bad mod_perl kills it, but mod_perl is RAM-hungry). Bugzilla.mozilla.org is a many-headed beast because of Firefox and friends. :-) Having the DB on a separate box from the webserver may be good for performance. Denis Roy wrote: > If there's consensus, then I'd appreciate knowing what the project team > needs to run. > > We use SuSE Linux Entreprise 12 which has everything needed to run a > Bugzilla instance. Aside from the obvious Perl, MariaDB and other > related bits, what is needed in terms of hardware specs? > > Denis > > > On 30/11/15 11:41 AM, Dave Miller wrote: >> Gervase Markham wrote: >>> On 29/11/15 14:33, Fr?d?ric Buclin wrote: >>>> I would suggest that >>>> the Bugzilla project has its own Bugzilla installation, managed by the >>>> upstream Bugzilla team itself. >>> I agree that now is the time for this, particularly given the very >>> generous offer from Denis and the Eclipse team. >> I agree as well. I was going to say that we probably ought to wait for >> BMO to finish their current upstream merge and see where that puts us, >> but I think the Eclipse offer gives us a pretty good excuse to do it >> anyway :) We have actually wanted it for a while, everyone's just >> scared of the work involved in migrating. >> > > - > To view or change your list settings, click here: > -- Dave Miller http://www.justdave.net/ IT Infrastructure Engineer, Mozilla http://www.mozilla.org/ Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ From gerv at mozilla.org Thu Dec 3 10:04:08 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 3 Dec 2015 10:04:08 +0000 Subject: Topline goal ideas for Bugzilla based on what a few sites are doing or needing In-Reply-To: References: Message-ID: Hi Dylan, Thanks for doing this research :-) On 30/11/15 03:14, Dylan Hardison wrote: > I also ran a few simple queries against open bugs on BMO, ordered by > the number of CC's by specific accounts. Many of those bugs are very > old, have very little activity > and (in my humble opinion) examples of "perfect is the enemy of good". As in, what the bug requests is too perfect and so has not been actioned? Or in the bug, people have argued for something simple and been rebuffed? > What I've compiled (which is not much) is now available on the wiki page: > https://wiki.mozilla.org/Bugzilla:Ideas The ideas are: 1) Webhooks or Push Connector API -- Can you explain what you mean by "webhooks" in this context, and expand a bit more on what this would look like and what it would let you do? 2) Auth Stack Changes -- If the auth stack is getting in the way of people actually using it to authenticate things, we should fix that, yes. BMO has some plans in this area, I believe - what are they, do you know? 3) Modernize UI -- I think we should definitely start from glob's work. Does it support mobile? 4) Advanced Search UI Problems -- By "advanced" you mean the Boolean Charts stuff at the bottom of the search page (as it used to be called)? This is indeed a great candidate for an API-driven dynamic query builder rather than a bunch of dropdowns. 5) Product/Component Watching -- I agree the extension should be shipped with core or be reimplemented in core. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From dylan at mozilla.com Thu Dec 3 14:32:42 2015 From: dylan at mozilla.com (Dylan Hardison) Date: Thu, 3 Dec 2015 09:32:42 -0500 Subject: Topline goal ideas for Bugzilla based on what a few sites are doing or needing In-Reply-To: References: Message-ID: On Thu, Dec 3, 2015 at 5:04 AM, Gervase Markham wrote: > Hi Dylan, > > Thanks for doing this research :-) My pleasure. My hope is we can make a roadmap that meets the needs of many Bugzillas and is more than strictly maintenance work. > On 30/11/15 03:14, Dylan Hardison wrote: >> I also ran a few simple queries against open bugs on BMO, ordered by >> the number of CC's by specific accounts. Many of those bugs are very >> old, have very little activity >> and (in my humble opinion) examples of "perfect is the enemy of good". > > As in, what the bug requests is too perfect and so has not been > actioned? Or in the bug, people have argued for something simple and > been rebuffed? Both of those situations happen. Usually new work gets blocked by re-architecture requests as well. Let's not dwell on that though. We can just fix things moving forward. >> What I've compiled (which is not much) is now available on the wiki page: >> https://wiki.mozilla.org/Bugzilla:Ideas > > The ideas are: > > 1) Webhooks or Push Connector API > > -- Can you explain what you mean by "webhooks" in this context, and > expand a bit more on what this would look like and what it would let you do? The ability of a user to subscribe to bug changes, so that when a change happens an (out of process, as in bugmail or the push connector itself) HTTP request is made. You could use this to hook up changes in a product to invoke a CI system or so on. It is something we're going to be doing to BMO using the push connector. I think for now we can change this item to just "adopt the push connector" (although it will require a few tweaks to be extensible). > 2) Auth Stack Changes > > -- If the auth stack is getting in the way of people actually using it > to authenticate things, we should fix that, yes. BMO has some plans in > this area, I believe - what are they, do you know? The entire auth stack below the level of Bugzilla->login should be simplified. BGO has an open bug for openid, BRC has an open bug for openid (and they also want to use SAML). Meanwhile, the changes to auth I'm doing for BMO are purely a simplification of what is there. The bug is https://bugzilla.mozilla.org/show_bug.cgi?id=1215314. Right now, auth looks a bit like this: https://hardison.net/~dylan/bugzilla-auth/internals/auth.html#execution-path-overview I would like to survey who is using the LDAP and RADIUS auth providers and if they couldn't be migrated to something more contemporary. > 3) Modernize UI > > -- I think we should definitely start from glob's work. Does it support > mobile? Bug Modal explicitly does not, although IMHO it looks better on mobile than the current system. Work on the header and footer would help that. I am looking into the feasibility of using bzdeck against 5.0+ bugzillas. I would like talking about it to be on the agenda for the December 23rd meeting. I think redhat is looking into redoing their show_bug as well, taking a different direction by scrapping template toolkit. Devel::NYTProf indicates TT2 is a significant performance problem. I think we need a separate page for performance improvements (I have a long list of these. most need benchmarking) > 4) Advanced Search UI Problems > > -- By "advanced" you mean the Boolean Charts stuff at the bottom of the > search page (as it used to be called)? This is indeed a great candidate > for an API-driven dynamic query builder rather than a bunch of dropdowns. once again, I'm just highlighting what (a couple) of bugzilla sites are planning on doing. > 5) Product/Component Watching > > -- I agree the extension should be shipped with core or be reimplemented > in core. From denis.roy at eclipse.org Tue Dec 8 21:27:51 2015 From: denis.roy at eclipse.org (Denis Roy) Date: Tue, 08 Dec 2015 16:27:51 -0500 Subject: Have a separate Bugzilla installation for the Bugzilla project? In-Reply-To: <565FAADA.6060203@bugzilla.org> References: <565B0CAB.5040709@gmail.com> <565C773E.4040109@mozilla.org> <565C7C30.9090303@bugzilla.org> <565F9B55.2070709@eclipse.org> <565FAADA.6060203@bugzilla.org> Message-ID: <56674B57.2010001@eclipse.org> Thanks... I have my plate busy with $DAY_JOB stuff but I expect to have this going sometime next week. Since this is the first ever vserver for a non-Eclipse project, we'll set up a host on our DMZ, outside of our firewall. Denis On 12/02/2015 09:37 PM, Dave Miller wrote: > In the grand scheme of things, the Bugzilla project is pretty small. I > highly doubt we'd need anything more than a dual core server with 8GB of > RAM or so. (Maybe less RAM, depends on how bad mod_perl kills it, but > mod_perl is RAM-hungry). Bugzilla.mozilla.org is a many-headed beast > because of Firefox and friends. :-) Having the DB on a separate box > from the webserver may be good for performance. > > Denis Roy wrote: >> If there's consensus, then I'd appreciate knowing what the project team >> needs to run. >> >> We use SuSE Linux Entreprise 12 which has everything needed to run a >> Bugzilla instance. Aside from the obvious Perl, MariaDB and other >> related bits, what is needed in terms of hardware specs? >> >> Denis >> >> >> On 30/11/15 11:41 AM, Dave Miller wrote: >>> Gervase Markham wrote: >>>> On 29/11/15 14:33, Fr?d?ric Buclin wrote: >>>>> I would suggest that >>>>> the Bugzilla project has its own Bugzilla installation, managed by the >>>>> upstream Bugzilla team itself. >>>> I agree that now is the time for this, particularly given the very >>>> generous offer from Denis and the Eclipse team. >>> I agree as well. I was going to say that we probably ought to wait for >>> BMO to finish their current upstream merge and see where that puts us, >>> but I think the Eclipse offer gives us a pretty good excuse to do it >>> anyway :) We have actually wanted it for a while, everyone's just >>> scared of the work involved in migrating. >>> >> >> - >> To view or change your list settings, click here: >> > From gerv at mozilla.org Wed Dec 23 15:57:35 2015 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 23 Dec 2015 15:57:35 +0000 Subject: Bugzilla meeting today, 21:00 UTC Message-ID: Hi everyone, Remember there's a Bugzilla meeting today at 21:00 UTC: http://arewemeetingyet.com/UTC/2015-12-23/21:00/Bugzilla%20Meeting I look forward to seeing you all :-) Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From denis.roy at eclipse.org Wed Dec 23 16:03:09 2015 From: denis.roy at eclipse.org (Denis Roy) Date: Wed, 23 Dec 2015 11:03:09 -0500 Subject: Bugzilla meeting today, 21:00 UTC In-Reply-To: References: Message-ID: <567AC5BD.1010800@eclipse.org> Thanks for the reminder. I will be there. D. On 12/23/2015 10:57 AM, Gervase Markham wrote: > Hi everyone, > > Remember there's a Bugzilla meeting today at 21:00 UTC: > http://arewemeetingyet.com/UTC/2015-12-23/21:00/Bugzilla%20Meeting > > I look forward to seeing you all :-) > > Gerv > _______________________________________________ > dev-apps-bugzilla mailing list > dev-apps-bugzilla at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-apps-bugzilla > - > To view or change your list settings, click here: > > From theycallmefish at gmail.com Wed Dec 23 17:29:34 2015 From: theycallmefish at gmail.com (Ryan Wilson) Date: Wed, 23 Dec 2015 17:29:34 +0000 Subject: Bugzilla meeting today, 21:00 UTC In-Reply-To: <567AC5BD.1010800@eclipse.org> References: <567AC5BD.1010800@eclipse.org> Message-ID: Unfortunately, I will not be making it to today's meeting. On Wed, Dec 23, 2015 at 9:03 AM Denis Roy wrote: > Thanks for the reminder. I will be there. > > D. > > On 12/23/2015 10:57 AM, Gervase Markham wrote: > > Hi everyone, > > > > Remember there's a Bugzilla meeting today at 21:00 UTC: > > http://arewemeetingyet.com/UTC/2015-12-23/21:00/Bugzilla%20Meeting > > > > I look forward to seeing you all :-) > > > > Gerv > > _______________________________________________ > > dev-apps-bugzilla mailing list > > dev-apps-bugzilla at lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-apps-bugzilla > > - > > To view or change your list settings, click here: > > > > > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dylan at mozilla.com Wed Dec 23 18:34:28 2015 From: dylan at mozilla.com (Dylan Hardison) Date: Wed, 23 Dec 2015 13:34:28 -0500 Subject: Bugzilla meeting today, 21:00 UTC In-Reply-To: References: Message-ID: Note I've started an agenda on https://wiki.mozilla.org/Bugzilla:Meetings#Agenda On Wed, Dec 23, 2015 at 10:57 AM, Gervase Markham wrote: > Hi everyone, > > Remember there's a Bugzilla meeting today at 21:00 UTC: > http://arewemeetingyet.com/UTC/2015-12-23/21:00/Bugzilla%20Meeting > > I look forward to seeing you all :-) > > Gerv > _______________________________________________ > dev-apps-bugzilla mailing list > dev-apps-bugzilla at lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-apps-bugzilla > - > To view or change your list settings, click here: > From altlist at gmail.com Wed Dec 23 19:01:13 2015 From: altlist at gmail.com (Albert Ting) Date: Wed, 23 Dec 2015 11:01:13 -0800 Subject: Bugzilla meeting today, 21:00 UTC In-Reply-To: References: Message-ID: Hi Dylan, I won't be able to make it. But would like to get closure on the Markdown feature. It works quite well, yet using fair number of patches that have not yet been reviewed/approved. On Wed, Dec 23, 2015 at 10:34 AM, Dylan Hardison wrote: > Note I've started an agenda on > https://wiki.mozilla.org/Bugzilla:Meetings#Agenda > > On Wed, Dec 23, 2015 at 10:57 AM, Gervase Markham > wrote: > > Hi everyone, > > > > Remember there's a Bugzilla meeting today at 21:00 UTC: > > http://arewemeetingyet.com/UTC/2015-12-23/21:00/Bugzilla%20Meeting > > > > I look forward to seeing you all :-) > > > > Gerv > > _______________________________________________ > > dev-apps-bugzilla mailing list > > dev-apps-bugzilla at lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-apps-bugzilla > > - > > To view or change your list settings, click here: > > > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dylan at mozilla.com Wed Dec 23 19:16:23 2015 From: dylan at mozilla.com (Dylan Hardison) Date: Wed, 23 Dec 2015 14:16:23 -0500 Subject: Bugzilla meeting today, 21:00 UTC In-Reply-To: References: Message-ID: I will add that to the agenda. On Wed, Dec 23, 2015 at 2:01 PM, Albert Ting wrote: > Hi Dylan, > > I won't be able to make it. But would like to get closure on the Markdown > feature. It works quite well, yet using fair number of patches that have not > yet been reviewed/approved. > > On Wed, Dec 23, 2015 at 10:34 AM, Dylan Hardison wrote: >> >> Note I've started an agenda on >> https://wiki.mozilla.org/Bugzilla:Meetings#Agenda >> >> On Wed, Dec 23, 2015 at 10:57 AM, Gervase Markham >> wrote: >> > Hi everyone, >> > >> > Remember there's a Bugzilla meeting today at 21:00 UTC: >> > http://arewemeetingyet.com/UTC/2015-12-23/21:00/Bugzilla%20Meeting >> > >> > I look forward to seeing you all :-) >> > >> > Gerv >> > _______________________________________________ >> > dev-apps-bugzilla mailing list >> > dev-apps-bugzilla at lists.mozilla.org >> > https://lists.mozilla.org/listinfo/dev-apps-bugzilla >> > - >> > To view or change your list settings, click here: >> > >> - >> To view or change your list settings, click here: >> > > From dylan at mozilla.com Thu Dec 24 17:33:28 2015 From: dylan at mozilla.com (Dylan Hardison) Date: Thu, 24 Dec 2015 12:33:28 -0500 Subject: Porting Modal UI to upstream Message-ID: I think porting the modal UI to upstream is a good thing to do. So I'm doing that. it's probably a lot of work. To that end, I've started a branch of the current trunk to contain and share the effort. Bug Modal specifically does not work with non-Mozilla (e.g. Sandstone) skins, and when you force it to (which I have done) it looks bad. So on top of this work, I've applied Ryan Wilson's Sandstone patch. Note that I have allowed the upstream port of Bug Modal to allow other skins to be selected. Any skins that can't be made to work with it we should probably drop. Note that with the .psgi support that has landed in trunk, it is possible to get a local dev environment set up with only perl + cpanm. I intend to write a blog post about this in short order. From dylan at mozilla.com Thu Dec 24 17:34:56 2015 From: dylan at mozilla.com (Dylan Hardison) Date: Thu, 24 Dec 2015 12:34:56 -0500 Subject: Porting Modal UI to upstream In-Reply-To: References: Message-ID: Woopsy. The said branch is https://github.com/dylanwh/bugzilla/tree/modal (a branch of a fork, to avoid cluttering the main repo with what might amount to just be noise). On Thu, Dec 24, 2015 at 12:33 PM, Dylan Hardison wrote: > I think porting the modal UI to upstream is a good thing to do. So I'm > doing that. > it's probably a lot of work. To that end, I've started a branch of the > current trunk to contain and share the effort. > > Bug Modal specifically does not work with non-Mozilla (e.g. Sandstone) skins, > and when you force it to (which I have done) it looks bad. So on top > of this work, I've applied Ryan Wilson's Sandstone patch. > > Note that I have allowed the upstream port of Bug Modal to allow other > skins to be selected. > Any skins that can't be made to work with it we should probably drop. > > Note that with the .psgi support that has landed in trunk, it is > possible to get a local dev environment set up with only perl + cpanm. > I intend to write a blog post about this in short order. From gerv at mozilla.org Tue Dec 29 11:52:10 2015 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 29 Dec 2015 11:52:10 +0000 Subject: Skins (was: Re: Porting Modal UI to upstream) In-Reply-To: References: Message-ID: <568273EA.9090108@mozilla.org> On 24/12/15 17:33, Dylan Hardison wrote: > Bug Modal specifically does not work with non-Mozilla (e.g. Sandstone) skins, > and when you force it to (which I have done) it looks bad. So on top > of this work, I've applied Ryan Wilson's Sandstone patch. Before we do a bunch of what may be unnecessary or wrongly-directed work here, we need to develop a skin strategy. This has come up in a few meetings. Currently, Bugzilla ships with two skins - Classic and Dusk. Users have the ability to choose the skin on a per-user basis. This means that unless admins have changed Bugzilla to stop users using that pref, any customizations admins do must be checked with both skins. Skins, AIUI, do not generally provide additional functionality. They just look different. I was to suggest that the high cost to us as Bugzilla developers and to admins of maintaining multiple skins is not worth it for the user value this generates. I think we should: * Keep a skins system * Ship a single skin * Remove the user preference for selecting a skin * Add an admin param to define the skin on a per-installation basis This preserves UI customizability for admins who want to make Bugzilla fit in with their environment, but removes the maintenance and customization burdens for us and for admins who are personally happy with the default. So if that logic seems good, which skin should we ship? 1) Dusk. This ships in the contrib directory, and yet became the default for new installations in bug 259723, nine years ago. 2) Classic. This ships in the "standard" skin location but has not been the default for a very long time. 3) Sandstone (Mozilla's skin; see https://bugzilla.mozilla.org/show_bug.cgi?id=988971 ) Classic seems obviously wrong - we moved to Dusk 9 years ago, why go backwards? Remember, we can take a skin and change the colours very easily. We could ship a Sandstone which looks quite a bit like Dusk; there's no need to keep the Sandstone colour. Gerv From gerv at mozilla.org Tue Dec 29 11:52:41 2015 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 29 Dec 2015 11:52:41 +0000 Subject: Porting Modal UI to upstream In-Reply-To: References: Message-ID: <56827409.7090204@mozilla.org> On 24/12/15 17:33, Dylan Hardison wrote: > I think porting the modal UI to upstream is a good thing to do. So I'm > doing that. Oh and BTW, this is a great thing :-) > Note that with the .psgi support that has landed in trunk, it is > possible to get a local dev environment set up with only perl + cpanm. > I intend to write a blog post about this in short order. As would that be! Gerv From lpsolit at gmail.com Tue Dec 29 12:48:47 2015 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Tue, 29 Dec 2015 13:48:47 +0100 Subject: Skins In-Reply-To: <568273EA.9090108@mozilla.org> References: <568273EA.9090108@mozilla.org> Message-ID: <5682812F.6060302@gmail.com> Le 29. 12. 15 12:52, Gervase Markham a ?crit : > Skins, AIUI, do not generally provide additional functionality. They > just look different. "just look different" is what skins are about, yes. The reason we ship two skins is because not everybody like the Classical skin, and not everybody like the Dusk skin. Even Firefox has themes/skins. Even BMO ships 6 different skins. There must be a reason. > I was to suggest that the high cost to us as > Bugzilla developers and to admins of maintaining multiple skins is not > worth it for the user value this generates. "High cost" where? How often did you, as a developer, have to deal with the fact that we ship 2 skins? As admin, the cost is zero. If you made customizations which do not play well with one of the skins, you just have to turn off this user pref and that's it. All users will be forced to use the skin selected by the admin. Shipping 2 skins has been a real plus for us. It forces us to think if the Classical skin (the one currently in skins/standard/) doesn't prevent custom skins from working correctly. For instance, we learned that "!important" should be avoided as much as possible, else it would take precedence over custom rules. Keeping only one skin will inevitably trigger such problems in the future. So IMO, a valid reason to keep only one skin would be because this skin is great enough that everybody like it, not because developers are too lazy to maintain a 2nd skin. Another point: it's currently very easy to write your own skin because you can imitate what is in contrib/Dusk/*.css. You can easily clone it in e.g. contrib/Foo/ and start playing with CSS files there. If we remove the 2nd skin, will the whole skins/contrib/ directory go away? If not, how to avoid the confusion between skins/contrib/ and skins/custom/? (and do we really still need skins/custom/, to begin with?) > * Remove the user preference for selecting a skin > * Add an admin param to define the skin on a per-installation basis This brings no value, and doesn't make anyone's life easier. If an installation has only one working skin, then the admin can already force all users to use it. If there are several working skins, I see no reason to force everybody to use the same skin. I could even imagine that some skins are better suited for smartphones/small screens, or for users with visual disabilities who require a skin with higher contrast or a simplified UI or displayed differently to ease readability. LpSolit From gerv at mozilla.org Tue Dec 29 13:34:55 2015 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 29 Dec 2015 13:34:55 +0000 Subject: Skins In-Reply-To: <5682812F.6060302@gmail.com> References: <568273EA.9090108@mozilla.org> <5682812F.6060302@gmail.com> Message-ID: <56828BFF.3060107@mozilla.org> On 29/12/15 12:48, Fr?d?ric Buclin wrote: > "just look different" is what skins are about, yes. The reason we ship > two skins is because not everybody like the Classical skin, and not > everybody like the Dusk skin. I am sure people express preferences; we have to balance the engineering effort and admin effort required to indulge those preferences against the level of user benefit it brings. I agree the user benefit is non-zero (although it might be less if we had one skin which we made a good job of and which could appeal to a wider group, rather than dividing our efforts). > Even Firefox has themes/skins. Firefox recently deprecated its heavyweight theming system ("complete themes") precisely because of the maintainability burden. It retains "themes" (which used to be called "personas"), but these are basically just a single background image which goes behind the toolbar. That level of complexity is fairly easy to support. > Even BMO > ships 6 different skins. Actually, AIUI the BMO team only really support Sandstone, and are thinking of formally dropping support for the other skins. The new modal UI only works with Sandstone. Perhaps someone from the team reading this list can comment? > "High cost" where? How often did you, as a developer, have to deal with > the fact that we ship 2 skins? Well, when Dylan is working on porting the bug modal UI, he's going to need to deal with it. :-) > As admin, the cost is zero. If you made > customizations which do not play well with one of the skins, you just > have to turn off this user pref and that's it. All users will be forced > to use the skin selected by the admin. Except that if the admin doesn't test with the other skin, users who use it see breakage and they don't know why. They might report it (or they might not) and after he's debugged it and worked out that it's the skin, he then has to work out that it's possible to withdraw the skin option and do it, and _then_ he has to deal with the annoyed users. > Shipping 2 skins has been a real plus for us. It forces us to think if > the Classical skin (the one currently in skins/standard/) doesn't > prevent custom skins from working correctly. For instance, we learned > that "!important" should be avoided as much as possible, else it would > take precedence over custom rules. Give me a quick refresher: you are saying that if someone invokes a custom skin, we load _both_ the Classic and the custom skin's CSS? > Keeping only one skin will inevitably > trigger such problems in the future. So IMO, a valid reason to keep only > one skin would be because this skin is great enough that everybody like > it, not because developers are too lazy to maintain a 2nd skin. Let's say for a moment that the group concludes you are right. How does Sandstone fit in? Do we want it, or not? If we do, do we ship 3 skins, or do we drop one? If we drop one, which? > Another point: it's currently very easy to write your own skin because > you can imitate what is in contrib/Dusk/*.css. You can easily clone it > in e.g. contrib/Foo/ and start playing with CSS files there. If we > remove the 2nd skin, will the whole skins/contrib/ directory go away? If > not, how to avoid the confusion between skins/contrib/ and > skins/custom/? (and do we really still need skins/custom/, to begin with?) Another good question. "Contrib" in Bugzilla speak is supposed to mean "OK, we ship this in case it's useful, but we don't support it". That's clearly not true of Dusk. > This brings no value, and doesn't make anyone's life easier. If an > installation has only one working skin, then the admin can already force > all users to use it. If there are several working skins, I see no reason > to force everybody to use the same skin. I could even imagine that some > skins are better suited for smartphones/small screens, Our default skin should be suitable for these use cases. > or for users with > visual disabilities who require a skin with higher contrast or a > simplified UI or displayed differently to ease readability. These things are much better dealt with by using accessible web design (for everyone) and letting the disabled user's user agent work out how best to present the information to them. We can't second-guess the requirements for everyone. Has anyone ever built a skin for Bugzilla focussed around the needs of disabled users? Gerv From lpsolit at gmail.com Tue Dec 29 14:20:40 2015 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Tue, 29 Dec 2015 15:20:40 +0100 Subject: Skins In-Reply-To: <56828BFF.3060107@mozilla.org> References: <568273EA.9090108@mozilla.org> <5682812F.6060302@gmail.com> <56828BFF.3060107@mozilla.org> Message-ID: <568296B8.3040905@gmail.com> Le 29. 12. 15 14:34, Gervase Markham a ?crit : >> "High cost" where? How often did you, as a developer, have to deal with >> the fact that we ship 2 skins? > > Well, when Dylan is working on porting the bug modal UI, he's going to > need to deal with it. :-) This doesn't mean the cost will be high. ;) > Give me a quick refresher: you are saying that if someone invokes a > custom skin, we load _both_ the Classic and the custom skin's CSS? Yes, because the custom skin only contains changes made against the Classic skin. It doesn't need to contain all rules. This is why writing a new skin is easy: you just edit the few rules you want to change, such as the background color. For instance, standard/buglist.css is 9.6KB while contrib/Dusk/buglist.css is only 386 bytes. And standard/global.css is 19KB while contrib/Dusk/global.css is only 3.7KB. So even if dylan has to rewrite CSS files heavily in standard/, he only has to edit a few rules in contrib/ assuming they are still relevant. This is much less painful than to have to maintain the whole set of rules again. > Let's say for a moment that the group concludes you are right. How does > Sandstone fit in? Do we want it, or not? If we do, do we ship 3 skins, > or do we drop one? If we drop one, which? We certainly want Sandstone, and it certainly could become the new default skin. As you said, Dusk replaced Classic as the default skin since Bugzilla 3.2 and so we don't want Classic back as the default skin. I gave a quick look at the 40 Bugzilla installations I'm watching, and many of them use their own skin by default, or Dusk (for those running 4.4 and newer) or Classic (for those running 4.2 and older, i.e. "obsolete" installations). So if my understanding is correct, there is a move towards Dusk. So my proposal would be: replace Classic by Standstone, and make it the new default skin for Bugzilla 6.0 (if done on time for 6.0, of course). This way 1) skins/standard/ would really be the place for the default skin, which makes sense, and 2) we could still offer an alternative to users, aka Dusk (but we would need to see how the final Standstone implementation would look like to know what to change in Dusk), and 3) we don't need to support an extra 3rd skin. LpSolit