Backwards development

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Backwards development

Denis Roy
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:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Backwards development

Mark Côté
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:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=dev-apps-bugzilla@...>
>

_______________________________________________
dev-apps-bugzilla mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Backwards development

Frédéric Buclin
In reply to this post by Denis Roy
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.

<proposal>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.</proposal>


LpSolit

-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Backwards development

Gervase Markham
In reply to this post by Denis Roy
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
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Backwards development

Denis Roy
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
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Backwards development

Gervase Markham
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:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Backwards development

Denis Roy
In reply to this post by Mark Côté
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
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Backwards development

Dale Harvey
In reply to this post by Gervase Markham
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 <[hidden email]> 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:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=dale@...>

Reply | Threaded
Open this post in threaded view
|

Re: Backwards development

Dave Miller
In reply to this post by Denis Roy
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:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Backwards development

Ryan Wilson-9
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 <[hidden email]> 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:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=theycallmefish@...>

Reply | Threaded
Open this post in threaded view
|

Re: Backwards development

Mark Côté
In reply to this post by Mark Côté
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Backwards development

Gervase Markham
In reply to this post by Denis Roy
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
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Backwards development

Denis Roy
In reply to this post by Mark Côté
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
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-apps-bugzilla
> -
> To view or change your list settings, click here:
> <http://bugzilla.org/cgi-bin/mj_wwwusr?user=denis.roy@...>
>
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
mva
Reply | Threaded
Open this post in threaded view
|

Re: Backwards development

mva
In reply to this post by Gervase Markham

Quoting Gervase Markham <[hidden email]>:

> 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


-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Backwards development

Gervase Markham
In reply to this post by Gervase Markham
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
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>
Reply | Threaded
Open this post in threaded view
|

Re: Backwards development

Gervase Markham
In reply to this post by Gervase Markham
On 20/11/15 21:29, [hidden email] 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
[hidden email]
https://lists.mozilla.org/listinfo/dev-apps-bugzilla
-
To view or change your list settings, click here:
<http://bugzilla.org/cgi-bin/mj_wwwusr?user=lists+s6506n84121h51@...>