Bug Importance

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

Re: Bug Importance

beltzner
On Thu, Apr 5, 2012 at 2:57 AM, Justin Dolske <[hidden email]> wrote:
> is to have consistency across areas. Perhaps the answer lies in a clear
> difference between fields of relevance to end-users vs those who drive a
> component.

This, so very much this.

There are many ways one could choose to modify the design of Bugzilla
(and yes, I guess it is that time of year again!) in order to help
with this and other difficult interactions regarding the proper
filing, marking and tracking of bugs, but the one I seldom hear
offered is to provide different views based on the task / goals of the
user.

cheers,
mike
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance - Simplifying

Benjamin Smedberg
In reply to this post by Mark Banner-4
On 4/5/2012 5:03 AM, Mark Banner wrote:
>
> Err wrong. Thunderbird, MailNews Core use at least the enhancement and
> normal levels of Importance (we also use critical for crashes, but
> that tends to be duplicated by the "crash" keyword.
>
> Minor/Major and Blocking do get used, but not that extensively IMO.
>
> Off the top of my head, I'd say we could probably remove that severity
> field and replace it by one checkbox: enhancement.
How do you currently use the field? For searches? I'd argue that
explicit metadata fields (either the severity dropdown or a separate
checkbox) are only useful if we need to search or order on the results.

I know that the server ops people use severity in this way quite
explicitly (to trigger oncall emails or pages, etc). But in the code
products, even in cases where the severity field is "correct", I've
never seen an automated query use the data in an especially useful way.
So if we could just mark enhancements in the bug comments or the
whiteboard, we'd achieve the same results for human readers without
having required metadata.

Presumably an enhancement keyword would be equivalent to an enhancement
checkbox?

--BDS

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Steve Wendt
In reply to this post by Gavin Sharp-3
On 4/4/2012 11:24 PM, Byron Jones wrote:

> or assume that if someone isn't using the guided form, they know what
> they are doing, and default platform/os to "all" without capturing the
> reporter's platform information.

This sounds perfect, and is dead simple.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Mike Hoye-2
In reply to this post by beltzner
On 12-04-05 10:48 AM, beltzner wrote:

> There are many ways one could choose to modify the design of Bugzilla
> (and yes, I guess it is that time of year again!) in order to help
> with this and other difficult interactions regarding the proper
> filing, marking and tracking of bugs, but the one I seldom hear
> offered is to provide different views based on the task / goals of the
> user.

Following this thread and having some conversations around MoTo, the
following things are true:

- Probably no two people, and definitely no two teams, use Bugzilla's
flags the same way.

- Many people use Bugzilla fields that their team doesn't use for their
own reasons, which may conflict with other team members' uses. This
seems to be navigated based on ownership, with people not modifying
those flags in other people's bugs.

- Some of the ways some of the people use some of the flags aren't
cleanly aligned with with those flags' names or their historical usage
norms.


None of that would be a problem if it wasn't for the fact that
Bugzilla's data layer and presentation layer are inseparable. No one
team can have a view of their bugs that doesn't expose stuff they or
their team either don't care about, or that doesn't make sense or
doesn't agree with their team or personal norms.

Bugzilla doesn't need a big-bang redesign beyond a few sane-default
choices, but it does need to be _made designable_ by separating
presentation and data in a way that individuals and teams can modify to
their needs.

It doesn't have to be more complicated than an extension, I think, but
it does need two thing. The most important, I think, to admit that
Mozilla is now too big for there to be a de-jure, much less de-facto
internal monoculture, or One Right Way To Work.

The second is a way to publish those customizations, so that on a wiki
somewhere the (say) Accessibility or Graphics teams (or whoever) have a
say of saying, these are the parts of Bugzilla we focus on, so if you
want to bring something to our attention, these are the flags we
actually watch. this is the Bugzilla Dialect that we prefer.

A nice upside to this would be sane presentation-layer defaults for new
users, to smooth the new-contributor onramp by hiding the scarier and
noisier parts of bugzilla until they're ready to pull that curtain back
themselves.

--
Michael Hoye
Bespoke I/O
http://bespokeio.com


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Justin Lebar-3
> [We should] admit that Mozilla is
> now too big for there to be a de-jure, much less de-facto internal
> monoculture, or One Right Way To Work.

While I agree with this, I disagree with the specific suggestions here.

In particular, I think it would be Bad if I had to install an
extension (or otherwise take some action locally) in order to see the
blessed "gfx/accessibility/whatever-centric" view of Bugzilla.  Things
are already complex enough as-is, and this just adds a whole new set
of ways for me to screw things up.

What we've done in MemShrink is simply add [MemShrink:P{1,2,3}] to
bugs' whiteboards.  This has worked out well for us.  It's clear who
owns the priority, and it gives people a clear way to ask us to look
at a bug (just tag it with [MemShrink]).

On Thu, Apr 5, 2012 at 2:35 PM, Mike Hoye <[hidden email]> wrote:

> On 12-04-05 10:48 AM, beltzner wrote:
>
>> There are many ways one could choose to modify the design of Bugzilla
>> (and yes, I guess it is that time of year again!) in order to help
>> with this and other difficult interactions regarding the proper
>> filing, marking and tracking of bugs, but the one I seldom hear
>> offered is to provide different views based on the task / goals of the
>> user.
>
>
> Following this thread and having some conversations around MoTo, the
> following things are true:
>
> - Probably no two people, and definitely no two teams, use Bugzilla's flags
> the same way.
>
> - Many people use Bugzilla fields that their team doesn't use for their own
> reasons, which may conflict with other team members' uses. This seems to be
> navigated based on ownership, with people not modifying those flags in other
> people's bugs.
>
> - Some of the ways some of the people use some of the flags aren't cleanly
> aligned with with those flags' names or their historical usage norms.
>
>
> None of that would be a problem if it wasn't for the fact that Bugzilla's
> data layer and presentation layer are inseparable. No one team can have a
> view of their bugs that doesn't expose stuff they or their team either don't
> care about, or that doesn't make sense or doesn't agree with their team or
> personal norms.
>
> Bugzilla doesn't need a big-bang redesign beyond a few sane-default choices,
> but it does need to be _made designable_ by separating presentation and data
> in a way that individuals and teams can modify to their needs.
>
> It doesn't have to be more complicated than an extension, I think, but it
> does need two thing. The most important, I think, to admit that Mozilla is
> now too big for there to be a de-jure, much less de-facto internal
> monoculture, or One Right Way To Work.
>
> The second is a way to publish those customizations, so that on a wiki
> somewhere the (say) Accessibility or Graphics teams (or whoever) have a say
> of saying, these are the parts of Bugzilla we focus on, so if you want to
> bring something to our attention, these are the flags we actually watch.
> this is the Bugzilla Dialect that we prefer.
>
> A nice upside to this would be sane presentation-layer defaults for new
> users, to smooth the new-contributor onramp by hiding the scarier and
> noisier parts of bugzilla until they're ready to pull that curtain back
> themselves.
>
> --
> Michael Hoye
> Bespoke I/O
> http://bespokeio.com
>
>
>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Mike Hoye-2
On 12-04-05 3:17 PM, Justin Lebar wrote:
> While I agree with this, I disagree with the specific suggestions here.
>
> In particular, I think it would be Bad if I had to install an
> extension (or otherwise take some action locally) in order to see the
> blessed "gfx/accessibility/whatever-centric" view of Bugzilla.  Things
> are already complex enough as-is, and this just adds a whole new set
> of ways for me to screw things up.

So, I expressed myself badly there: as you rightly note, that would
everyone has a worse problem.

What I meant by that was that it be put up as a way for teams to
communicate how they use bugzilla, and what's important to them in
Bugzilla's data fields. That is, a way to better understand each other
other teams, instead of another hurdle you have to overcome to get
anything done across teams.


--
Michael Hoye
Bespoke I/O
http://bespokeio.com


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Zack Weinberg-2
In reply to this post by Ben Bucksch
On 2012-04-04 11:15 AM, Jeff Hammel wrote:

> On 04/04/2012 11:07 AM, Ben Bucksch wrote:
>> On 04.04.2012 19:41, David E. Ross wrote:
>>> I am seeing a number of bugzilla.mozilla.org bug reports submitted by
>>> Mozilla developers with the Importance set at Normal.
>>> ...these bug reports involve a "request for enhancement"
>>>
>>> Is no one monitoring this situation?
>>
>> I also closely monitor the fact that people file bugs with OS: Linux,
>> although the bug applies to all operating systems and CPUs. This is
>> directly discriminating those other OSes, and I object to that.

Discrimination against OSes where we are in direct competition with the
OS vendor is necessary for our long-term survival (hhos).

> I also have a bit of an allergy to people that don't put in platform
> correctly. I understand why the default is there -- to get as much info
> as possible from people who may not be filling out a bug report
> correctly, typically those new to bugzilla. But, especially (?) not
> working on mozilla-central, I see many things that are blatantly
> misfiled.

Nearly all the bugs I file, I know _a priori_ it's not a
platform-specific bug.  Nearly all the platform-specific bugs I file are
reported to me by various informants, who are not using the same
platform as me.  (And I can't remember the last time I filed a bug that
was in any way *CPU* specific, although I'm sure it happens,
particularly over in JIT land.)  Therefore the default-from-user-agent
behavior is almost always wrong for me, and I know I don't always
remember to reset it.

Which is to say, I'd definitely support the defaults being changed to
all:all.

zw
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance - Simplifying

Robert Kaiser
In reply to this post by Mark Banner-4
Benjamin Smedberg schrieb:
> But in the code
> products, even in cases where the severity field is "correct", I've
> never seen an automated query use the data in an especially useful way.

In earlier years of the SeaMonkey projects, we had regular bug triage on
"all old bugs that are not marked as enhancement", as real bugs were
often eliminated with switching to a different codebase or through other
work - RFEs mostly stayed valid.
Not sure if current drivers of the project are still doing this, though.

Robert Kaiser
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Daniel Veditz-2
In reply to this post by Dave Mandelin-2
On 4/4/12 11:24 AM, Dave Mandelin wrote:
> I keep a text file on the side to track important bugs, but
> that's not a very good system either--I'd love to be able to
> share that info more easily.

Two bugzilla alternatives you can consider: tracking bugs and
tags/shared queries.

If you have a project goal that you think several team members will
be interested in you could have "tracking bug" with all of your
"important bugs" added to the "depends on" field.
 - gets unwieldy for ongoing concepts like "important",
   but works for "important for release X".
 - if they're only important to -you- it clutters communal
   bugzilla with personal bugs
 - easily managed and shared with a team
 - the tracking bug can be given an easily remembered "alias"

If this is a list of mostly personal interest then consider the
Bugzilla "tag" feature. You first have to turn it on in preferences,
and then you can easily add the current bug to any tagged list. The
tag will create a named query which is added to your page footer for
easy access.
  - tagged list can be shared with others from the Saved Searches
    tab in bugzilla prefs.
  - somewhat clunky to manage, but not too different than
    editing the "Depends on" field.

Neither is perfect, but might be better than "a text file on the side".

-Dan Veditz
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Dave Mandelin-2
In reply to this post by Dave Mandelin-2
On Friday, April 6, 2012 1:40:41 PM UTC-7, Daniel Veditz wrote:

> On 4/4/12 11:24 AM, Dave Mandelin wrote:
> > I keep a text file on the side to track important bugs, but
> > that's not a very good system either--I'd love to be able to
> > share that info more easily.
>
> Two bugzilla alternatives you can consider: tracking bugs and
> tags/shared queries.
>
> If you have a project goal that you think several team members will
> be interested in you could have "tracking bug" with all of your
> "important bugs" added to the "depends on" field.
>  - gets unwieldy for ongoing concepts like "important",
>    but works for "important for release X".
>  - if they're only important to -you- it clutters communal
>    bugzilla with personal bugs
>  - easily managed and shared with a team
>  - the tracking bug can be given an easily remembered "alias"
>
> If this is a list of mostly personal interest then consider the
> Bugzilla "tag" feature. You first have to turn it on in preferences,
> and then you can easily add the current bug to any tagged list. The
> tag will create a named query which is added to your page footer for
> easy access.
>   - tagged list can be shared with others from the Saved Searches
>     tab in bugzilla prefs.
>   - somewhat clunky to manage, but not too different than
>     editing the "Depends on" field.
>
> Neither is perfect, but might be better than "a text file on the side".

I thought of the tracking bug thing before, but for reasons I don't recall decided not to use it. Maybe it's because I reclassify bugs fairly often and also change the classification scheme, so there would be a lot of churn.

I'll look into the tags, though, next time I take a look at my systems. It might work well.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

glob
In reply to this post by Mike Hoye-2
Mike Hoye wrote:
> None of that would be a problem if it wasn't for the fact that
> Bugzilla's data layer and presentation layer are inseparable. No one
> team can have a view of their bugs that doesn't expose stuff they or
> their team either don't care about, or that doesn't make sense or
> doesn't agree with their team or personal norms.
this is definitely not the case - bugzilla's data and presentation
layers are separate (internally and externally).

we have webservices which teams can, and do, use to provide their own
view of the data on bmo.

bugzilla has xml-rpc and json-rpc natively
(http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/WebService.html),
and gerv has a proxy which sits in front of bmo which provides a REST
api (https://wiki.mozilla.org/Bugzilla:REST_API).

i'm also not against providing limited per-product customisation of the
native bugzilla UI on bmo.

--
byron - irc:glob - bugzilla.mozilla.org team -

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Gervase Markham
In reply to this post by beltzner
On 05/04/12 19:35, Mike Hoye wrote:

> None of that would be a problem if it wasn't for the fact that
> Bugzilla's data layer and presentation layer are inseparable. No one
> team can have a view of their bugs that doesn't expose stuff they or
> their team either don't care about, or that doesn't make sense or
> doesn't agree with their team or personal norms.
>
> Bugzilla doesn't need a big-bang redesign beyond a few sane-default
> choices, but it does need to be _made designable_ by separating
> presentation and data in a way that individuals and teams can modify to
> their needs.

I don't think it's necessarily true to say that the data and
presentation layers are inseperable. There are 2 things which make this
not the case:

1) Template formats. Pretty much any Bugzilla screen can have multiple
HTML views; all that's required is writing a template in Template
Toolkit. Usually, this feature is used to e.g. provide CSV forms of
buglists, but there's no reason that a page can't have two HTML
versions. The enter bug page does:

https://bugzilla.mozilla.org/enter_bug.cgi?format=guided
https://bugzilla.mozilla.org/enter_bug.cgi

If people want to write new templates for Bugzilla, get in touch and we
can show you how.

2) BzAPI. Write your own front end, exposing whatever data you like and
using web technologies, using Bugzilla's REST API:
https://wiki.mozilla.org/Bugzilla:REST_API

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Mike Hoye-2
In reply to this post by glob
On 12-04-09 7:32 AM, Byron Jones wrote:

