From denis.roy at eclipse.org Wed Nov 18 20:16:00 2015 From: denis.roy at eclipse.org (Denis Roy) Date: Wed, 18 Nov 2015 15:16:00 -0500 Subject: Backwards development Message-ID: <564CDC80.7020107@eclipse.org> I find it odd that BMO is using something that looks like Bugzilla, but isn't. EditComments, the Dashboard, and even the UI are different (read: better) than what is available to the rest of us. These extensions are available to us, somewhere, in some repo, if we can find it. Why does Mozilla do this backwards? Wouldn't you want to improve the core project and have BMO (and everyone else) consume that? When a group of developers are off in one corner working on a new UI, it makes it impossible for the rest of us to follow along. Furthermore, our contributions go ignored because we're not aware of the work that's happening behind the scenes: https://bugzilla.mozilla.org/show_bug.cgi?id=101865#c51 Short story -- does the Bugzilla project want contributions, or is it relegated to being a code dump for Mozilla's bug tracker? D. From mcote at mozilla.com Wed Nov 18 21:51:06 2015 From: mcote at mozilla.com (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Wed, 18 Nov 2015 16:51:06 -0500 Subject: Backwards development In-Reply-To: References: Message-ID: Hi Denis. I think there's something that needs to be clarified. BMO is Mozilla's version of Bugzilla. It happens to be the home of upstream Bugzilla bugs, for historical reasons, but it is administered separately. BMO is owned by the Mozilla Corporation's Engineering Productivity team and primarily serves to support Mozilla's engineering efforts, mainly Firefox and family, but it also hosts bugs for other Mozilla projects and a few projects not directly administered by Mozilla. It has its own code base, https://git.mozilla.org/webtools/bmo/bugzilla.git. Upstream Bugzilla, that is, the general, packaged, versioned product, is governed separately. It has a project lead, assistant project leads, and official reviewers and approvers. Mozilla acts as a steward of the Bugzilla project, providing resources like machines and a bit of labour, but not controlling its direction. Historically, since shortly after Mozilla first released Bugzilla, the Bugzilla development community has not involved very many people from the Mozilla community, and almost no Mozilla employees. Lately, this has shifted a bit, as the upstream community has dwindled. We (Mozilla employees) got involved a bit more to attempt to revive the community, though this hasn't been very successful. At this point, there are almost no official reviewers nor approvers left; those that are there happen to be Mozilla employees, but that is largely happenstance, and it was not intended to be permanent. Mark On 2015-11-18 3:16 PM, Denis Roy wrote: > I find it odd that BMO is using something that looks like Bugzilla, but > isn't. > > EditComments, the Dashboard, and even the UI are different (read: > better) than what is available to the rest of us. These extensions are > available to us, somewhere, in some repo, if we can find it. > > Why does Mozilla do this backwards? Wouldn't you want to improve the > core project and have BMO (and everyone else) consume that? > > When a group of developers are off in one corner working on a new UI, it > makes it impossible for the rest of us to follow along. Furthermore, our > contributions go ignored because we're not aware of the work that's > happening behind the scenes: > https://bugzilla.mozilla.org/show_bug.cgi?id=101865#c51 > > Short story -- does the Bugzilla project want contributions, or is it > relegated to being a code dump for Mozilla's bug tracker? > > > D. > - > To view or change your list settings, click here: > > _______________________________________________ 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 Wed Nov 18 23:12:41 2015 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Thu, 19 Nov 2015 00:12:41 +0100 Subject: Backwards development In-Reply-To: <564CDC80.7020107@eclipse.org> References: <564CDC80.7020107@eclipse.org> Message-ID: <564D05E9.7000304@gmail.com> Le 18. 11. 15 21:16, Denis Roy a ?crit : > Why does Mozilla do this backwards? Wouldn't you want to improve the > core project and have BMO (and everyone else) consume that? As I understand it, several BMO extensions are very Mozilla-specific, are based on some specific policies or have some hardcoded strings here and there. This means that what matches Mozilla specific needs is not necessarily what other Bugzilla maintainers would want for their installation, which means extra work to implement new parameters or new user preferences when they make sense. Also, hardcoded strings mean than localizers couldn't translate them easily or at all, requiring extra work to fix that. I guess some extensions also only work on Linux but not on Windows, which upstream Bugzilla must also support. And finally, BMO is currently based on Bugzilla 4.2 while current upstream version is 5.1 and so extra work would be required to port them from 4.2 to 5.1. My understanding is that BMO maintainers do not want to waste their time with these requirements and they prefer to customize their own installation to spare several review cycles or endless discussions. > Short story -- does the Bugzilla project want contributions, or is it > relegated to being a code dump for Mozilla's bug tracker? The Bugzilla project definitely wants contributions. One of the reasons which causes review or implementation delays is that some of the contributions are based on some older Bugzilla version, e.g. 4.2 or 4.4, while the current master code is 5.1, and so the patch doesn't apply cleanly. In some cases, it's trivial to fix conflicts and the reviewer will very likely do it himself on checkin. In some other cases, the code is different enough between 4.2 and 5.1 that the reviewer is not willing to do the job himself, due to a lack of time or energy (some contributions are not critical enough to waste hours fixing conflicts). If the contributor has no interest in porting his patch to 5.1, then the patch stays there for several months or years, till someone decides to port it or rewrite it from scratch... or till the bug is finally closed as worksforme or wontfix for some reason. Another reason for the delays is that some contributors say that their patches work, and do not see why they should waste their time fixing them to meet our requirements. One example is a patch which duplicates some existing code and is rejected because it would be better to refactor the existing code to be able to reuse it in the patch, and the contributor refuses to do this, probably due to a lack of time or interest. When I started contributing 11 years ago, an informal policy was that contributors had to fix their patches themselves, because it's their contributions and it's a way to "become better to code" (or at least to follow the guidelines). When I became an official reviewer 10 years ago, I remember I once fixed the last few bits myself to avoid the contributor to waste extra cycles, but I made him upset because the final code was a bit different from his original contribution and he had the feeling that I stole or heavily changed his contribution. I didn't steal his contribution because he was listed as the original contributor in the CVS commit message. But I admit I had to heavily refactor his patch to make it pass our requirements. So my intention was to make everybody to not waste their time (reviewing a huge patch also takes a lot of time, and it's sometimes faster to fix it ourselves!). Since that day, I stopped to do this. Now I let contributors waste cycles as it seems some of them do not like to see someone else alter their patches, even if the goal is to make development go faster. Oh, and one drawback for a reviewer to heavily alter a patch himself is that he needs to find another reviewer to review the new patch, and we all know how hard it is to find another reviewer who is willing to do reviews these days. If the upstream Bugzilla team is really that small, then maybe the requirement for them to ask for review should go away, so that they are free to commit whatever code they want. But this would require an hyperactive project leader to keep an eye on this. In fact, we did this in the past already, when mkanat and I were both allowed to commit patches without asking anyone for reviews, because we had a very good understanding of the backend code and of the direction the project wanted to go. We were terribly fast to implement new features and heavy changes could be committed pretty quickly without having to wait for months to get reviews. LpSolit From gerv at mozilla.org Thu Nov 19 10:08:07 2015 From: gerv at mozilla.org (Gervase Markham) Date: Thu, 19 Nov 2015 10:08:07 +0000 Subject: Backwards development In-Reply-To: <564CDC80.7020107@eclipse.org> References: <564CDC80.7020107@eclipse.org> Message-ID: <564D9F87.3020806@mozilla.org> Hi Denis, On 18/11/15 20:16, Denis Roy wrote: > Why does Mozilla do this backwards? Wouldn't you want to improve the > core project and have BMO (and everyone else) consume that? In the last couple of years, we have been struggling with the impedance mismatch of BMO's rapid release cycle (they ship weekly) and regular requirements for improvements from Mozilla's management, with the differing pace of development of upstream. For better or worse, the BMO team have decided that working upstream, doing releases and then shipping them on bugzilla.mozilla.org is not a model which works given their constraints. They do plan to merge the trunk into their codebase again soon, and I hope that the upstream developers (as many as there are) will be able to work together to take that opportunity to port upstream many of the generally-applicable improvements that have been made on BMO. > Short story -- does the Bugzilla project want contributions, or is it > relegated to being a code dump for Mozilla's bug tracker? The Bugzilla project is extremely keen to see contributions, particularly from outside Mozilla. In fact, Bugzilla's future as an independent software project depends on it. Gerv From laurent.facq at math.u-bordeaux1.fr Fri Nov 20 14:01:53 2015 From: laurent.facq at math.u-bordeaux1.fr (Laurent Facq) Date: Fri, 20 Nov 2015 15:01:53 +0100 Subject: patch proposition to add some functionnality to the Bugzilla 5.0.1 REST API Message-ID: <564F27D1.5000906@math.u-bordeaux1.fr> Hi ! i'm new to bugzilla dev. i'm trying to hack bugzilla REST API to implement some features i need like removing group or product, modifying rights groups have on a product. i know my code is a bit quick & dirty... but may be anyway it can be a step further :) here's my patch against bugzilla 5.0.1 and an example in Ruby of how i begin to use it. L. -- Laurent FACQ - +(33)5 4000 6956 Institut de Math?matiques de Bordeaux - Mathrice GDS 2754 -------------- next part -------------- diff --git a/Bugzilla/Group.pm b/Bugzilla/Group.pm index 07b78e3..c7e2ebd 100644 --- a/Bugzilla/Group.pm +++ b/Bugzilla/Group.pm @@ -193,6 +193,8 @@ sub set_name { $_[0]->set('name', $_[1]); } sub set_user_regexp { $_[0]->set('userregexp', $_[1]); } sub set_icon_url { $_[0]->set('icon_url', $_[1]); } +sub set_action_remove { $_[0]->remove_from_db(); } + sub update { my $self = shift; my $dbh = Bugzilla->dbh; @@ -204,10 +206,13 @@ sub update { my $update_params; foreach my $group (GROUP_PARAMS) { if ($old_name eq Bugzilla->params->{$group}) { + if (Bugzilla->params->{$group}) ## not sure if this test is ok, but should check for empty values ? right ? + { SetParam($group, $new_name); $update_params = 1; } } + } write_params() if $update_params; } diff --git a/Bugzilla/Product.pm b/Bugzilla/Product.pm index 30ebc7c..a3da6b9 100644 --- a/Bugzilla/Product.pm +++ b/Bugzilla/Product.pm @@ -485,9 +485,39 @@ sub set_default_milestone { $_[0]->set('defaultmilestone', $_[1]); } sub set_is_active { $_[0]->set('isactive', $_[1]); } sub set_allows_unconfirmed { $_[0]->set('allows_unconfirmed', $_[1]); } +sub set_remove { $_[0]->remove_from_db(); } + +## +## here we hav the choice : an new method "set_group_controls_update" or a fix of the arguments of the existnig "set_group_controls" method +## + +sub set_group_controls_update { + my ($self, $group, $settings) = @_; + + if (ref($group) eq 'ARRAY') + { + # this is a WebService Request, need to fix the arguments (extract $group and $settings from the first $group argument) + $settings= $group->[1]; + $group= Bugzilla::Group->new({name => $group->[0]}); + + return $self->set_group_controls($group,$settings); + } + else + { + ThrowUserError('product_illegal_group', "set_group_controls_update called with bad arguments"); ### FIXLE bad error type - just to do an error... + } +} + sub set_group_controls { my ($self, $group, $settings) = @_; + if (ref($group) eq 'ARRAY') + { + # this is a WebService Request, need to fix the arguments (extract $group and $settings from the first $group argument) + $settings= $group->[1]; + $group= Bugzilla::Group->new({name => $group->[0]}); + } + $group->is_active_bug_group || ThrowUserError('product_illegal_group', {group => $group}); -------------- next part -------------- #! /usr/bin/ruby require 'rest-client' @bz_api_key = 'YOU_API_KEY' @bz_root_url= 'https://bugzilla.YOUR.DOMAIN/rest.cgi' def bugzirq (verb='get', method='version', params={ }) begin # res= RestClient.get "#{@bz_root_url}#{method}", :accept => :json, :content_type => :json , :params => { 'api_key' => @api_key }.merge!(params) if (verb=='get') res= RestClient.get "#{@bz_root_url}/#{method}", :accept => :json, :content_type => :json , :params => { 'api_key' => @bz_api_key }.merge!(params) elsif (verb=='post') # res= RestClient.post "https://tracker.math.cnrs.fr/rest.cgi/#{method}", :accept => :json, :content_type => :json , :params => { 'api_key' => @bz_api_key }.merge!(params) res= RestClient.post "#{@bz_root_url}/#{method}", { :accept => :json, :content_type => :json , 'api_key' => @bz_api_key }.merge!(params) elsif (verb=='put') # res= RestClient.post "https://tracker.math.cnrs.fr/rest.cgi/#{method}", :accept => :json, :content_type => :json , :params => { 'api_key' => @bz_api_key }.merge!(params) #res= RestClient.put "https://tracker.math.cnrs.fr/rest.cgi/#{method}", { :accept => :json, :content_type => :json , 'api_key' => @bz_api_key }.merge!(params) res= RestClient.put "#{@bz_root_url}/#{method}", { 'api_key' => @bz_api_key }.merge!(params).to_json, :content_type => :json, :accept => :json elsif (verb=='delete') # res= RestClient.post "https://tracker.math.cnrs.fr/rest.cgi/#{method}", :accept => :json, :content_type => :json , :params => { 'api_key' => @bz_api_key }.merge!(params) res= RestClient.delete "#{@bz_root_url}/#{method}", { :accept => :json, :content_type => :json , 'api_key' => @bz_api_key }.merge!(params) end rescue RestClient::ResourceNotFound => e puts e.response+"resource not found\n" rescue => e puts e.response+"error\n" end res.to_s end #%w( user parameters version product_selectable product_enterable product_accessible ).each{ |m| # puts bugzirq('get',m,{:match => 'depo'}).to_s #} puts "== Product CREATE\n" puts bugzirq('post','product', { :name => 'bz_api_test', :description => 'the marvelous bz_api', :version => '0.1' }).to_s puts "== Group CREATE\n" puts bugzirq('post','group', { :name => 'bz_api_test', :description => 'the marvelous bz_api', 'is_active' => 'true' }).to_s # update product (/rest/product/NAME) # { add => [$group_name] } puts "== Product UPDATE - add group rights on product\n" puts bugzirq('put','product/bz_api_test', #puts bugzirq('put','product', { :name => 'bz_api_test', :names => [ 'bz_api_test' ], :description => 'new desc ', :group_controls => [ 'bz_api_test', { 'editcomponents' => 1, 'canedit' => 0, } ] }).to_s puts "== Product UPDATE (alternate) - add group rights on product\n" puts bugzirq('put','product/bz_api_test', { :description => 'new desc', :group_controls_update => [ 'bz_api_test', { 'editcomponents' => 1, 'canedit' => 0, } ] }).to_s puts "== Groups UPDATE - add dumbo\n" puts bugzirq('put','user/dumbo at bugzilla.plm', { :groups => { 'add' => ['bz_api_test' ] } }).to_s puts "== Product UPDATE (alternate) - add group rights on product\n" puts bugzirq('put','product/bz_api_test', { :description => 'new desc', :group_controls_update => [ 'bz_api_test', { 'editcomponents' => 1, 'canedit' => 0, } ] }).to_s puts "== Products UPDATE - remove product\n" puts bugzirq('put','product/bz_api_test', { :remove => 1 }).to_s puts "== Groups UPDATE - remove dumbo\n" puts bugzirq('put','user/dumbo at bugzilla.plm', { :groups => { 'remove' => ['bz_api_test' ] } }).to_s puts "== Group GET - get info\n" puts bugzirq('get','group', {:match => 'aaaabz_api_test'} ).to_s puts "== Group UPDATE - remove group\n" #puts bugzirq('put','group/bz_api_test', puts bugzirq('put','group/bz_api_test', { :description => 'bz_api_test new desc', :remove => 'bz_api_test' # }) end #puts bugzirq('delete','component', # { :name => 'bz_api_test', # :description => 'the marvelous bz_api', # :version => '0.1' # }).to_s puts "== Group CREATE\n" puts bugzirq('post','group', { :name => 'zztoshiba', :description => 'the toshiba grp', 'is_active' => 'true' }).to_s puts "== Group DELETE - remove group\n" #puts bugzirq('put','group/bz_api_test', puts bugzirq('put','group/zztoshiba', { :action_remove => 1 }) From denis.roy at eclipse.org Fri Nov 20 15:48:00 2015 From: denis.roy at eclipse.org (Denis Roy) Date: Fri, 20 Nov 2015 10:48:00 -0500 Subject: Backwards development In-Reply-To: <564D9F87.3020806@mozilla.org> References: <564CDC80.7020107@eclipse.org> <564D9F87.3020806@mozilla.org> Message-ID: <564F40B0.1020806@eclipse.org> On 11/19/2015 05:08 AM, Gervase Markham wrote: > For better or worse, the BMO > team have decided that working upstream, doing releases and then > shipping them on bugzilla.mozilla.org is not a model which works given > their constraints. > > The Bugzilla project is extremely keen to see contributions, > particularly from outside Mozilla. In fact, Bugzilla's future as an > independent software project depends on it. In Open Source, I don't see how these two models can coexist. In fact, I see this methodology as the biggest possible barrier to external contributions, and no tool (Git, Github) can fix that. Don't get me wrong, I'm a happy BZ user & admin for many years, but the biggest gripe my userbase has about BZ is the 1990's UI. At Eclipse we're willing to roll up our sleeves and help fix it, but we can't do that when the BZ devs are cheering on the BMO team from the sidelines. Denis From gerv at mozilla.org Fri Nov 20 16:10:31 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 20 Nov 2015 16:10:31 +0000 Subject: Backwards development In-Reply-To: <564F40B0.1020806@eclipse.org> References: <564CDC80.7020107@eclipse.org> <564D9F87.3020806@mozilla.org> <564F40B0.1020806@eclipse.org> Message-ID: <564F45F7.5080002@mozilla.org> Hi Denis, On 20/11/15 15:48, Denis Roy wrote: > In Open Source, I don't see how these two models can coexist. In fact, I > see this methodology as the biggest possible barrier to external > contributions, and no tool (Git, Github) can fix that. > > Don't get me wrong, I'm a happy BZ user & admin for many years, but the > biggest gripe my userbase has about BZ is the 1990's UI. At Eclipse > we're willing to roll up our sleeves and help fix it, but we can't do > that when the BZ devs are cheering on the BMO team from the sidelines. I think there has perhaps been some misunderstanding here. The BMO team has made its own decision about how to run BMO; those in the Bugzilla community who are not BMO devs may or may not agree with it, but we have no say in it. So it seems odd to characterise us as "cheering from the sidelines", as if we both endorse what they are doing and are equally happy to do nothing while they do it. Both impressions are partially or wholly wrong. The Bugzilla community would love you at Eclipse to get involved and help update the UI. One thing you could seriously consider would be porting the updated API-using show_bug view deployed on BMO to trunk Bugzilla, if you agree that this sort of thing is the future. The BMO team have said they don't have time to do that port, but the upstream Bugzilla team very much want the feature. Gerv From denis.roy at eclipse.org Fri Nov 20 16:15:13 2015 From: denis.roy at eclipse.org (Denis Roy) Date: Fri, 20 Nov 2015 11:15:13 -0500 Subject: Backwards development In-Reply-To: References: Message-ID: <564F4711.4030206@eclipse.org> On 11/18/2015 04:51 PM, Mark C?t? wrote: > At this point, there are > almost no official reviewers nor approvers left; those that are there > happen to be Mozilla employees, but that is largely happenstance, and it > was not intended to be permanent. We've been through this at Eclipse, where many projects had dwindling communities and near-zero external contributions, but we've been able to help turn that around using modern contribution models (GitHub, Git, Gerrit), modern methodologies and careful coaching of projects. Just look at the charts for our core platform, once dominated by IBM: https://projects.eclipse.org/projects/eclipse.platform.ui/who Perhaps if Bugzilla is serious about being an independent software project, it should consider moving to an independent software foundation. As it stands, Mozilla is not living up to its manifesto wrt. Bugzilla, specifically: 08 Transparent community-based processes promote participation, accountability and trust. https://www.mozilla.org/en-US/about/manifesto/ Respectfully, Denis From dale at arandomurl.com Fri Nov 20 16:24:48 2015 From: dale at arandomurl.com (Dale Harvey) Date: Fri, 20 Nov 2015 16:24:48 +0000 Subject: Backwards development In-Reply-To: <564F45F7.5080002@mozilla.org> References: <564CDC80.7020107@eclipse.org> <564D9F87.3020806@mozilla.org> <564F40B0.1020806@eclipse.org> <564F45F7.5080002@mozilla.org> Message-ID: I am not part of bugzilla / bmo projects, but I dont see how anyone is being prevented from working on an updated UI for bugzilla. I am currently working on https://www.bzlite.com ( https://github.com/mozilla-b2g/bzlite/) and would very much welcome anyone who wanted to contribute. Similiarly there is https://www.bzdeck.com which is also open source. On 20 November 2015 at 16:10, Gervase Markham wrote: > Hi Denis, > > On 20/11/15 15:48, Denis Roy wrote: > > In Open Source, I don't see how these two models can coexist. In fact, I > > see this methodology as the biggest possible barrier to external > > contributions, and no tool (Git, Github) can fix that. > > > > Don't get me wrong, I'm a happy BZ user & admin for many years, but the > > biggest gripe my userbase has about BZ is the 1990's UI. At Eclipse > > we're willing to roll up our sleeves and help fix it, but we can't do > > that when the BZ devs are cheering on the BMO team from the sidelines. > > I think there has perhaps been some misunderstanding here. The BMO team > has made its own decision about how to run BMO; those in the Bugzilla > community who are not BMO devs may or may not agree with it, but we have > no say in it. So it seems odd to characterise us as "cheering from the > sidelines", as if we both endorse what they are doing and are equally > happy to do nothing while they do it. Both impressions are partially or > wholly wrong. > > The Bugzilla community would love you at Eclipse to get involved and > help update the UI. One thing you could seriously consider would be > porting the updated API-using show_bug view deployed on BMO to trunk > Bugzilla, if you agree that this sort of thing is the future. The BMO > team have said they don't have time to do that port, but the upstream > Bugzilla team very much want the feature. > > Gerv > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From justdave at bugzilla.org Fri Nov 20 16:32:46 2015 From: justdave at bugzilla.org (Dave Miller) Date: Fri, 20 Nov 2015 11:32:46 -0500 Subject: Backwards development In-Reply-To: <564F40B0.1020806@eclipse.org> References: <564CDC80.7020107@eclipse.org> <564D9F87.3020806@mozilla.org> <564F40B0.1020806@eclipse.org> Message-ID: <564F4B2E.2060406@bugzilla.org> Denis Roy wrote: > On 11/19/2015 05:08 AM, Gervase Markham wrote: > Don't get me wrong, I'm a happy BZ user & admin for many years, but the > biggest gripe my userbase has about BZ is the 1990's UI. At Eclipse > we're willing to roll up our sleeves and help fix it, but we can't do > that when the BZ devs are cheering on the BMO team from the sidelines. Part of the problem is there are currently about two active bugzilla devs that aren't also part of the BMO team right now, and both of those two are doing Bugzilla on their own time and not as part of their day jobs (which mostly don't involve Bugzilla at all these days). These people have been begging the BMO folks to keep porting their stuff. But that's all they can do. It's kind of ironic... Bugzilla used to do pretty well independently, but was always complaining to Mozilla because they were the primary user of the product and didn't contribute any developers. Three or four years ago that changed when they finally hired a few developers to actually work on Bugzilla (specifically for BMO, but initially they were pretty religious about porting everything that was appropriate). It feels to me like after Mozilla finally got developers, everyone else was suddenly "oh, Mozilla has developers for it now, we don't need to help them anymore" and everyone from outside Mozilla that had been active disappeared. And this happened as a result. -- 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 theycallmefish at gmail.com Fri Nov 20 16:50:03 2015 From: theycallmefish at gmail.com (Ryan Wilson) Date: Fri, 20 Nov 2015 09:50:03 -0700 Subject: Backwards development In-Reply-To: <564F4B2E.2060406@bugzilla.org> References: <564CDC80.7020107@eclipse.org> <564D9F87.3020806@mozilla.org> <564F40B0.1020806@eclipse.org> <564F4B2E.2060406@bugzilla.org> Message-ID: Bugzilla is still very much a part of my day job, and I would be happy to take a much more active part in its development. Currently, the company has me pulled into more of a support role for the software (which, if successful, could lead to a userbase on my installation of nearly triple what it is now), so time for active development is very low for the time being. Downtime is currently allocated to the Testopia extension to ensure it can move forward with Bugzilla. On Fri, Nov 20, 2015 at 9:32 AM, Dave Miller wrote: > Denis Roy wrote: > > On 11/19/2015 05:08 AM, Gervase Markham wrote: > > Don't get me wrong, I'm a happy BZ user & admin for many years, but the > > biggest gripe my userbase has about BZ is the 1990's UI. At Eclipse > > we're willing to roll up our sleeves and help fix it, but we can't do > > that when the BZ devs are cheering on the BMO team from the sidelines. > > Part of the problem is there are currently about two active bugzilla > devs that aren't also part of the BMO team right now, and both of those > two are doing Bugzilla on their own time and not as part of their day > jobs (which mostly don't involve Bugzilla at all these days). These > people have been begging the BMO folks to keep porting their stuff. But > that's all they can do. > > It's kind of ironic... Bugzilla used to do pretty well independently, > but was always complaining to Mozilla because they were the primary user > of the product and didn't contribute any developers. Three or four > years ago that changed when they finally hired a few developers to > actually work on Bugzilla (specifically for BMO, but initially they were > pretty religious about porting everything that was appropriate). It > feels to me like after Mozilla finally got developers, everyone else was > suddenly "oh, Mozilla has developers for it now, we don't need to help > them anymore" and everyone from outside Mozilla that had been active > disappeared. And this happened as a result. > > -- > Dave Miller http://www.justdave.net/ > IT Infrastructure Engineer, Mozilla http://www.mozilla.org/ > Project Leader, Bugzilla Bug Tracking System http://www.bugzilla.org/ > > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcote at mozilla.com Fri Nov 20 17:57:39 2015 From: mcote at mozilla.com (=?UTF-8?B?TWFyayBDw7R0w6k=?=) Date: Fri, 20 Nov 2015 12:57:39 -0500 Subject: Backwards development In-Reply-To: References: Message-ID: On 2015-11-20 11:15 AM, Denis Roy wrote: > Perhaps if Bugzilla is serious about being an independent software > project, it should consider moving to an independent software > foundation. As it stands, Mozilla is not living up to its manifesto wrt. > Bugzilla, specifically: > > 08 Transparent community-based processes promote participation, > accountability and trust. > > https://www.mozilla.org/en-US/about/manifesto/ Again, the Bugzilla project is not administered by Mozilla. Mozilla supports it by providing some resources. Coincidentally there are some Mozilla employees active in the Bugzilla community, but the two are functionally separate. Creating a software foundation for the Bugzilla project is a great idea, particularly if it would involve funding to employ a product manager and, ideally, some developers. It would also be a large amount of work, and I don't know anyone at the moment who would want to lead that. As for Mozilla's manifesto, I don't think Bugzilla fits into Mozilla's mission at all, which is reflected by it being a separately governed project. Maybe it did early on, when the web was young and every open-source web application Mozilla created helped drive the web forward. In my opinion, that is no longer the case--there are a vast number of open-source web applications, and so the web apps that Mozilla continues to create and maintain mainly act in a supporting role for Mozilla's mission. This includes BMO specifically, which is an important tool for projects that are directly related to our mission (Firefox, Webmaker, etc.). I became an Assistant Project Lead for the Bugzilla project, independent of my role as a manager on Mozilla's Engineering Productivity team, because I wanted to revive the community, hoping we could develop a more productive relationship between Bugzilla and BMO. I was pretty naive about the scope of that work. There is indeed plenty more the Bugzilla community could do to revive the project, but at some point I had to admit that the amount of effort and time I would have to put in would not have a commensurate impact for Mozilla. It is a frustrating and disappointing situation. Mark _______________________________________________ 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 Fri Nov 20 18:11:33 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 20 Nov 2015 18:11:33 +0000 Subject: Backwards development In-Reply-To: <564F4711.4030206@eclipse.org> References: <564F4711.4030206@eclipse.org> Message-ID: <564F6255.7000608@mozilla.org> Hi Denis, On 20/11/15 16:15, Denis Roy wrote: > We've been through this at Eclipse, where many projects had dwindling > communities and near-zero external contributions, but we've been able to > help turn that around using modern contribution models (GitHub, Git, > Gerrit), modern methodologies and careful coaching of projects. It would be wonderful if someone had the cycles to do this for Bugzilla. I'd like to, but I just don't have the hours. We already use Git, and mirror to Github. > Perhaps if Bugzilla is serious about being an independent software > project, it should consider moving to an independent software > foundation. I don't see how being part of Mozilla is actively holding Bugzilla back. Moving to an independent foundation is not going to cause the BMO team to suddenly have lots of time to port things upstream. Am I missing something? > As it stands, Mozilla is not living up to its manifesto wrt. > Bugzilla, specifically: > > 08 Transparent community-based processes promote participation, > accountability and trust. > > https://www.mozilla.org/en-US/about/manifesto/ I don't agree that this is true. The Bugzilla project has a transparent, community-based contribution process. I don't think the Mozilla manifesto requires Mozilla to upstream every patch it writes to an open source codebase, although I agree it's more unusual if that codebase is itself a Mozilla project. Gerv From denis.roy at eclipse.org Fri Nov 20 19:52:22 2015 From: denis.roy at eclipse.org (Denis Roy) Date: Fri, 20 Nov 2015 14:52:22 -0500 Subject: Backwards development In-Reply-To: References: Message-ID: <564F79F6.1090900@eclipse.org> This discussion is great... and please interpret my emails as a concerned (and grateful) user who wants to understand and help, but is having a hard time. Buzgilla project's roadmap calls for "Push BMO Customizations into Upstream Bugzilla" [1] How are casual contributors supposed to follow along? Sure, that's open ... but that is not transparent. Eclipse could just fork on Github and do our own thing according to our specific needs (sound familiar?) but we believe contributing directly into the upstream project to be far more beneficial in the long run. Too bad Mozilla doesn't see it that way. But as BZ's contribution model is to wait for BMO work to be complete, there is little hope for the rest of us. On 20/11/15 16:15, Denis Roy wrote: >> We've been through this at Eclipse, where many projects had dwindling >> communities and near-zero external contributions, but we've been >> able to help turn that around using modern contribution models >> Gerrit), modern methodologies and careful coaching of projects. > It would be wonderful if someone had the cycles to do this > for Bugzilla. I'd like to, but I just don't have the hours. It is easy. If I were the BZ lead, here is what I would do: 1. Roadmap[1] items must be linked to bugs in Bugzilla. I've requested a wiki.mozilla.org account and volunteer to do this for you. 2. Use this mailing list to discuss the roadmap with the community. Always. No back-channels. 3. Use Bugzilla _exclusively_ to discuss the roadmap items. Leverage Bugzilla's excellent dependency tree to break roadmap items in smaller chunks if need be 4. Instead of "glob is working on something, ask him" ... encourage glob to post his progress on the bug, not on a blog somewhere https://bugzilla.mozilla.org/show_bug.cgi?id=101865#c32 5. Work with the community on getting individual bugs into the codebase. 6. After 2 years, realize that reviewing code patches in Bugzilla is slowing you down, and implement a code review tool. 7. World dominance? YMMV [1] https://wiki.mozilla.org/Bugzilla:Roadmap On 11/20/2015 12:57 PM, Mark C?t? wrote: > Again, the Bugzilla project is not administered by Mozilla. Mozilla > supports it by providing some resources. Coincidentally there are some > Mozilla employees active in the Bugzilla community, but the two are > functionally separate. Creating a software foundation for the Bugzilla > project is a great idea, particularly if it would involve funding to > employ a product manager and, ideally, some developers. It would also > be a large amount of work, and I don't know anyone at the moment who > would want to lead that. > > As for Mozilla's manifesto, I don't think Bugzilla fits into Mozilla's > mission at all, which is reflected by it being a separately governed > project. Maybe it did early on, when the web was young and every > open-source web application Mozilla created helped drive the web > forward. In my opinion, that is no longer the case--there are a vast > number of open-source web applications, and so the web apps that Mozilla > continues to create and maintain mainly act in a supporting role for > Mozilla's mission. This includes BMO specifically, which is an > important tool for projects that are directly related to our mission > (Firefox, Webmaker, etc.). > > I became an Assistant Project Lead for the Bugzilla project, independent > of my role as a manager on Mozilla's Engineering Productivity team, > because I wanted to revive the community, hoping we could develop a more > productive relationship between Bugzilla and BMO. I was pretty naive > about the scope of that work. There is indeed plenty more the Bugzilla > community could do to revive the project, but at some point I had to > admit that the amount of effort and time I would have to put in would > not have a commensurate impact for Mozilla. It is a frustrating and > disappointing situation. > > Mark > > _______________________________________________ > 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 mva at sysfault.org Fri Nov 20 21:29:39 2015 From: mva at sysfault.org (mva at sysfault.org) Date: Fri, 20 Nov 2015 22:29:39 +0100 Subject: Backwards development In-Reply-To: <564D9F87.3020806@mozilla.org> References: <564CDC80.7020107@eclipse.org> <564D9F87.3020806@mozilla.org> Message-ID: <20151120222939.Horde.KeNnCrcAjGW9QXJFJZY0ug1@webmail.df.eu> Quoting Gervase Markham : > Hi Denis, > > On 18/11/15 20:16, Denis Roy wrote: >> Why does Mozilla do this backwards? Wouldn't you want to improve the >> core project and have BMO (and everyone else) consume that? > > In the last couple of years, we have been struggling with the impedance > mismatch of BMO's rapid release cycle (they ship weekly) and regular > requirements for improvements from Mozilla's management, with the > differing pace of development of upstream. For better or worse, the BMO > team have decided that working upstream, doing releases and then > shipping them on bugzilla.mozilla.org is not a model which works given > their constraints. > > They do plan to merge the trunk into their codebase again soon, and I > hope that the upstream developers (as many as there are) will be able to > work together to take that opportunity to port upstream many of the > generally-applicable improvements that have been made on BMO. > >> Short story -- does the Bugzilla project want contributions, or is it >> relegated to being a code dump for Mozilla's bug tracker? > > The Bugzilla project is extremely keen to see contributions, > particularly from outside Mozilla. In fact, Bugzilla's future as an > independent software project depends on it. It does not feel like that. Start to eat your own dog food :-). Use a stock Bugzilla for tracking Bugzilla bugs instead of BMO - right now the pressure on the project itself for its own needs is low, since it benefits from things (BMO) that are not merged into it. How about not closing bugs and feature requests as duplicates, referring to other bugs being more that 4 or 5 years old (with the last comment being equally old)? This neither leaves a good impression nor motivates others to participate even more. Take care of them instead. I have quite a set of changes and enhancements, which I am currently not discussing on the tracker, since I a) won't get any response (or do not expect to get any, based on my experience) b) can expect them to be closed with a referral to an aged bug and thus simply vanish c) will be told that this is an incomplete solution, since it's not generic enough Finally, push small changes and features into Bugzilla, even if they only deal with a minor bit of a bigger solution. My impression right now is that lots of things are hold back to aim for a "generic, one-size-fits-all" approach. Although that's appealing, it will delay features and is not a motivator for contributors. Implement a small feature, then enhance it and get feedback from users about whether your approach is correct (learn from your failures, do not live with them). Cheers Marcus From gerv at mozilla.org Fri Nov 20 21:53:59 2015 From: gerv at mozilla.org (Gervase Markham) Date: Fri, 20 Nov 2015 21:53:59 +0000 Subject: Backwards development In-Reply-To: References: <564CDC80.7020107@eclipse.org> <564D9F87.3020806@mozilla.org> <564F40B0.1020806@eclipse.org> <564F45F7.5080002@mozilla.org> Message-ID: <9dWdnfGn2L7lC9LLnZ2dnUU7-XmdnZ2d@mozilla.org> On 20/11/15 16:24, Dale Harvey wrote: > I am not part of bugzilla / bmo projects, but I dont see how anyone is > being prevented from working on an updated UI for bugzilla. > > I am currently working on https://www.bzlite.com ( > https://github.com/mozilla-b2g/bzlite/) and would very much welcome anyone > who wanted to contribute. Similiarly there is https://www.bzdeck.com which > is also open source. Slighly off-topic: anyone know how to get this working? All I get is an intro para, a link to their wiki, and a note that I need Developer Edition. I have Developer Edition. 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 Sat Nov 21 10:27:07 2015 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 21 Nov 2015 10:27:07 +0000 Subject: Backwards development In-Reply-To: References: <564CDC80.7020107@eclipse.org> <564D9F87.3020806@mozilla.org> Message-ID: On 20/11/15 21:29, mva at sysfault.org wrote: > It does not feel like that. Start to eat your own dog food :-). Use a > stock Bugzilla for tracking Bugzilla bugs instead of BMO - right now > the pressure on the project itself for its own needs is low, since > it benefits from things (BMO) that are not merged into it. I can see some advantages to doing that; but I can also see a lot of work and migration effort. Given that we do not have a great level of resources, we would have to be certain it was worth it. > How about not closing bugs and feature requests as duplicates, > referring to other bugs being more that 4 or 5 years old (with the > last comment being equally old)? This neither leaves a good > impression nor motivates others to participate even more. I'm not sure what alternative you are suggesting. Are you saying we should leave open multiple bugs covering the same problem? The point of marking a bug as a duplicate of another is that the reporter can then see all of the information pertaining to the problem, including what other people have thought about it. Leaving the new bug open would not make anyone more likely to work on the problem in question. > Finally, push small changes and features into Bugzilla, even if they > only deal with a minor bit of a bigger solution. If you have outstanding patches where you have requested a review and aren't getting one, please let me know. > My impression right > now is that lots of things are hold back to aim for a "generic, > one-size-fits-all" approach. Although that's appealing, it will delay > features and is not a motivator for contributors. I agree that historically this balance has sometimes been in the wrong place. 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 Sat Nov 21 10:56:15 2015 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 21 Nov 2015 10:56:15 +0000 Subject: Bugzilla meeting: Wed Nov 25th, 21:00 UTC Message-ID: Hi everyone, Just a reminder that this month's Bugzilla meeting is at a new time, 21:00 UTC (13:00 PST, 16:00 EST, 22:00 CET) as decided by the poll a little while back. So I do hope more people will be able to make it. To find out when it is in your timezone, go here: http://arewemeetingyet.com/UTC/2015-11-25/21:00/Bugzilla%20Meeting https://wiki.mozilla.org/Bugzilla:Meetings has dial-in and agenda details. Hope to see you there :-) 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 Sat Nov 21 13:05:05 2015 From: gerv at mozilla.org (Gervase Markham) Date: Sat, 21 Nov 2015 13:05:05 +0000 Subject: patch proposition to add some functionnality to the Bugzilla 5.0.1 REST API In-Reply-To: <564F27D1.5000906@math.u-bordeaux1.fr> References: <564F27D1.5000906@math.u-bordeaux1.fr> Message-ID: <56506C01.9030302@mozilla.org> Hi Laurent, On 20/11/15 14:01, Laurent Facq wrote: > Hi ! > > i'm new to bugzilla dev. > > i'm trying to hack bugzilla REST API to implement some features i need > like removing group or product, modifying rights groups have on a product. > i know my code is a bit quick & dirty... but may be anyway it can be a > step further :) > > here's my patch against bugzilla 5.0.1 and an example in Ruby of how i > begin to use it. Thanks for making this patch :-) I don't think your original message made it through to all of the group, possibly due to the attachment. The best thing to do is probably to file a bug in bugzilla.mozilla.org and attach it to that. Please feel free to CC me. Gerv From theycallmefish at gmail.com Sat Nov 21 18:24:22 2015 From: theycallmefish at gmail.com (Ryan Wilson) Date: Sat, 21 Nov 2015 11:24:22 -0700 Subject: Bugzilla meeting: Wed Nov 25th, 21:00 UTC In-Reply-To: References: Message-ID: I will be there! On Nov 21, 2015 4:00 AM, "Gervase Markham" wrote: > Hi everyone, > > Just a reminder that this month's Bugzilla meeting is at a new time, > 21:00 UTC (13:00 PST, 16:00 EST, 22:00 CET) as decided by the poll a > little while back. So I do hope more people will be able to make it. > > To find out when it is in your timezone, go here: > http://arewemeetingyet.com/UTC/2015-11-25/21:00/Bugzilla%20Meeting > > https://wiki.mozilla.org/Bugzilla:Meetings has dial-in and agenda details. > > Hope to see you there :-) > > 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 denis.roy at eclipse.org Mon Nov 23 15:12:55 2015 From: denis.roy at eclipse.org (Denis Roy) Date: Mon, 23 Nov 2015 10:12:55 -0500 Subject: Bugzilla meeting: Wed Nov 25th, 21:00 UTC In-Reply-To: References: Message-ID: <56532CF7.50704@eclipse.org> Likewise. On 11/21/2015 01:24 PM, Ryan Wilson wrote: > I will be there! > > On Nov 21, 2015 4:00 AM, "Gervase Markham" > wrote: > > Hi everyone, > > Just a reminder that this month's Bugzilla meeting is at a new time, > 21:00 UTC (13:00 PST, 16:00 EST, 22:00 CET) as decided by the poll a > little while back. So I do hope more people will be able to make it. > > To find out when it is in your timezone, go here: > http://arewemeetingyet.com/UTC/2015-11-25/21:00/Bugzilla%20Meeting > > https://wiki.mozilla.org/Bugzilla:Meetings has dial-in and agenda > details. > > Hope to see you there :-) > > 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 lpsolit at gmail.com Sun Nov 29 14:33:15 2015 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Sun, 29 Nov 2015 15:33:15 +0100 Subject: Have a separate Bugzilla installation for the Bugzilla project? Message-ID: <565B0CAB.5040709@gmail.com> Hi all, Seeing how things are going in the Mozilla world, I would suggest that the Bugzilla project has its own Bugzilla installation, managed by the upstream Bugzilla team itself. More and more users do not understand that BMO != upstream Bugzilla, and having their own installation running unmodified current tip code (currently 5.1) would help 1) users to discover newly implemented features, and 2) developers to find regressions. BMO UI and backend code differ more and more from upstream Bugzilla; some features which exist upstream are being removed from BMO, such as personal tags, see bug 1227316; many bugs reported by Mozilla users are specific to BMO and do not affect upstream. So IMO it makes sense to close the Bugzilla product in BMO and manage upstream bugs in their own Bugzilla installation instead. What do you think? Ignore import/export of existing bugs for now. This is not the most critical part. Myk filed a bug about this migration a long time ago, see https://bugzilla.mozilla.org/show_bug.cgi?id=127876. LpSolit From jochen.wiedmann at gmail.com Sun Nov 29 15:11:19 2015 From: jochen.wiedmann at gmail.com (Jochen Wiedmann) Date: Sun, 29 Nov 2015 16:11:19 +0100 Subject: Have a separate Bugzilla installation for the Bugzilla project? In-Reply-To: <565B0CAB.5040709@gmail.com> References: <565B0CAB.5040709@gmail.com> Message-ID: Makes quite some sense to me. Jochen On Sun, Nov 29, 2015 at 3:33 PM, Fr?d?ric Buclin wrote: > Hi all, > > Seeing how things are going in the Mozilla world, I would suggest that > the Bugzilla project has its own Bugzilla installation, managed by the > upstream Bugzilla team itself. More and more users do not understand > that BMO != upstream Bugzilla, and having their own installation running > unmodified current tip code (currently 5.1) would help 1) users to > discover newly implemented features, and 2) developers to find regressions. > > BMO UI and backend code differ more and more from upstream Bugzilla; > some features which exist upstream are being removed from BMO, such as > personal tags, see bug 1227316; many bugs reported by Mozilla users are > specific to BMO and do not affect upstream. So IMO it makes sense to > close the Bugzilla product in BMO and manage upstream bugs in their own > Bugzilla installation instead. > > What do you think? Ignore import/export of existing bugs for now. This > is not the most critical part. > > Myk filed a bug about this migration a long time ago, see > https://bugzilla.mozilla.org/show_bug.cgi?id=127876. > > > LpSolit > > - > To view or change your list settings, click here: > -- The next time you hear: "Don't reinvent the wheel!" http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg From denis.roy at eclipse.org Sun Nov 29 15:16:45 2015 From: denis.roy at eclipse.org (Denis Roy) Date: Sun, 29 Nov 2015 10:16:45 -0500 Subject: Have a separate Bugzilla installation for the Bugzilla project? Message-ID: I agree and I'm willing to help get things going. --Denis Roy?@droy_eclipsehttp://eclipse.org/ -------- Original message -------- From: Fr?d?ric Buclin Date: 2015-11-29 9:33 AM (GMT-05:00) To: developers at bugzilla.org Subject: Have a separate Bugzilla installation for the Bugzilla project? Hi all, Seeing how things are going in the Mozilla world, I would suggest that the Bugzilla project has its own Bugzilla installation, managed by the upstream Bugzilla team itself. More and more users do not understand that BMO != upstream Bugzilla, and having their own installation running unmodified current tip code (currently 5.1) would help 1) users to discover newly implemented features, and 2) developers to find regressions. BMO UI and backend code differ more and more from upstream Bugzilla; some features which exist upstream are being removed from BMO, such as personal tags, see bug 1227316; many bugs reported by Mozilla users are specific to BMO and do not affect upstream. So IMO it makes sense to close the Bugzilla product in BMO and manage upstream bugs in their own Bugzilla installation instead. What do you think? Ignore import/export of existing bugs for now. This is not the most critical part. Myk filed a bug about this migration a long time ago, see https://bugzilla.mozilla.org/show_bug.cgi?id=127876. LpSolit - To view or change your list settings, click here: -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpsolit at gmail.com Sun Nov 29 15:34:41 2015 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Sun, 29 Nov 2015 16:34:41 +0100 Subject: Have a separate Bugzilla installation for the Bugzilla project? In-Reply-To: References: <565B0CAB.5040709@gmail.com> Message-ID: <565B1B11.9040606@gmail.com> I forgot to mention: The Testopia product on BMO should also be moved to the new Bugzilla installation as it's tied to upstream Bugzilla, not BMO. As I see it, this could make things easier to manage and develop Bugzilla extensions, as each extension could have its own product on the new installation, with its own set of contributors. Something similar to what Mozdev did: https://www.mozdev.org/bugs/describecomponents.cgi LpSolit From mva at sysfault.org Sun Nov 29 21:04:17 2015 From: mva at sysfault.org (mva at sysfault.org) Date: Sun, 29 Nov 2015 22:04:17 +0100 Subject: Have a separate Bugzilla installation for the Bugzilla project? In-Reply-To: <565B0CAB.5040709@gmail.com> References: <565B0CAB.5040709@gmail.com> Message-ID: <20151129220417.Horde.qtD3nMctZedb6IjI12IiwQ6@webmail.df.eu> Quoting Fr?d?ric Buclin : > Hi all, > > Seeing how things are going in the Mozilla world, I would suggest that > the Bugzilla project has its own Bugzilla installation, managed by the > upstream Bugzilla team itself. More and more users do not understand > that BMO != upstream Bugzilla, and having their own installation running > unmodified current tip code (currently 5.1) would help 1) users to > discover newly implemented features, and 2) developers to find regressions. > > BMO UI and backend code differ more and more from upstream Bugzilla; > some features which exist upstream are being removed from BMO, such as > personal tags, see bug 1227316; many bugs reported by Mozilla users are > specific to BMO and do not affect upstream. So IMO it makes sense to > close the Bugzilla product in BMO and manage upstream bugs in their own > Bugzilla installation instead. > > What do you think? [...] A long overdue task; go for it. Cheers Marcus From dylan at mozilla.com Mon Nov 30 03:14:10 2015 From: dylan at mozilla.com (Dylan Hardison) Date: Sun, 29 Nov 2015 22:14:10 -0500 Subject: Topline goal ideas for Bugzilla based on what a few sites are doing or needing Message-ID: During the bugzilla meeting last week, I offered my opinion that the project should have some top-line goals that directly relate to interested parties. I also volunteered to research this. I spent a bit of time on bugzilla.redhat.com, bugzilla.gnome.org, and bugs.eclipse.org. 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". What I've compiled (which is not much) is now available on the wiki page: https://wiki.mozilla.org/Bugzilla:Ideas I have done this of my own time -- the opinions I hold are very probably distinct from those of the BMO team. But then, I have only been acquainted with Bugzilla for 2 out of its 17 year history. :-) Let's work over these ideas on the wiki -- and also on the mailing list if that is appropriate -- and come together for the December 23rd meeting with a set of high level goals that users of bugzilla can benefit from. From denis.roy at eclipse.org Mon Nov 30 14:41:12 2015 From: denis.roy at eclipse.org (Denis Roy) Date: Mon, 30 Nov 2015 09:41:12 -0500 Subject: Have a separate Bugzilla installation for the Bugzilla project? In-Reply-To: <565B0CAB.5040709@gmail.com> References: <565B0CAB.5040709@gmail.com> Message-ID: <565C6008.8090702@eclipse.org> As I've posted on the bug, I'm behind this and Eclipse can offer a pair of load-balanced virtual servers to which the core developers all have root accces to, to run Bugzilla, the build system and whatever is needed. Eclipse IT staff will also maintain (sysadmin) the servers so that core devs don't have to waste their time on this task. Denis On 11/29/2015 09:33 AM, Fr?d?ric Buclin wrote: > Hi all, > > Seeing how things are going in the Mozilla world, I would suggest that > the Bugzilla project has its own Bugzilla installation, managed by the > upstream Bugzilla team itself. More and more users do not understand > that BMO != upstream Bugzilla, and having their own installation running > unmodified current tip code (currently 5.1) would help 1) users to > discover newly implemented features, and 2) developers to find regressions. > > BMO UI and backend code differ more and more from upstream Bugzilla; > some features which exist upstream are being removed from BMO, such as > personal tags, see bug 1227316; many bugs reported by Mozilla users are > specific to BMO and do not affect upstream. So IMO it makes sense to > close the Bugzilla product in BMO and manage upstream bugs in their own > Bugzilla installation instead. > > What do you think? Ignore import/export of existing bugs for now. This > is not the most critical part. > > Myk filed a bug about this migration a long time ago, see > https://bugzilla.mozilla.org/show_bug.cgi?id=127876. > > > LpSolit > > - > To view or change your list settings, click here: > > From gerv at mozilla.org Mon Nov 30 16:20:14 2015 From: gerv at mozilla.org (Gervase Markham) Date: Mon, 30 Nov 2015 16:20:14 +0000 Subject: Have a separate Bugzilla installation for the Bugzilla project? In-Reply-To: <565B0CAB.5040709@gmail.com> References: <565B0CAB.5040709@gmail.com> Message-ID: <565C773E.4040109@mozilla.org> 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. Gerv From theycallmefish at gmail.com Mon Nov 30 16:31:50 2015 From: theycallmefish at gmail.com (Ryan Wilson) Date: Mon, 30 Nov 2015 09:31:50 -0700 Subject: Have a separate Bugzilla installation for the Bugzilla project? In-Reply-To: <565C773E.4040109@mozilla.org> References: <565B0CAB.5040709@gmail.com> <565C773E.4040109@mozilla.org> Message-ID: I'm definitely for this idea, maybe allocate it to bugs.bugzilla.org to cause the least confusion? On Mon, Nov 30, 2015 at 9:20 AM, 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. > > Gerv > > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From justdave at bugzilla.org Mon Nov 30 16:41:20 2015 From: justdave at bugzilla.org (Dave Miller) Date: Mon, 30 Nov 2015 11:41:20 -0500 Subject: Have a separate Bugzilla installation for the Bugzilla project? In-Reply-To: <565C773E.4040109@mozilla.org> References: <565B0CAB.5040709@gmail.com> <565C773E.4040109@mozilla.org> Message-ID: <565C7C30.9090303@bugzilla.org> 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. -- 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 lpsolit at gmail.com Mon Nov 30 16:42:44 2015 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Mon, 30 Nov 2015 17:42:44 +0100 Subject: Have a separate Bugzilla installation for the Bugzilla project? In-Reply-To: References: <565B0CAB.5040709@gmail.com> <565C773E.4040109@mozilla.org> Message-ID: <565C7C84.60106@gmail.com> Le 30. 11. 15 17:31, Ryan Wilson a ?crit : > I'm definitely for this idea, maybe allocate it to bugs.bugzilla.org to > cause the least confusion? Yes, I agree. A much better name than bugzilla.bugzilla.org. LpSolit From theycallmefish at gmail.com Mon Nov 30 17:16:09 2015 From: theycallmefish at gmail.com (Ryan Wilson) Date: Mon, 30 Nov 2015 10:16:09 -0700 Subject: Have a separate Bugzilla installation for the Bugzilla project? In-Reply-To: <565C7C84.60106@gmail.com> References: <565B0CAB.5040709@gmail.com> <565C773E.4040109@mozilla.org> <565C7C84.60106@gmail.com> Message-ID: Should we run an implementation of Testopia on the new system, or would that go against the 'unmodified' state of this system? I'm willing to assist on that process. On Mon, Nov 30, 2015 at 9:42 AM, Fr?d?ric Buclin wrote: > Le 30. 11. 15 17:31, Ryan Wilson a ?crit : > > I'm definitely for this idea, maybe allocate it to bugs.bugzilla.org to > > cause the least confusion? > > Yes, I agree. A much better name than bugzilla.bugzilla.org. > > LpSolit > > - > To view or change your list settings, click here: > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lpsolit at gmail.com Mon Nov 30 17:23:40 2015 From: lpsolit at gmail.com (=?UTF-8?B?RnLDqWTDqXJpYyBCdWNsaW4=?=) Date: Mon, 30 Nov 2015 18:23:40 +0100 Subject: Have a separate Bugzilla installation for the Bugzilla project? In-Reply-To: References: <565B0CAB.5040709@gmail.com> <565C773E.4040109@mozilla.org> <565C7C84.60106@gmail.com> Message-ID: <565C861C.3010409@gmail.com> Le 30. 11. 15 18:16, Ryan Wilson a ?crit : > Should we run an implementation of Testopia on the new system, or would > that go against the 'unmodified' state of this system? I'm willing to > assist on that process. If we have a real use for Testopia (this would be a separate discussion), it could be applied to the installation IMO. But in all cases, I wouldn't do it till Testopia 3.0 is released (i.e. finish the bug you are working on about killing all tr_*.cgi scripts) and till all security bugs are fixed. (Bonus point for ExtJS -> jQuery) LpSolit