From glob at mozilla.com Mon Sep 1 07:05:48 2014 From: glob at mozilla.com (Byron Jones) Date: Mon, 01 Sep 2014 15:05:48 +0800 Subject: Important news regarding future YUI development In-Reply-To: <5400CEFB.4020901@mozilla.com> References: <5400CEFB.4020901@mozilla.com> Message-ID: <54041ACC.9060808@mozilla.com> David Lawrence wrote: > Unfortunately it seems Yahoo is taking a different direction and all development work > on YUI has stopped effective immediately. > > http://yahooeng.tumblr.com/post/96098168666/important-announcement-regarding-yui that's a shame :( > Since we are not too far along yet unfortunately this isn't accurate. while there isn't work ready to commit, significant effort has been put into the yui3 migration, and there's already a lot of work against that branch. that said, i think it would be wise to shelf that work, and instead move to jquery. before we start throwing frameworks at the list and hope one of them stick, i think it would be prudent to first document our requirements. thankfully we make very sparten use of yui, and the gsoc yui3 project work can be used roadmap towards js/template that will need to be touched once a framework and plugins are chosen. here's my start: requirements: - jquery based - compatible license (foss) - cross-browser support - wai/aria support - localisation support widgets/plugins: - data tables/grids with ajax support - auto-completion with ajax support - calendar -- byron jones - :glob - bugzilla.mozilla.org team - -------------- next part -------------- An HTML attachment was scrubbed... URL: From emmanuel at seyman.fr Mon Sep 1 07:21:35 2014 From: emmanuel at seyman.fr (Emmanuel Seyman) Date: Mon, 1 Sep 2014 09:21:35 +0200 Subject: Important news regarding future YUI development In-Reply-To: <54041ACC.9060808@mozilla.com> References: <5400CEFB.4020901@mozilla.com> <54041ACC.9060808@mozilla.com> Message-ID: <20140901072135.GA10493@orient> * Byron Jones [01/09/2014 15:05] : > > that's a shame :( +1 > that said, i think it would be wise to shelf that work, and instead move to jquery. Unless there's a massive amount of work left to be done, I'ld prefer we move to yui3. It might not have a lot going for it but, at least, it's maintained, unlike yui 2.x . Emmanuel _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From glob at mozilla.com Mon Sep 1 08:21:46 2014 From: glob at mozilla.com (Byron Jones) Date: Mon, 01 Sep 2014 16:21:46 +0800 Subject: Important news regarding future YUI development In-Reply-To: <20140901072135.GA10493@orient> References: <5400CEFB.4020901@mozilla.com> <54041ACC.9060808@mozilla.com> <20140901072135.GA10493@orient> Message-ID: <54042C9A.2090606@mozilla.com> Emmanuel Seyman wrote: >> > that said, i think it would be wise to shelf that work, and instead move to jquery. > Unless there's a massive amount of work left to be done, I'ld prefer we > move to yui3. It might not have a lot going for it but, at least, it's > maintained, unlike yui 2.x . i honestly don't think moving to a platform which has already been announced as deprecated would be a good idea. yui3 will die a slow death, and we'd be left, yet again, using an old technology that nobody wants to work with (see also: bzr). -glob -- byron jones - :glob - bugzilla.mozilla.org team - _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Mon Sep 1 15:14:47 2014 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 01 Sep 2014 16:14:47 +0100 Subject: Important news regarding future YUI development In-Reply-To: References: <5400CEFB.4020901@mozilla.com> <54041ACC.9060808@mozilla.com> <20140901072135.GA10493@orient> Message-ID: On 01/09/14 09:21, Byron Jones wrote: > i honestly don't think moving to a platform which has already been > announced as deprecated would be a good idea. > yui3 will die a slow death, and we'd be left, yet again, using an old > technology that nobody wants to work with (see also: bzr). I agree with this. YUI wasn't all that popular even when it was supported. I'm a Bugzilla developer, and I haven't bothered to learn it :-) I would certainly back a process where we stepped back and looked at where things are now in client side web development best practice and where they are going. This should be led by someone who had already heard of Grunt, Broccoli, Gulp, Backbone, React, Ember, Polymer, Angular, Mocha, Casper and Karma before reading the YUI announcement! (I hadn't heard of most of them - perhaps that's just me, though.) Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From glob at mozilla.com Mon Sep 1 16:28:31 2014 From: glob at mozilla.com (Byron Jones) Date: Tue, 02 Sep 2014 00:28:31 +0800 Subject: Important news regarding future YUI development In-Reply-To: References: <5400CEFB.4020901@mozilla.com> <54041ACC.9060808@mozilla.com> <20140901072135.GA10493@orient> Message-ID: <54049EAF.3050304@mozilla.com> Gervase Markham wrote: > I would certainly back a process where we stepped back and looked at > where things are now in client side web development best practice and > where they are going. This should be led by someone who had already > heard of Grunt, Broccoli, Gulp, Backbone, React, Ember, Polymer, > Angular, Mocha, Casper and Karma before reading the YUI announcement! (I > hadn't heard of most of them - perhaps that's just me, though.) most of those aren't relevant to bugzilla (task runner, client-side asset builder, build system, testing, complete frameworks, ...). modern javascript web development generally doesn't mesh well with large legacy applications, and i'm concerned that taking a step back at this stage to evaluate a large rewrite of the UI would not result in timely decision. our immediate need is to determine if we should continue the yui3 path, or move to a jquery based widget library. if we decide to move to jquery, then we should be talking about widget libraries, not wholesale rewrites. -- byron jones - :glob - bugzilla.mozilla.org team - -------------- next part -------------- An HTML attachment was scrubbed... URL: From guy.pyrzak at gmail.com Mon Sep 1 22:48:22 2014 From: guy.pyrzak at gmail.com (Guy Pyrzak) Date: Mon, 1 Sep 2014 15:48:22 -0700 Subject: Important news regarding future YUI development In-Reply-To: <54049EAF.3050304@mozilla.com> References: <5400CEFB.4020901@mozilla.com> <54041ACC.9060808@mozilla.com> <20140901072135.GA10493@orient> <54049EAF.3050304@mozilla.com> Message-ID: To help clarify. Mocha, qunit, and jasmine are all for testing JavaScript. Mockjax, Sinon would help with that. These are framework/library independent and could be used with yui3, bootstrap, or jquery ui. The fact that Bugzilla has JavaScript code that has no testing code associated with it ( other than selenium scripts) is something that should be considered and corrected. I agree that Angular, React, Polymer, ember, gulp, grunt or broccoli are not as worth while as they are frameworks or node.js dependent. -Guy On Monday, September 1, 2014, Byron Jones wrote: > Gervase Markham wrote: > > I would certainly back a process where we stepped back and looked at > where things are now in client side web development best practice and > where they are going. This should be led by someone who had already > heard of Grunt, Broccoli, Gulp, Backbone, React, Ember, Polymer, > Angular, Mocha, Casper and Karma before reading the YUI announcement! (I > hadn't heard of most of them - perhaps that's just me, though.) > > most of those aren't relevant to bugzilla (task runner, client-side asset > builder, build system, testing, complete frameworks, ...). > > modern javascript web development generally doesn't mesh well with large > legacy applications, and i'm concerned that taking a step back at this > stage to evaluate a large rewrite of the UI would not result in timely > decision. > > our immediate need is to determine if we should continue the yui3 path, or > move to a jquery based widget library. > if we decide to move to jquery, then we should be talking about widget > libraries, not wholesale rewrites. > > -- > byron jones - :glob - bugzilla.mozilla.org team - > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcote at bugzilla.org Tue Sep 2 00:43:11 2014 From: mcote at bugzilla.org (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Mon, 01 Sep 2014 20:43:11 -0400 Subject: Proposal for target milestones Message-ID: At last Wednesday's Bugzilla meeting, when discussing remaining blockers for Bugzilla 5.0, we discussed how we flag bugs for inclusion into a given release. At the moment, we use both the Target Milestone and the whiteboard for this purpose. The Target Milestone currently serves two purposes: flagging bugs we think would be nice to include in a given release (the next one or a future one), and flagging bugs that have been fixed (but not necessarily flagged ahead of time) and will be included in the next version. The white board tag, e.g. [Roadmap: 5.0], is used to denote bugs that we think *really* should be in that release. This system may have worked well in the past, but in our current development process, where we have a stable product and a small pool of contributors, it's essentially backwards. Since the number of new features is relatively low, at least compared with earlier Bugzilla versions, we are moving to a model in which we ship whatever we have every 6 months or so, or if there's a really big or useful feature that we want to get out. Development of the latter tends to come from features that are needed in site installations, such as Red Hat's or Mozilla's. Other commits tend to be smaller bug fixes that volunteers sporadically contribute. We end up with lots and lots of Target Milestones that have no reasonable chance of being resolved and just get moved from version to version after each release. Thus I propose that our policy for using the Target Milestone be as follows: * Bugs that are being actively worked on and are anticipated to be finished before the next release, as well as bugs officially designated as blockers, should have the Target Milestone set, and only to the next anticipated release. * Only the bug's assignee or a Bugzilla reviewer/approver should set or unset the Target Milestone. * As we currently do, bugs without a Target Milestone that are committed before an upcoming release should set it after the patch is committed. * We will stop using the [Roadmap: X] white board tag. Everyone at the meeting was in agreement, but I want to turn it over to the forum for any discussion before making it official. Mark -- Mark C?t? Assistant Project Lead, Bugzilla _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From glob at mozilla.com Tue Sep 2 04:23:04 2014 From: glob at mozilla.com (Byron Jones) Date: Tue, 02 Sep 2014 12:23:04 +0800 Subject: Proposal for target milestones In-Reply-To: References: Message-ID: <54054628.9000608@mozilla.com> Mark C?t? wrote: > Thus I propose that our policy for using the Target Milestone be as follows: > > * Bugs that are being actively worked on and are anticipated to be > finished before the next release, as well as bugs officially designated > as blockers, should have the Target Milestone set, and only to the next > anticipated release. > > * Only the bug's assignee or a Bugzilla reviewer/approver should set or > unset the Target Milestone. > > * As we currently do, bugs without a Target Milestone that are committed > before an upcoming release should set it after the patch is committed. nit: the current policy is for the approver to set the milestone - it probably makes sense to continue this practice instead of setting the milestone when a bug is marked as fixed. > * We will stop using the [Roadmap: X] white board tag. > > Everyone at the meeting was in agreement, but I want to turn it over to > the forum for any discussion before making it official. -- byron jones - :glob - bugzilla.mozilla.org team - -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Tue Sep 2 12:15:03 2014 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 02 Sep 2014 13:15:03 +0100 Subject: Proposal for target milestones In-Reply-To: References: Message-ID: <5405B4C7.9050909@mozilla.org> On 02/09/14 01:43, Mark C?t? wrote: > Everyone at the meeting was in agreement, but I want to turn it over to > the forum for any discussion before making it official. Let's do it. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From damien.nozay at gmail.com Tue Sep 2 16:04:51 2014 From: damien.nozay at gmail.com (Damien) Date: Tue, 2 Sep 2014 09:04:51 -0700 Subject: Important news regarding future YUI development In-Reply-To: References: <5400CEFB.4020901@mozilla.com> <54041ACC.9060808@mozilla.com> <20140901072135.GA10493@orient> <54049EAF.3050304@mozilla.com> Message-ID: ... actually, node.js could be used to serve REST APIs. There is much less value in a MV* framework when the rest api is lacking; so yes, Angular and friends wouldn't have as much value. What do I mean? I mean that my experience as a bugzilla user is that one big page is loaded, that sometimes I get iframes for searching duplicate bugs, but other than that you cannot do everything from one page. Where are all the fragments? That is a different discussion though. How about the stakeholders put a criteria list forward to help pick the UI framework? Things like accessibility for example should not be discounted. On Mon, Sep 1, 2014 at 3:48 PM, Guy Pyrzak wrote: > To help clarify. > > Mocha, qunit, and jasmine are all for testing JavaScript. Mockjax, Sinon > would help with that. These are framework/library independent and could be > used with yui3, bootstrap, or jquery ui. > > The fact that Bugzilla has JavaScript code that has no testing code > associated with it ( other than selenium scripts) is something that should > be considered and corrected. > > I agree that Angular, React, Polymer, ember, gulp, grunt or broccoli are > not as worth while as they are frameworks or node.js dependent. > > -Guy > > On Monday, September 1, 2014, Byron Jones wrote: > >> Gervase Markham wrote: >> >> I would certainly back a process where we stepped back and looked at >> where things are now in client side web development best practice and >> where they are going. This should be led by someone who had already >> heard of Grunt, Broccoli, Gulp, Backbone, React, Ember, Polymer, >> Angular, Mocha, Casper and Karma before reading the YUI announcement! (I >> hadn't heard of most of them - perhaps that's just me, though.) >> >> most of those aren't relevant to bugzilla (task runner, client-side >> asset builder, build system, testing, complete frameworks, ...). >> >> modern javascript web development generally doesn't mesh well with large >> legacy applications, and i'm concerned that taking a step back at this >> stage to evaluate a large rewrite of the UI would not result in timely >> decision. >> >> our immediate need is to determine if we should continue the yui3 path, >> or move to a jquery based widget library. >> if we decide to move to jquery, then we should be talking about widget >> libraries, not wholesale rewrites. >> >> -- >> byron jones - :glob - bugzilla.mozilla.org team - >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.nozay at gmail.com Tue Sep 2 16:29:10 2014 From: damien.nozay at gmail.com (Damien) Date: Tue, 2 Sep 2014 09:29:10 -0700 Subject: Proposal for target milestones In-Reply-To: References: Message-ID: inline comments about how those fields are used in places I know about... On Mon, Sep 1, 2014 at 5:43 PM, Mark C?t? wrote: > At last Wednesday's Bugzilla meeting, when discussing remaining > blockers for Bugzilla 5.0, we discussed how we flag bugs for inclusion > into a given release. At the moment, we use both the Target Milestone > and the whiteboard for this purpose. > > The Target Milestone currently serves two purposes: flagging bugs we > think would be nice to include in a given release (the next one or a > future one), and flagging bugs that have been fixed (but not necessarily > flagged ahead of time) and will be included in the next version. The > white board tag, e.g. [Roadmap: 5.0], is used to denote bugs that we > think *really* should be in that release. > Are we making assumptions there? What if a team wants to follow agile processes? Would that become a tedious activity? > > This system may have worked well in the past, but in our current > development process, where we have a stable product and a small pool of > contributors, it's essentially backwards. Since the number of new > features is relatively low, at least compared with earlier Bugzilla > versions, we are moving to a model in which we ship whatever we have > every 6 months or so, or if there's a really big or useful feature that > we want to get out. Development of the latter tends to come from > features that are needed in site installations, such as Red Hat's or > Mozilla's. Other commits tend to be smaller bug fixes that volunteers > sporadically contribute. We end up with lots and lots of Target > Milestones that have no reasonable chance of being resolved and just get > moved from version to version after each release. > agile: everything goes in the "backlog", "backlog" would be an interesting value to add to your target milestones. > > Thus I propose that our policy for using the Target Milestone be as > follows: > > * Bugs that are being actively worked on and are anticipated to be > finished before the next release, as well as bugs officially designated > as blockers, should have the Target Milestone set, and only to the next > anticipated release. > agile: they would be in "backlog" to begin with, and if somebody is working on them, then let's assume product owner moved them to the release backlog or sprint backlog. > * Only the bug's assignee or a Bugzilla reviewer/approver should set or > unset the Target Milestone. > agile: only the product owner would do that. new bugs go to the backlog. ... I lie, we need to distinguish bugs from features. if the bug is introduced based on some other bug getting worked on, then that would belong to the same sprint. Maybe if you are not product owner, your choices get restricted to either current sprint or backlog. > > * As we currently do, bugs without a Target Milestone that are committed > before an upcoming release should set it after the patch is committed. > This is making the assumption that people work on what they want to work on rather than on what they have been appointed to work on. Not all processes are like that. It's okay for you to say it should be one way or another for bmo, but for users out there, please consider that it is not the only workflow. If you have a milestone "current sprint" or "current", you can always rename that when you branch the code or change versions. Is target milestone normalized? > > * We will stop using the [Roadmap: X] white board tag. > > Everyone at the meeting was in agreement, but I want to turn it over to > the forum for any discussion before making it official. > > Mark > -- > Mark C?t? > Assistant Project Lead, Bugzilla > _______________________________________________ > 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: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From glob at mozilla.com Tue Sep 2 16:47:08 2014 From: glob at mozilla.com (Byron Jones) Date: Wed, 03 Sep 2014 00:47:08 +0800 Subject: Proposal for target milestones In-Reply-To: References: Message-ID: <5405F48C.30901@mozilla.com> Damien wrote: > > The Target Milestone currently serves two purposes: flagging bugs we > think would be nice to include in a given release (the next one or a > future one), and flagging bugs that have been fixed (but not > necessarily > flagged ahead of time) and will be included in the next version. The > white board tag, e.g. [Roadmap: 5.0], is used to denote bugs that we > think *really* should be in that release. > > > Are we making assumptions there? What if a team wants to follow agile > processes? > Would that become a tedious activity? [snip] > This is making the assumption that people work on what they want to > work on > rather than on what they have been appointed to work on. Not all processes > are like that. It's okay for you to say it should be one way or > another for > bmo, but for users out there, please consider that it is not the only > workflow. i think you may have miss-understood the context of this email. we are discussing how the bugzilla team intend to track development on bugzilla itself. these changes don't have any impact on any other teams or bugzilla installations. -glob -- byron jones - :glob - bugzilla.mozilla.org team - -------------- next part -------------- An HTML attachment was scrubbed... URL: From damien.nozay at gmail.com Tue Sep 2 16:47:56 2014 From: damien.nozay at gmail.com (Damien) Date: Tue, 2 Sep 2014 09:47:56 -0700 Subject: Proposal for target milestones In-Reply-To: <5405F48C.30901@mozilla.com> References: <5405F48C.30901@mozilla.com> Message-ID: thanks for the clarification. On Tue, Sep 2, 2014 at 9:47 AM, Byron Jones wrote: > Damien wrote: > > The Target Milestone currently serves two purposes: flagging bugs we >> think would be nice to include in a given release (the next one or a >> future one), and flagging bugs that have been fixed (but not necessarily >> flagged ahead of time) and will be included in the next version. The >> white board tag, e.g. [Roadmap: 5.0], is used to denote bugs that we >> think *really* should be in that release. >> > > Are we making assumptions there? What if a team wants to follow agile > processes? > Would that become a tedious activity? > > [snip] > > This is making the assumption that people work on what they want to > work on > rather than on what they have been appointed to work on. Not all processes > are like that. It's okay for you to say it should be one way or another for > bmo, but for users out there, please consider that it is not the only > workflow. > > i think you may have miss-understood the context of this email. > > we are discussing how the bugzilla team intend to track development on > bugzilla itself. > these changes don't have any impact on any other teams or bugzilla > installations. > > > > -glob > > > -- > byron jones - :glob - bugzilla.mozilla.org team - > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dmarshal at yahoo-inc.com Tue Sep 2 17:28:27 2014 From: dmarshal at yahoo-inc.com (David Marshall) Date: Tue, 2 Sep 2014 10:28:27 -0700 Subject: Important news regarding future YUI development In-Reply-To: <54042C9A.2090606@mozilla.com> References: <5400CEFB.4020901@mozilla.com> <54041ACC.9060808@mozilla.com> <20140901072135.GA10493@orient> <54042C9A.2090606@mozilla.com> Message-ID: <1409678907.18747.YahooMailNeo@web310001.mail.ne1.yahoo.com> On Monday, September 1, 2014 1:23 AM, Byron Jones wrote: > Emmanuel Seyman wrote: > >> > that said, i think it would be wise to shelf that work, and instead > >> > move to jquery. > > Unless there's a massive amount of work left to be done, I'ld prefer we > > move to yui3. It might not have a lot going for it but, at least, it's > > maintained, unlike yui 2.x . > i honestly don't think moving to a platform which has already been > announced as deprecated would be a good idea. > yui3 will die a slow death, and we'd be left, yet again, using an old > technology that nobody wants to work with (see also: bzr). I don't disagree that Bugzilla may quite reasonably move to a YUI alternative, but it's not quite accurate to describe YUI as deprecated. All that's been said is that Yahoo employees won't be spending their time doing new YUI 3 development. There's a developer community apart from Yahoo employees, and it is ultimately they who will determine the relevance of YUI going forward. _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From mcote at bugzilla.org Wed Sep 3 01:02:07 2014 From: mcote at bugzilla.org (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Tue, 02 Sep 2014 21:02:07 -0400 Subject: Important news regarding future YUI development In-Reply-To: References: <5400CEFB.4020901@mozilla.com> Message-ID: <_YidnYJu14oO9ZvJnZ2dnUVZ_qadnZ2d@mozilla.org> On 2014-09-01 3:05 AM, Byron Jones wrote: > widgets/plugins: In jQuery land, I've personally used the following: > - data tables/grids with ajax support http://datatables.net/ > - auto-completion with ajax support http://jqueryui.com/autocomplete/ (part of jQuery UI) > - calendar http://jqueryui.com/datepicker/ (also part of jQuery UI) Mark -- Mark C?t? Assistant Project Lead, Bugzilla _______________________________________________ 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 Wed Sep 3 04:03:34 2014 From: justdave at bugzilla.org (Dave Miller) Date: Wed, 03 Sep 2014 00:03:34 -0400 Subject: Important news regarding future YUI development In-Reply-To: <1409678907.18747.YahooMailNeo@web310001.mail.ne1.yahoo.com> References: <5400CEFB.4020901@mozilla.com> <54041ACC.9060808@mozilla.com> <20140901072135.GA10493@orient> <54042C9A.2090606@mozilla.com> <1409678907.18747.YahooMailNeo@web310001.mail.ne1.yahoo.com> Message-ID: <54069316.7060001@bugzilla.org> David Marshall wrote: > I don't disagree that Bugzilla may quite reasonably move to a YUI alternative, but it's not quite accurate to describe YUI as deprecated. All that's been said is that Yahoo employees won't be spending their time doing new YUI 3 development. There's a developer community apart from Yahoo employees, and it is ultimately they who will determine the relevance of YUI going forward. I was going to mention this, too. The announcement reads very much like Mozilla's announcement that it was dropping Thunderbird development. Thunderbird is still very much alive, just Mozilla isn't paying developers to work on it anymore. -- 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 Wed Sep 3 09:09:34 2014 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 03 Sep 2014 10:09:34 +0100 Subject: Important news regarding future YUI development In-Reply-To: <54069316.7060001@bugzilla.org> References: <5400CEFB.4020901@mozilla.com> <54041ACC.9060808@mozilla.com> <20140901072135.GA10493@orient> <54042C9A.2090606@mozilla.com> <1409678907.18747.YahooMailNeo@web310001.mail.ne1.yahoo.com> <54069316.7060001@bugzilla.org> Message-ID: <5406DACE.3080306@mozilla.org> On 03/09/14 05:03, Dave Miller wrote: > I was going to mention this, too. The announcement reads very much like > Mozilla's announcement that it was dropping Thunderbird development. > Thunderbird is still very much alive, just Mozilla isn't paying > developers to work on it anymore. That is so. And how that plays out does depend on how strong their non-Yahoo community is. However, choice of desktop email software and choice of web framework are not the same. The web moves fast; email, not so much. We ideally want to use something would-be developers of Bugzilla are familiar with, whereas it doesn't matter much at all to you what email client I use, and it doesn't matter to me what you use. We are also about to make the effort of a transition, and it does make sense not to transition to something which has already been put into "maintenance mode" in a fast-moving space, and of which knowledge among potential developers is inevitably going to decrease. Gerv From mcote at bugzilla.org Wed Sep 3 14:03:13 2014 From: mcote at bugzilla.org (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Wed, 03 Sep 2014 10:03:13 -0400 Subject: Important news regarding future YUI development In-Reply-To: References: <5400CEFB.4020901@mozilla.com> <54041ACC.9060808@mozilla.com> <20140901072135.GA10493@orient> <54042C9A.2090606@mozilla.com> <1409678907.18747.YahooMailNeo@web310001.mail.ne1.yahoo.com> <54069316.7060001@bugzilla.org> Message-ID: <6IadnehBk_88gprJnZ2dnUVZ_oOdnZ2d@mozilla.org> On 2014-09-03 5:09 AM, Gervase Markham wrote: > On 03/09/14 05:03, Dave Miller wrote: >> I was going to mention this, too. The announcement reads very much like >> Mozilla's announcement that it was dropping Thunderbird development. >> Thunderbird is still very much alive, just Mozilla isn't paying >> developers to work on it anymore. > > That is so. And how that plays out does depend on how strong their > non-Yahoo community is. > > However, choice of desktop email software and choice of web framework > are not the same. The web moves fast; email, not so much. We ideally > want to use something would-be developers of Bugzilla are familiar with, > whereas it doesn't matter much at all to you what email client I use, > and it doesn't matter to me what you use. > > We are also about to make the effort of a transition, and it does make > sense not to transition to something which has already been put into > "maintenance mode" in a fast-moving space, and of which knowledge among > potential developers is inevitably going to decrease. I agree with Gerv on all points. No, YUI isn't going away right now, but I would bet that it will follow the path of Bazaar, and slowly lose its user base and thus people with any knowledge of and experience with it. As Gerv pointed out, we're at the point where we either have to put more effort into the YUI3 conversion to finish it, or we use what lessons we learned there and move to a system that has much less likelihood of vanishing. We already decided that moving from Bazaar to git was a good idea for a number of reasons, despite Bazaar not being entirely abandoned, so I think similar reasoning should apply here. Mark -- Mark C?t? Assistant Project Lead, Bugzilla _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Tue Sep 9 12:15:22 2014 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 09 Sep 2014 13:15:22 +0100 Subject: "The Worst Bug Tracking Software" Message-ID: Posted to remind you all what a blessing Bugzilla is ;-) http://thedailywtf.com/Articles/The-Worst-Bug-Tracking-Software.aspx Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Wed Sep 10 13:47:09 2014 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 10 Sep 2014 14:47:09 +0100 Subject: Questions for docs, part 2 Message-ID: * Our install docs currently include a large and rather rambling section titled "UNIX (non-root) Installation Notes". It tells you how to build your own Apache and MySQL from scratch and run them on non-standard ports. In these days of open source virtualization software, with cheap VMs available everywhere, does anyone still install Bugzilla on a system where they don't have root? Do we need to keep this information? Unless someone argues for it, I'm going to assume No. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From glob at mozilla.com Thu Sep 11 04:01:59 2014 From: glob at mozilla.com (Byron Jones) Date: Thu, 11 Sep 2014 12:01:59 +0800 Subject: Questions for docs, part 2 In-Reply-To: References: Message-ID: <54111EB7.1000001@mozilla.com> Gervase Markham wrote: > * Our install docs currently include a large and rather rambling section > titled "UNIX (non-root) Installation Notes". It tells you how to build > your own Apache and MySQL from scratch and run them on non-standard ports. > > In these days of open source virtualization software, with cheap VMs > available everywhere, does anyone still install Bugzilla on a system > where they don't have root? Do we need to keep this information? Unless > someone argues for it, I'm going to assume No. i agree that this section is no longer relevant and should be removed. -- byron jones - :glob - bugzilla.mozilla.org team - -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen.wiedmann at gmail.com Thu Sep 11 08:42:03 2014 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Thu, 11 Sep 2014 10:42:03 +0200 Subject: Questions for docs, part 2 In-Reply-To: References: Message-ID: I do have the occasional who requests to run Bugzilla in an Apache vhost environments w/o root permissions.I'd beg to keep that stuff. How about a section "Unmaintained" in the docs? On Sep 10, 2014 3:50 PM, "Gervase Markham" wrote: > * Our install docs currently include a large and rather rambling section > titled "UNIX (non-root) Installation Notes". It tells you how to build > your own Apache and MySQL from scratch and run them on non-standard ports. > > In these days of open source virtualization software, with cheap VMs > available everywhere, does anyone still install Bugzilla on a system > where they don't have root? Do we need to keep this information? Unless > someone argues for it, I'm going to assume No. > > 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: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jochen.wiedmann at gmail.com Thu Sep 11 08:50:39 2014 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Thu, 11 Sep 2014 10:50:39 +0200 Subject: "The Worst Bug Tracking Software" In-Reply-To: References: Message-ID: As if we didn' t know? :-) On Sep 9, 2014 2:20 PM, "Gervase Markham" wrote: > Posted to remind you all what a blessing Bugzilla is ;-) > > http://thedailywtf.com/Articles/The-Worst-Bug-Tracking-Software.aspx > > 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: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gerv at mozilla.org Thu Sep 11 08:51:52 2014 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 11 Sep 2014 09:51:52 +0100 Subject: Questions for docs, part 2 In-Reply-To: References: Message-ID: On 11/09/14 09:42, Jochen Wiedmann wrote: > I do have > the occasional > who requests to run Bugzilla in an Apache vhost environments w/o root > permissions. Do you read that section of the docs when you do so? Is it actually useful? Are you interested in maintaining it to an appropriate standard? ;-) > I'd beg to keep that stuff. How about a section "Unmaintained" > in the docs? I'd prefer the information to be transferred to a wiki page - just as I'm transferring in the other direction information people are actually commonly interested in. I don't want any part of our official docs to be unmaintained if at all possible. Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From jochen.wiedmann at gmail.com Thu Sep 11 08:58:07 2014 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Thu, 11 Sep 2014 10:58:07 +0200 Subject: Questions for docs, part 2 In-Reply-To: References: Message-ID: If so, just leave a pointer to the Wiki page, and everything should be fine. On Sep 11, 2014 10:55 AM, "Gervase Markham" wrote: > On 11/09/14 09:42, Jochen Wiedmann wrote: > > I do have > > the occasional > > who requests to run Bugzilla in an Apache vhost environments w/o root > > permissions. > > Do you read that section of the docs when you do so? Is it actually useful? > > Are you interested in maintaining it to an appropriate standard? ;-) > > > I'd beg to keep that stuff. How about a section "Unmaintained" > > in the docs? > > I'd prefer the information to be transferred to a wiki page - just as > I'm transferring in the other direction information people are actually > commonly interested in. I don't want any part of our official docs to be > unmaintained if at all possible. > > 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: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roman at pszonka.org Thu Sep 11 09:14:59 2014 From: roman at pszonka.org (Roman Pszonka) Date: Thu, 11 Sep 2014 10:14:59 +0100 Subject: Questions for docs, part 2 In-Reply-To: References: Message-ID: On Wed, Sep 10, 2014 at 2:47 PM, Gervase Markham wrote: > In these days of open source virtualization software, with cheap VMs > available everywhere, does anyone still install Bugzilla on a system > where they don't have root? Yes. Using it myself this way on a hosting from external company - no root available there. Cheers, -- Roman Pszonka roman at pszonka.org From henrique.rocha at dcc.ufmg.br Mon Sep 15 02:20:56 2014 From: henrique.rocha at dcc.ufmg.br (H. Rocha) Date: Sun, 14 Sep 2014 23:20:56 -0300 Subject: Academic Research: Recommending similar bugs Message-ID: Hello, I am a PhD student at UFMG, Brazil. As part of my research, I am working with a recommender for similar bugs. The idea is to recommend to a developer who has fixed or is working on a bug X that there are similar bugs X1, X2, etc in the tracking system. Currently, I am assuming that two bugs are similar if they are assigned to the same component and share some similarities among their textual descriptions. In fact, we implemented a prototype extension of Bugzilla, with recommendations of similar bugs, called NextBug. We also have some results showing that similar bugs happen in real systems. Finally, we conducted a small survey with Mozilla developers, who also provided an interesting feedback. Therefore, if possible, I would like to discuss with Bugzilla's developers if they seem such recommendations useful and if they have interest on including a similar feature in the system. I appreciate any comments on the matter. Thank you in advance for your collaboration. - Henrique Rocha Computer Science PhD Student Applied Software Engineering Research Group ( http://aserg.labsoft.dcc.ufmg.br/) -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgreen at redhat.com Mon Sep 15 04:56:20 2014 From: sgreen at redhat.com (Simon Green) Date: Mon, 15 Sep 2014 14:56:20 +1000 Subject: Resigning my APL role. Message-ID: <54167174.8060201@redhat.com> Hi all, I've resigned from my day job as a Bugzilla developer at Red Hat. Since my new job doesn't involve Bugzilla, I also am not going to have the time to be an Assistant Project Lead for the upstream project, and therefore regretfully announce my resignation. I'll reassign any bugs that I don't get to finish before I leave back to the default assignee. -- Simon Green Software Engineer Red Hat Asia Pacific Pty Ltd From mhoye at mozilla.com Mon Sep 15 13:00:04 2014 From: mhoye at mozilla.com (Mike Hoye) Date: Mon, 15 Sep 2014 09:00:04 -0400 Subject: Academic Research: Recommending similar bugs In-Reply-To: References: Message-ID: <5416E2D4.7080805@mozilla.com> On 2014-09-14 10:20 PM, H. Rocha wrote: > In fact, we implemented a prototype extension of Bugzilla, with recommendations > of similar bugs, called NextBug. We also have some results showing that > similar bugs happen in real systems. Finally, we conducted a small survey > with Mozilla developers, who also provided an interesting feedback. > > Therefore, if possible, I would like to discuss with Bugzilla's developers > if they seem such recommendations useful and if they have interest on > including a similar feature in the system. Certainly as a community manager I'm interested - the prospect of automating, even partially, a next-good-bug search is pretty compelling from a community-building and contributor-fostering sense. - mhoye _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From ak-47 at gmx.net Mon Sep 15 14:22:49 2014 From: ak-47 at gmx.net (Andre Klapper) Date: Mon, 15 Sep 2014 16:22:49 +0200 Subject: Academic Research: Recommending similar bugs In-Reply-To: References: Message-ID: <1410790969.2055.50.camel@localhost> On Sun, 2014-09-14 at 23:20 -0300, H. Rocha wrote: > The idea is to recommend to a developer who has fixed or is working on a > bug X that there are similar bugs X1, X2, etc in the tracking system. > Currently, I am assuming that two bugs are similar if they are assigned to > the same component and share some similarities among their textual > descriptions. I highly appreciate when academia reaches out to developers. There seems to be a huge gap between research and getting stuff implemented upstream. There's been dozens of research papers (and some prototypes) on duplicate detection in Bugzilla and I assume you're well aware of them. Still I'm very curious: So your basic assumption is that tickets are triaged and end up in the correct component? That sounds very similar to Sun et al.'s "Towards More Accurate Retrieval of Duplicate Bug Reports" at http://www.comp.nus.edu.sg/~specmine/suncn/papers/ase11.pdf Did you consider using additional contextual word lists (like Alipour, Hindle and Stroulia in "A contextual approach towards more accurate duplicate bug report detection")? Did you consider giving tickets created in a similar time span more weight (Prifti, Banerjee and Cukic did that in "Detecting bug duplicate reports through local references")? Did you consider giving higher exposure to reports which have a high number of comments as they likely also receive more duplicates (Cavalcanti et al. tried that in "The bug report duplication problem: an exploratory study")? (All three papers don't have some public access that I'm aware of.) In any case, that's probably all stuff to only consider once some basic code actually HAS landed in upstream code. andre -- Andre Klapper | ak-47 at gmx.net http://blogs.gnome.org/aklapper/ _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Mon Sep 15 15:29:19 2014 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 15 Sep 2014 23:29:19 +0800 Subject: Questions for docs, part 3 Message-ID: * Does anyone still use Patch Viewer? - It only works with CVS. - It requires a Perl module not on CPAN. - BMO doesn't seem to use it any more. - We already have Splinter. - We are moving in the direction of Review Board integration. Can we tear out the docs (and the code)? Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From lpsolit at gmail.com Mon Sep 15 15:41:05 2014 From: lpsolit at gmail.com (=?windows-1252?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 15 Sep 2014 17:41:05 +0200 Subject: Questions for docs, part 3 In-Reply-To: References: Message-ID: <54170891.2080800@gmail.com> Le 15. 09. 14 17:29, Gervase Markham a ?crit : > * Does anyone still use Patch Viewer? I do. That's how I review patches. > - It only works with CVS. Only half true. It works with bzr, git, etc... What only works with CVS is the "# lines for context" feature. > - It requires a Perl module not on CPAN. No idea which module you are talking about. Linux distros have PatchReader available and it's working fine. > - BMO doesn't seem to use it any more. > - We already have Splinter. > - We are moving in the direction of Review Board integration. What do they require as dependencies or configuration? > Can we tear out the docs (and the code)? No reason for now. It currently has no replacement implemented upstream. LpSolit From ak-47 at gmx.net Mon Sep 15 15:42:33 2014 From: ak-47 at gmx.net (Andre Klapper) Date: Mon, 15 Sep 2014 17:42:33 +0200 Subject: Questions for docs, part 3 In-Reply-To: References: Message-ID: <1410795753.2055.54.camel@localhost> On Mon, 2014-09-15 at 23:29 +0800, Gervase Markham wrote: > * Does anyone still use Patch Viewer? Wasn't survey at bugzilla.org meant to be a list to reach out to Bugzilla administrators out there? Sounds like the potential audience to me ("If anyone still uses 'Patch Viewer', please speak up within the next 14 days or it'll be removed"). andre -- Andre Klapper | Wikimedia Bugwrangler http://blogs.gnome.org/aklapper/ _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From lpsolit at gmail.com Mon Sep 15 15:48:19 2014 From: lpsolit at gmail.com (=?windows-1252?Q?Fr=E9d=E9ric_Buclin?=) Date: Mon, 15 Sep 2014 17:48:19 +0200 Subject: Questions for docs, part 3 In-Reply-To: <1410795753.2055.54.camel@localhost> References: <1410795753.2055.54.camel@localhost> Message-ID: <54170A43.60901@gmail.com> Le 15. 09. 14 17:42, Andre Klapper a ?crit : > Wasn't survey at bugzilla.org meant to be a list to reach out to Bugzilla > administrators out there? > Sounds like the potential audience to me Yes, you are right. developers@ is not the right place for such a question. > ("If anyone still uses 'Patch > Viewer', please speak up within the next 14 days or it'll be removed"). 14 days would certainly be too short. There is no hurry to remove this feature. It's not broken, has no security vulnerability, and it's not like this feature prevents you from writing new features. If gerv wants to kill something, I will point him to Old Charts first. LpSolit From dkl at mozilla.com Mon Sep 15 15:56:55 2014 From: dkl at mozilla.com (David Lawrence) Date: Mon, 15 Sep 2014 11:56:55 -0400 Subject: Questions for docs, part 3 In-Reply-To: <54170891.2080800@gmail.com> References: <54170891.2080800@gmail.com> Message-ID: <54170C47.8060906@mozilla.com> On 09/15/2014 11:41 AM, Fr?d?ric Buclin wrote: >> - BMO doesn't seem to use it any more. >> - We already have Splinter. >> - We are moving in the direction of Review Board integration. > > What do they require as dependencies or configuration? Splinter does not have any dependencies on its own (YUI2?) as it is pure javascript but it is an extension and is not part of the upstream Bugzilla code and likely will never be. Reviewboard is the direction *Mozilla* is moving for code review and there is work to integrate it would BMO specifically using extensions and the webservice API. So another solution that will likely not be part of the upstream as it is a fully third party code review tool. >> Can we tear out the docs (and the code)? > > No reason for now. It currently has no replacement implemented upstream. I agree as we. Upstream Bugzilla itself needs to have some sort of native patch viewer built in and PatchReader is the best thing for now. People are still able to install whatever add-ons they want be it Splinter, Reviewboard or something else. dkl -- David Lawrence dkl at mozilla.com From gerv at mozilla.org Tue Sep 16 02:25:28 2014 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 16 Sep 2014 10:25:28 +0800 Subject: Questions for docs, part 3 In-Reply-To: <54170891.2080800@gmail.com> References: <54170891.2080800@gmail.com> Message-ID: <54179F98.2060908@mozilla.org> On 15/09/14 23:41, Fr?d?ric Buclin wrote: >> Can we tear out the docs (and the code)? > > No reason for now. It currently has no replacement implemented upstream. OK, fair enough. Question answered :-) But perhaps we should make it more clear somewhere that you don't need CVS, Bonsai and LXR for it to be useful. Gerv From gerv at mozilla.org Tue Sep 16 02:36:38 2014 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 16 Sep 2014 10:36:38 +0800 Subject: Academic Research: Recommending similar bugs In-Reply-To: References: Message-ID: <5417A236.90205@mozilla.org> Hi Henrique, On 15/09/14 10:20, H. Rocha wrote: > In fact, we implemented a prototype extension of Bugzilla, > with recommendations of similar bugs, called NextBug. We also have some > results showing that similar bugs happen in real systems. Finally, we > conducted a small survey with Mozilla developers, who also provided an > interesting feedback. Is the code for this extension available anywhere? > Therefore, if possible, I would like to discuss with > Bugzilla's developers if they seem such recommendations useful and if > they have interest on including a similar feature in the system. I think it would be good for us to see and evaluate your prototype. Gerv From gerv at mozilla.org Tue Sep 16 02:40:34 2014 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 16 Sep 2014 10:40:34 +0800 Subject: Resigning my APL role. In-Reply-To: <54167174.8060201@redhat.com> References: <54167174.8060201@redhat.com> Message-ID: <5417A322.1070607@mozilla.org> On 15/09/14 12:56, Simon Green wrote: > I've resigned from my day job as a Bugzilla developer at Red Hat. Are you leaving Red Hat, or just that job? Do you know if Red Hat plan to get someone else to work on Bugzilla? > Since > my new job doesn't involve Bugzilla, I also am not going to have the > time to be an Assistant Project Lead for the upstream project, and > therefore regretfully announce my resignation. That's a shame; we are sorry to see you go. Thank you so much for your contributions and hard work :-) Gerv From sgreen at redhat.com Tue Sep 16 02:47:50 2014 From: sgreen at redhat.com (Simon Green) Date: Tue, 16 Sep 2014 12:47:50 +1000 Subject: Resigning my APL role. In-Reply-To: <5417A322.1070607@mozilla.org> References: <54167174.8060201@redhat.com> <5417A322.1070607@mozilla.org> Message-ID: <5417A4D6.6060201@redhat.com> On 16/09/14 12:40, Gervase Markham wrote: > Are you leaving Red Hat, or just that job? I'm leaving Red Hat. > Do you know if Red Hat plan to get someone else to work on Bugzilla? I'm not sure at this stage. > That's a shame; we are sorry to see you go. Thank you so much for your > contributions and hard work :-) Thanks. I've really enjoyed working on Bugzilla the past four years. -- Simon Green Software Engineer Red Hat Asia Pacific Pty Ltd From henrique.rocha at dcc.ufmg.br Tue Sep 16 18:17:10 2014 From: henrique.rocha at dcc.ufmg.br (H. Rocha) Date: Tue, 16 Sep 2014 15:17:10 -0300 Subject: Academic Research: Recommending similar bugs In-Reply-To: <5417A236.90205@mozilla.org> References: <5417A236.90205@mozilla.org> Message-ID: Hello all, Thank you very much for the feedback. I welcome any comment on this subject. On Sep 15, 2014 at 10:00 AM, Mike Hoye wrote: > Certainly as a community manager I'm interested - > the prospect of automating, even partially, a > next-good-bug search is pretty compelling from a > community-building and contributor-fostering sense. I hope NextBug could help with that. The experiments show reasonable results so far. On Sep 15, 2014 at 11:22 AM, Andre Klapper wrote: > I highly appreciate when academia reaches out to developers. > There seems to be a huge gap between research and getting stuff > implemented upstream. My research group also shares these believes. We are always trying to apply our research to help developers. On Sep 15, 2014 at 11:22 AM, Andre Klapper wrote: > There's been dozens of research papers (and some prototypes) on > duplicate detection in Bugzilla and I assume you're well aware of them. I am aware of the papers you mentioned and I am considering theses works to improve our current prototype. Basically, our current prototype is indeed more similar to Sun et al. (2011) On Sep 15, 2014 at 11:36 PM, Gervase Markham wrote: > Is the code for this extension available anywhere? > I think it would be good for us to see and evaluate your prototype. Yes, we have a prototype tool already running. Please look at: < http://aserg.labsoft.dcc.ufmg.br/nextbug/ > Of course, we are working hardly now to improve this first prototype. In fact, by next week we plan to have a new version where the developers can customize filters to select recommendations on just specific types of bugs (e.g, bugs of a certain severity, bugs not assigned to anyone, etc). Thanks again for all the comments. - Henrique Rocha Computer Science PhD Student Applied Software Engineering Research Group ( http://aserg.labsoft.dcc.ufmg.br/) -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpsolit at gmail.com Tue Sep 16 18:18:44 2014 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Tue, 16 Sep 2014 20:18:44 +0200 Subject: Questions for docs, part 3 In-Reply-To: <54179F98.2060908@mozilla.org> References: <54170891.2080800@gmail.com> <54179F98.2060908@mozilla.org> Message-ID: <54187F04.3060200@gmail.com> Le 16. 09. 14 04:25, Gervase Markham a ?crit : > OK, fair enough. Question answered :-) But perhaps we should make it > more clear somewhere that you don't need CVS, Bonsai and LXR for it to > be useful. Or simply remove CVS-specific code (I really mean code here, not doc only). That's something I wouldn't be opposed to, and would let us kill the "Patch Viewer" panel in the Parameters page completely. CVS is probably not so common nowadays, and I'm not sure anyone is still using Bonsai or LXR these days. LpSolit From gerv at mozilla.org Wed Sep 17 06:29:26 2014 From: gerv at mozilla.org (Gervase Markham) Date: Wed, 17 Sep 2014 14:29:26 +0800 Subject: Questions for docs, part 3 In-Reply-To: References: <54170891.2080800@gmail.com> <54179F98.2060908@mozilla.org> Message-ID: On 17/09/14 02:18, Fr?d?ric Buclin wrote: > Or simply remove CVS-specific code (I really mean code here, not doc > only). That's something I wouldn't be opposed to, and would let us kill > the "Patch Viewer" panel in the Parameters page completely. CVS is > probably not so common nowadays, and I'm not sure anyone is still using > Bonsai or LXR these days. That's a good idea. Bug filed: https://bugzilla.mozilla.org/show_bug.cgi?id=1068494 Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Tue Sep 23 09:58:56 2014 From: gerv at mozilla.org (Gervase Markham) Date: Tue, 23 Sep 2014 10:58:56 +0100 Subject: Academic Research: Recommending similar bugs In-Reply-To: References: <5417A236.90205@mozilla.org> Message-ID: Hi Henrique, On 16/09/14 19:17, H. Rocha wrote: > Yes, we have a prototype tool already running. Please look at: < > http://aserg.labsoft.dcc.ufmg.br/nextbug/ > > > Of course, we are working hardly now to improve this first prototype. In > fact, by next week we plan to have a new version where the developers can > customize filters to select recommendations on just specific types of bugs > (e.g, bugs of a certain severity, bugs not assigned to anyone, etc). A few ideas and suggestions: * You should make your tool a proper Bugzilla Extension: http://www.bugzilla.org/docs/tip/en/html/api/Bugzilla/Extension.html There is a template hook called "after_custom_fields" which would be perfect for you to add your new UI to the bug edit screen. This would mean your extension would work with more than one version of Bugzilla. * You should use Template Toolkit and the template system to produce any HTML you need, rather than using print() statements as now. * Instead of loading the data via jquery, you could use code hooks to prepare it when a page was being viewed, and then just access it directly through template variables in the edit.html.tmpl template. The general idea of your tool looks great, though :-) Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla From gerv at mozilla.org Mon Sep 29 15:26:18 2014 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 29 Sep 2014 16:26:18 +0100 Subject: Reviewing the New Docs Message-ID: The rewritten Bugzilla docs are finally ready! They are loads better than the old ones, but we need to get them reviewed so they can be checked in and people can start using them. If you are a Bugzilla admin, administrator or user, the Bugzilla team could really use your help reviewing them. The more, the merrier. This is an opportunity for everyone who has been blessed by using Bugzilla to give a little back. Head over here: https://etherpad.mozilla.org/bugzilla-docs-review and follow the instructions to claim a chapter or section to review. A chapter can (and should be) reviewed multiple times. Particular bonus points and hugs for people who can review, and test, the install guides for Windows and Mac. Thanks for your help! Gerv _______________________________________________ dev-apps-bugzilla mailing list dev-apps-bugzilla at lists.mozilla.org https://lists.mozilla.org/listinfo/dev-apps-bugzilla