>
> we have webservices which teams can, and do, use to provide their own
> view of the data on bmo.
>
> bugzilla has xml-rpc and json-rpc natively
> (http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/WebService.html),
> and gerv has a proxy which sits in front of bmo which provides a REST
> api (https://wiki.mozilla.org/Bugzilla:REST_API).
>
> i'm also not against providing limited per-product customisation of the
> native bugzilla UI on bmo.

I've received this via email from a few other people as well. I've read
it a few times now, and I'm trying to figure out if there's a more
charitable way to interpret it than "If you don't like the bugzilla
interface, write your own. Patches accepted maybe, but probably not."

Right now, I'm looking at   https://github.com/mozilla   and I see that:

- BrowserID
- Mozillians
- OpenBadges
- OpenWebApps

are all doing their issue tracking over there. So are BrowserQuest and
PDF.js and DXR and a bunch of other projects that are important parts of
Mozilla's development processes or ecosystem or actual shipping products.

Those are just the ones I recognized well enough to drill into; that
list is pretty long.

Why are they all over there? I mean, git, sure. Git's awesome. But why
is all the issue tracking stuff over there too?

Is it because there's no formal policy about where Mozilla's bugs go, or
because the time-cost of using Bugzilla is comparatively too high for
people already at Github? Is it because the advantages of Git over the
current build process make balkanizing your knowledge base look like
acceptable collateral damage?

Maybe all those costs are hidden, or nobody's asked them not to do that.
Is it because it's just that much easier?

I don't have answers to those questions, but I sure hope they're on
somebody's radar, because you've got a real, systemic issue here that is
right-now-today actively fragmenting Mozilla's most important repository
of self-knowledge. And that's happening at the same time that the
organization is growing like mad.

This is large, structural problem with long-term implications. It's got
a UX component, sure, but it's also got a policy component and a
management component, and has as much to do with Mozilla's ability to
ship software a decade from now as it does with nagging day-to-day
usability problems.

How many new accounts on new services will somebody need to sign up for
in a decade, just to figure out where the bug they want to help with
actually lives? I can answer that, and it will be one of "zero", "one"
or "something is horribly wrong".

Gerv's API is great. XML-RPC and JSON-RPC: killer. Critical tools for
addressing these issues, no question. But this is a sprawling problem,
and as much as I wish otherwise, it's not something I think I can
address by reskinning Bugzilla just for me.

Thanks for your time,

--
Michael Hoye
Bespoke I/O
http://bespokeio.com


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Joshua Cranmer-2
In reply to this post by glob
On 4/10/2012 12:44 PM, Mike Hoye wrote:

> On 12-04-09 7:32 AM, Byron Jones wrote:
>>
>> we have webservices which teams can, and do, use to provide their own
>> view of the data on bmo.
>>
>> bugzilla has xml-rpc and json-rpc natively
>> (http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/WebService.html),
>> and gerv has a proxy which sits in front of bmo which provides a REST
>> api (https://wiki.mozilla.org/Bugzilla:REST_API).
>>
>> i'm also not against providing limited per-product customisation of the
>> native bugzilla UI on bmo.
>
> I've received this via email from a few other people as well. I've
> read it a few times now, and I'm trying to figure out if there's a
> more charitable way to interpret it than "If you don't like the
> bugzilla interface, write your own. Patches accepted maybe, but
> probably not."
>
> Right now, I'm looking at   https://github.com/mozilla   and I see that:
>
> - BrowserID
> - Mozillians
> - OpenBadges
> - OpenWebApps
>
> are all doing their issue tracking over there. So are BrowserQuest and
> PDF.js and DXR and a bunch of other projects that are important parts
> of Mozilla's development processes or ecosystem or actual shipping
> products.
>
At least one of the projects you mentioned does not use github's issue
tracking (DXR uses Bugzilla more than github). I also see issue tracking
for some PDF.js stuff in Bugzilla.

Having used both Bugzilla and github's tracker, I can honestly say that
I prefer Bugzilla by several orders of magnitude. About the only benefit
that github has over Bugzilla is the tight integration with the VCS.

> I don't have answers to those questions, but I sure hope they're on
> somebody's radar, because you've got a real, systemic issue here that
> is right-now-today actively fragmenting Mozilla's most important
> repository of self-knowledge. And that's happening at the same time
> that the organization is growing like mad.
Is Bugzilla really more important a repository of self-knowledge then
any of our other repositories? Like mailing lists, newsgroups [1],
blogs, IRC, the wiki, devmo, mozillazine, and Firefox Input?

[1] Actually, the last time I checked, we had two separate mailing list
servers, some of which are further replicated on Google Groups and
another set are replicated on newsgroups. We may even have some Google
Groups things that aren't replicated on our own mailing list servers,
IIRC. How is this any less infuriating a fragmentation than having some
projects use bug trackers? Actually, many people file bugs in extensions
in bugzilla.mozilla.org instead of with the extension author. We also
have issues where bugs get reported for Firefox in other trackers (think
Ubuntu's or Debian's trackers, e.g.). It's not an insurmountable
problem, as long as there is someone who can redispatch bug reports to
appropriate places.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Mike Hoye-2
On 12-04-10 2:20 PM, Joshua Cranmer wrote:
> Actually, the last time I checked, we had two separate mailing list
> servers, some of which are further replicated on Google Groups and
> another set are replicated on newsgroups. We may even have some Google
> Groups things that aren't replicated on our own mailing list servers,
> IIRC. How is this any less infuriating a fragmentation than having some
> projects use bug trackers?

I think that where issues are discussed isn't as important as tracking
the progress of issues being resolved. But sure, it's not the only issue
Mozilla is facing. If you only had one, you wouldn't need an issue
tracker at all.

--
Michael Hoye
Bespoke I/O
http://bespokeio.com


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Philip Chee
In reply to this post by glob
On Tue, 10 Apr 2012 13:44:38 -0400, Mike Hoye wrote:

> On 12-04-09 7:32 AM, Byron Jones wrote:
>>
>> we have webservices which teams can, and do, use to provide their own
>> view of the data on bmo.
>>
>> bugzilla has xml-rpc and json-rpc natively
>> (http://www.bugzilla.org/docs/4.0/en/html/api/Bugzilla/WebService.html),
>> and gerv has a proxy which sits in front of bmo which provides a REST
>> api (https://wiki.mozilla.org/Bugzilla:REST_API).
>>
>> i'm also not against providing limited per-product customisation of the
>> native bugzilla UI on bmo.
>
> I've received this via email from a few other people as well. I've read
> it a few times now, and I'm trying to figure out if there's a more
> charitable way to interpret it than "If you don't like the bugzilla
> interface, write your own. Patches accepted maybe, but probably not."
>
> Right now, I'm looking at   https://github.com/mozilla   and I see that:
>
> - BrowserID
> - Mozillians
> - OpenBadges
> - OpenWebApps
>
> are all doing their issue tracking over there. So are BrowserQuest and
> PDF.js and DXR and a bunch of other projects that are important parts of
> Mozilla's development processes or ecosystem or actual shipping products.
>
> Those are just the ones I recognized well enough to drill into; that
> list is pretty long.
>
> Why are they all over there? I mean, git, sure. Git's awesome. But why
> is all the issue tracking stuff over there too?
>
> Is it because there's no formal policy about where Mozilla's bugs go, or
> because the time-cost of using Bugzilla is comparatively too high for
> people already at Github? Is it because the advantages of Git over the
> current build process make balkanizing your knowledge base look like
> acceptable collateral damage?
>
> Maybe all those costs are hidden, or nobody's asked them not to do that.
> Is it because it's just that much easier?
>
> I don't have answers to those questions, but I sure hope they're on
> somebody's radar, because you've got a real, systemic issue here that is
> right-now-today actively fragmenting Mozilla's most important repository
> of self-knowledge. And that's happening at the same time that the
> organization is growing like mad.

Which brings up a point that wasn't adequately addressed the last time
this (github et al) was brought up. What backup contingency plans do we
have if GitHub goes tits-up? Originally it was suggested that Mozilla
hold a regularly upated git copy of all the Github Mozilla projects
behind our firewall. Has this been implemented?

The Github issue tracker might not so critical but useful technical
details might get lost in the shuffle. I believe that several Linux
distributors (e.g. Ubuntu) have some functionality that automatically
copies comments in b.m.o to their own bugzilla/issue tracker for Mozilla
bugs that they have dependencies for. Can we do the same here?

Phil

--
Philip Chee <[hidden email]>, <[hidden email]>
http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
Guard us from the she-wolf and the wolf, and guard us from the thief,
oh Night, and so be good for us to pass.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Gervase Markham
In reply to this post by glob
On 10/04/12 18:44, Mike Hoye wrote:
> I've received this via email from a few other people as well. I've read
> it a few times now, and I'm trying to figure out if there's a more
> charitable way to interpret it than "If you don't like the bugzilla
> interface, write your own.

That's basically what it is. Several people have. :-) We can't make the
UI all things to all people - that's why I wrote BzAPI. That doesn't
mean it can't be improved, but it does mean that the quickest route to
happiness for any one particular group may be to write their own tool.

> Patches accepted maybe, but probably not."

If it's just an alternative template view for a bug, I don't see any
reason the patch wouldn't be accepted.

> Why are they all over there? I mean, git, sure. Git's awesome. But why
> is all the issue tracking stuff over there too?

Integration, I suspect. Path of least resistance.

> Is it because there's no formal policy about where Mozilla's bugs go, or

I think it's more that there was an sort of assumed and therefore
unwritten policy about where Mozilla code goes, but it was unwritten and
therefore as we expanded, didn't get followed. And the bugs have
followed the code.

> I don't have answers to those questions, but I sure hope they're on
> somebody's radar, because you've got a real, systemic issue here that is
> right-now-today actively fragmenting Mozilla's most important repository
> of self-knowledge. And that's happening at the same time that the
> organization is growing like mad.

It's sort of on the radar. But what's the fix? The "don't use github"
horse has left the stable, left the village, and recently crossed the
state line still going at a furious clip. Moving everything to github
would be an enormous project and we'd be taking on some big risks. So
what do we do?

Gerv
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Robert Kaiser
In reply to this post by glob
Mike Hoye schrieb:
> Why are they all over there? I mean, git, sure. Git's awesome. But why
> is all the issue tracking stuff over there too?

That's something that bothers me as well (along with all the review
comments and stuff being only there and not in Bugzilla, btw - for even
more than the projects you listed), esp. given that 1) GitHub is outside
of our control and can in theory be shut down due to forces we can't
control, taking all that info down with it and 2) AFAIK GitHub is a
proprietary, commercial toolset and entity, and I don't think it's good
in terms of the Mozilla mission and Manifesto to depend on such a
service this way and host vital project management (issue tracking) and
history there.

Robert Kaiser
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Mike Hoye-2
In reply to this post by Gervase Markham
On 12-04-11 10:42 AM, Gervase Markham wrote:

> On 10/04/12 18:44, Mike Hoye wrote:
>> Is it because there's no formal policy about where Mozilla's bugs go, or
>
> I think it's more that there was an sort of assumed and therefore
> unwritten policy about where Mozilla code goes, but it was unwritten and
> therefore as we expanded, didn't get followed. And the bugs have
> followed the code.
>
>> I don't have answers to those questions, but I sure hope they're on
>> somebody's radar, because you've got a real, systemic issue here that is
>> right-now-today actively fragmenting Mozilla's most important repository
>> of self-knowledge. And that's happening at the same time that the
>> organization is growing like mad.
>
> It's sort of on the radar. But what's the fix?

I think you've answered your own question there, but if you've
discounted a policy championed by somebody near the top level of the
organization, I don't see another answer. And my experience is that this
type of fragmentation only gets worse. It never gets better.

Maybe I'm wrong? Maybe this is all no big deal, somebody can gin up a
few import/exports scripts that hook into GitHub or whatever the next
CMS coming down the pipe is and tie it all together, and everyone can
fork their own bugzilla front end and it will all be fine.

But I don't think so. And the cost a policy that consolidates Mozilla's
issue tracking and the cost of making Bugzilla more user-accessible this
year will be a vanishing fraction of what it costs to do all that plus
(inevitably) consolidating a fractured development process and community
in 2017.


--
Michael Hoye
Bespoke I/O
http://bespokeio.com


_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

i@paulbooker.co.uk
In reply to this post by Gervase Markham
On 11/04/2012 15:42, Gervase Markham wrote:

> On 10/04/12 18:44, Mike Hoye wrote:
>> I've received this via email from a few other people as well. I've read
>> it a few times now, and I'm trying to figure out if there's a more
>> charitable way to interpret it than "If you don't like the bugzilla
>> interface, write your own.
>
> That's basically what it is. Several people have. :-) We can't make
> the UI all things to all people - that's why I wrote BzAPI. That
> doesn't mean it can't be improved, but it does mean that the quickest
> route to happiness for any one particular group may be to write their
> own tool.
>
>> Patches accepted maybe, but probably not."
>
> If it's just an alternative template view for a bug, I don't see any
> reason the patch wouldn't be accepted.
>
>> Why are they all over there? I mean, git, sure. Git's awesome. But why
>> is all the issue tracking stuff over there too?
>
> Integration, I suspect. Path of least resistance.
>

Totally agree (and with previous comments). I think Mozilla should have
a conversation with the
community about how we currently use social services and if we could do
better. Personally I
think we should try to have all our services running on our own servers.


>> Is it because there's no formal policy about where Mozilla's bugs go, or
>
> I think it's more that there was an sort of assumed and therefore
> unwritten policy about where Mozilla code goes, but it was unwritten
> and therefore as we expanded, didn't get followed. And the bugs have
> followed the code.
>
>> I don't have answers to those questions, but I sure hope they're on
>> somebody's radar, because you've got a real, systemic issue here that is
>> right-now-today actively fragmenting Mozilla's most important repository
>> of self-knowledge. And that's happening at the same time that the
>> organization is growing like mad.
>
> It's sort of on the radar. But what's the fix? The "don't use github"
> horse has left the stable, left the village, and recently crossed the
> state line still going at a furious clip. Moving everything to github
> would be an enormous project and we'd be taking on some big risks. So
> what do we do?

:)  I think all we can do is have our own Git server, educate the
community on the issues involved and leave it in the communities hands
>
> Gerv
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning


--
[+] Paul Booker - MCS | Mozilla UK Community Member - Drupal Developer | Systems administrator
[+] WebFWD Scout
[+] T: @paulbooker

_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12345