Why are we using github's issue tracker instead of Bugzilla?

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

Why are we using github's issue tracker instead of Bugzilla?

Dave Townsend
More and more Mozilla projects are using github to host their source
code. That's a choice that has arguable benefits and drawbacks, but I
explicitly don't want to touch on that. What is worrying to me is that
many of these projects are also using github's issue tracker for bug
tracking.

Again this is a choice that the project in question has to make so on
the one hand I'd like to just let them make their choice freely, on the
other hand I'm finding the issue tracking there quite deficient compared
to what I expect and I know other developers are too so I think it's
worth questioning. This is speaking as someone who has used bugzilla for
a long time and only used github's issues for a short time of course so
feel free to point out what I'm missing.

I can see a couple of reasons for using github's issue tracking:

* It is simplistic and probably easier for new users to file bugs as
there is hardly any fields to figure out and no components etc.
* It has some decent github integration (though with github's hooks
bugzilla has a decent amount of integration too).
* It's easy for the project admins to create and administer, compared to
bugzilla where you have to get the bugzilla admin's to set things up.

And that's about all I can think of, hopefully others can add more. The
downsides from my perspective:

* I can't figure out where to file stuff. Even worse than having to find
the right product/component, I now have to find the right issue tracker
in the first place.
* It's a very simplistic bug tracker, no file attachments (so no
sensible way to do screenshots f.e.), no explicit dependencies that I
can see, all sorts of features are missing.
* We have no way to improve github to meet our own needs.
* All the data is in github's hands and I believe in a closed source
tool. Presumably we could write scripts to pull it out of their APIs but
right now it's on their servers under their control. Are we confident
that if github suddenly died we'd be able to pull the issues and put
them somewhere new?

One might argue that bugzilla is overkill for some projects. What
concerns me is that moving bug trackers is hard, and if these projects
reach the point where we are shipping them to millions of users (I'm
thinking of pdf.js and browser ID here) I think we're going to want the
level of bug tracking that bugzilla gives, and moving sooner rather than
later is going to be easier.

I guess what I'm asking here is what are the compelling reasons for
using github's tracker in favour of bugzilla that I'm not seeing,
because right now it doesn't seem like a big benefit to me.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Why are we using github's issue tracker instead of Bugzilla?

Mike Ratcliffe-3
We use Github for the Developer Tools Command Line code. The reason that we do this is that the code is shared between Firefox and a bunch of non-mozilla projects. We have a script that we run to create a Mozilla specific implementation. Bugzilla is used for bugs in the version embedded into Firefox.

We are also porting Firebug's Network Monitor as a built in developer tool. This means that the code is shared between Firefox and Firebug. Because Firebug is a Github based project with lots of contributors we decided to also use Github for the Network Monitor repo so that the Firebug guys can contribute.

Firebug Network Monitor issues are logged under Google Code and Firefox Network Monitor issues are logged under Bugzilla.

On Thursday, 16 August 2012 07:19:10 UTC+1, Dave Townsend  wrote:

> More and more Mozilla projects are using github to host their source
>
> code. That's a choice that has arguable benefits and drawbacks, but I
>
> explicitly don't want to touch on that. What is worrying to me is that
>
> many of these projects are also using github's issue tracker for bug
>
> tracking.
>
>
>
> Again this is a choice that the project in question has to make so on
>
> the one hand I'd like to just let them make their choice freely, on the
>
> other hand I'm finding the issue tracking there quite deficient compared
>
> to what I expect and I know other developers are too so I think it's
>
> worth questioning. This is speaking as someone who has used bugzilla for
>
> a long time and only used github's issues for a short time of course so
>
> feel free to point out what I'm missing.
>
>
>
> I can see a couple of reasons for using github's issue tracking:
>
>
>
> * It is simplistic and probably easier for new users to file bugs as
>
> there is hardly any fields to figure out and no components etc.
>
> * It has some decent github integration (though with github's hooks
>
> bugzilla has a decent amount of integration too).
>
> * It's easy for the project admins to create and administer, compared to
>
> bugzilla where you have to get the bugzilla admin's to set things up.
>
>
>
> And that's about all I can think of, hopefully others can add more. The
>
> downsides from my perspective:
>
>
>
> * I can't figure out where to file stuff. Even worse than having to find
>
> the right product/component, I now have to find the right issue tracker
>
> in the first place.
>
> * It's a very simplistic bug tracker, no file attachments (so no
>
> sensible way to do screenshots f.e.), no explicit dependencies that I
>
> can see, all sorts of features are missing.
>
> * We have no way to improve github to meet our own needs.
>
> * All the data is in github's hands and I believe in a closed source
>
> tool. Presumably we could write scripts to pull it out of their APIs but
>
> right now it's on their servers under their control. Are we confident
>
> that if github suddenly died we'd be able to pull the issues and put
>
> them somewhere new?
>
>
>
> One might argue that bugzilla is overkill for some projects. What
>
> concerns me is that moving bug trackers is hard, and if these projects
>
> reach the point where we are shipping them to millions of users (I'm
>
> thinking of pdf.js and browser ID here) I think we're going to want the
>
> level of bug tracking that bugzilla gives, and moving sooner rather than
>
> later is going to be easier.
>
>
>
> I guess what I'm asking here is what are the compelling reasons for
>
> using github's tracker in favour of bugzilla that I'm not seeing,
>
> because right now it doesn't seem like a big benefit to me.

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

Re: Why are we using github's issue tracker instead of Bugzilla?

Justin Lebar-3
I enjoy using the github bug tracker, myself.

* It is much faster than Bugzilla on average.
* It is much faster than Bugzilla at the 95th percentile -- that is,
there are many fewer days in my experience when Github is performing
badly than when Bugzilla is performing badly.
* Its internal search is usable (and very fast).  Searching Bugzilla
with Google works, but often does not find newly-filed bugs.
* Code review is built in and works much better than in Bugzilla, in
my experience.  (*)
* Its autocompletion of usernames (e.g. for cc'ing someone) is fast
and pleasant to use.
* No mid-air collisions.
* New comments show up without refreshing the page.

In general, github feels like a modern web application, while Bugzilla does not.

I don't disagree with the downsides you listed, save one:

> * We have no way to improve github to meet our own needs.

In my view, the user experience of github is already vastly superior
to the experience of Bugzilla, even if Bugzilla is in some ways more
powerful than github.  (I see the lack of attachments as a real
problem, while the relative simplicity of github's metadata doesn't
bother me much.)  So in one important sense, the fact that we can
modify Bugzilla doesn't mean we get a superior experience.

I think github bug tracking (and github in general) has served us well in B2G.

-Justin

(*) In case it's not clear: Of course you could use pull requests and
keep your bugs in Bugzilla.  But then Bugzilla would be missing the
review comments, which are a pretty important part of the bug!

On Thu, Aug 16, 2012 at 5:40 AM, Mike Ratcliffe <[hidden email]> wrote:

> We use Github for the Developer Tools Command Line code. The reason that we do this is that the code is shared between Firefox and a bunch of non-mozilla projects. We have a script that we run to create a Mozilla specific implementation. Bugzilla is used for bugs in the version embedded into Firefox.
>
> We are also porting Firebug's Network Monitor as a built in developer tool. This means that the code is shared between Firefox and Firebug. Because Firebug is a Github based project with lots of contributors we decided to also use Github for the Network Monitor repo so that the Firebug guys can contribute.
>
> Firebug Network Monitor issues are logged under Google Code and Firefox Network Monitor issues are logged under Bugzilla.
>
> On Thursday, 16 August 2012 07:19:10 UTC+1, Dave Townsend  wrote:
>> More and more Mozilla projects are using github to host their source
>>
>> code. That's a choice that has arguable benefits and drawbacks, but I
>>
>> explicitly don't want to touch on that. What is worrying to me is that
>>
>> many of these projects are also using github's issue tracker for bug
>>
>> tracking.
>>
>>
>>
>> Again this is a choice that the project in question has to make so on
>>
>> the one hand I'd like to just let them make their choice freely, on the
>>
>> other hand I'm finding the issue tracking there quite deficient compared
>>
>> to what I expect and I know other developers are too so I think it's
>>
>> worth questioning. This is speaking as someone who has used bugzilla for
>>
>> a long time and only used github's issues for a short time of course so
>>
>> feel free to point out what I'm missing.
>>
>>
>>
>> I can see a couple of reasons for using github's issue tracking:
>>
>>
>>
>> * It is simplistic and probably easier for new users to file bugs as
>>
>> there is hardly any fields to figure out and no components etc.
>>
>> * It has some decent github integration (though with github's hooks
>>
>> bugzilla has a decent amount of integration too).
>>
>> * It's easy for the project admins to create and administer, compared to
>>
>> bugzilla where you have to get the bugzilla admin's to set things up.
>>
>>
>>
>> And that's about all I can think of, hopefully others can add more. The
>>
>> downsides from my perspective:
>>
>>
>>
>> * I can't figure out where to file stuff. Even worse than having to find
>>
>> the right product/component, I now have to find the right issue tracker
>>
>> in the first place.
>>
>> * It's a very simplistic bug tracker, no file attachments (so no
>>
>> sensible way to do screenshots f.e.), no explicit dependencies that I
>>
>> can see, all sorts of features are missing.
>>
>> * We have no way to improve github to meet our own needs.
>>
>> * All the data is in github's hands and I believe in a closed source
>>
>> tool. Presumably we could write scripts to pull it out of their APIs but
>>
>> right now it's on their servers under their control. Are we confident
>>
>> that if github suddenly died we'd be able to pull the issues and put
>>
>> them somewhere new?
>>
>>
>>
>> One might argue that bugzilla is overkill for some projects. What
>>
>> concerns me is that moving bug trackers is hard, and if these projects
>>
>> reach the point where we are shipping them to millions of users (I'm
>>
>> thinking of pdf.js and browser ID here) I think we're going to want the
>>
>> level of bug tracking that bugzilla gives, and moving sooner rather than
>>
>> later is going to be easier.
>>
>>
>>
>> I guess what I'm asking here is what are the compelling reasons for
>>
>> using github's tracker in favour of bugzilla that I'm not seeing,
>>
>> because right now it doesn't seem like a big benefit to me.
>
> _______________________________________________
> 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: Why are we using github's issue tracker instead of Bugzilla?

Hanno Schlichting-5
In reply to this post by Dave Townsend
On 16.08.2012, at 08:19 , Dave Townsend <[hidden email]> wrote:
> More and more Mozilla projects are using github to host their source code. That's a choice that has arguable benefits and drawbacks, but I explicitly don't want to touch on that. What is worrying to me is that many of these projects are also using github's issue tracker for bug tracking.
> [...]
> I guess what I'm asking here is what are the compelling reasons for using github's tracker in favour of bugzilla that I'm not seeing, because right now it doesn't seem like a big benefit to me.

At least for some projects it's unclear whether or not they are "Mozilla projects". Just to give some examples:

We operate and use MySQL. Bugs relating to MoCo's use of MySQL will end up in bugzilla. But bugs about MySQL itself will likely be reported "upstream".

We integrated WebRTC code shared by Chrome. Would you expect all Chrome developers to use bugzilla? Or is bugzilla the place to put bugs about specific implementation / integration issues with Firefox and does the WebRTC project have a "neutral" place independent of either Chrome and Firefox.

There's other examples where projects started outside Mozilla, then some or all of their contributors became Mozillians. Some of these contributors might have moved on again and aren't working for MoCo anymore, for some that might also end the Mozilla community involvement. Some projects might have gotten non-Mozillian contributors.

On the services team we created a bunch of projects, most of them written in the Python language. We frequently use tools and services familiar to Python developers for these, like github, readthedocs.org or travis-ci.org. We do that as the most likely source of new contributors is from the Python community and this has turned out to work well for a number of these projects. As soon as these tools are actually used by MoCo, bugs and issues about that usage are tracked in bugzilla.

To me bugzilla is the place for anything that's used and operated by MoCo and key projects like Gecko/Firefox.

But there's a lot of projects where the contributor base or audience is not primarily Mozillians. I think each project should use the tools that best serve their contributors and intended audience. There's a lot of grey area in between a "Mozilla project" and an independent open source project.

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

Re: Why are we using github's issue tracker instead of Bugzilla?

Mike Hoye-2
In reply to this post by Justin Lebar-3
On Thu, Aug 16, 2012 at 8:26 AM, Justin Lebar <[hidden email]>wrote:

> I enjoy using the github bug tracker, myself.
>

If Github goes away, all that history goes away. That may be an acceptable
risk and it may not, but it seems like it should an explicit decision that.
either per-project or as an institution, Mozilla can live with.

Github has much to recommend it - having your issue tracking and your pull
requests right there in the same place is pretty great even if it is all
proprietary - and lots of people are moving over there.

While I share Dave's opinion that they don't seem _that_ huge, I suspect
that many of the advantages of Github have been exacerbated by the culture
around Bugzilla being extremely resistant to change. The long-running joke
I was unaware of when I mentioned this a while back was that a "we need to
fix bugzilla" thread is a biannual ceremony at Mozilla, but in the absence
of a project with a budget and an owner, and no better alternatives, not
much progress there has been made. Now there's Github, though, and it's
as-in-beer free, and it sure does look better than Bugzilla. And all the
new stuff seems to be happening over there, and as far as I can tell,
whenever people have a chance to start fresh and pick their workflows and
toolchains, they're just not picking Bugzilla.

I've been told informally that as projects become more important to Mozilla
they're eventually brought fully in-house; that may have been the case in
the past, but that's not the trend I'm seeing right now. And if B2G is
staying over there, well.

Hanno has a strong point, when he says that "bugzilla is the place for
anything that used and operated by MoCo and key projects like
Gecko/Firefox", and that it's probably OK if other stuff is in other
places, but Bugzilla is also very likely to be the the first place people
to file bugs against anything they see in a Mozilla-involved product, so
the more projects move away from Bugzilla, the more likely it is that bugs
filed in Bugzilla will be in the wrong place.

So right now, there are big disconnects between:

- where new contributors go to file bugs, and where those projects are
actually getting developed,
- what Mozilla employees and the larger community want in an issue tracking
system and what Mozilla is actually investing in, and in the larger sense
- how Mozilla-the-institution values their history, and where that data
actually lives.

Or, to put it differently: Mozilla goes fast now, and Bugzilla doesn't.

It doesn't need to be tossed in the bin or rewritten from scratch or
anything crazy like that, but man. It's Mozilla's internal historical and
cultural record, and Bugzilla could really use a bit of policy and a lot of
love.

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

Re: Why are we using github's issue tracker instead of Bugzilla?

Reed Loden
On Thu, 16 Aug 2012 11:19:57 -0400
Mike Hoye <[hidden email]> wrote:

> While I share Dave's opinion that they don't seem _that_ huge, I suspect
> that many of the advantages of Github have been exacerbated by the culture
> around Bugzilla being extremely resistant to change. The long-running joke
> I was unaware of when I mentioned this a while back was that a "we need to
> fix bugzilla" thread is a biannual ceremony at Mozilla, but in the absence
> of a project with a budget and an owner, and no better alternatives, not
> much progress there has been made. Now there's Github, though, and it's
> as-in-beer free, and it sure does look better than Bugzilla. And all the
> new stuff seems to be happening over there, and as far as I can tell,
> whenever people have a chance to start fresh and pick their workflows and
> toolchains, they're just not picking Bugzilla.

Your information is greatly outdated. Mozilla's Bugzilla has had two
full-time developers (dkl and glob) for at least a year and a half, and
they have been able to do a lot of work to fix some of the long-standing
issues, as well as innovate on new features and many MoCo-specific
customizations. They stay constantly busy, so just because you may not
think Bugzilla is getting any love, it most definitely is.

Check out https://bzr.mozilla.org/bmo/4.0/changes to see all the
work that has been done. Also, perhaps you should stop by #bteam some
time to say hi. :)

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

Re: Why are we using github's issue tracker instead of Bugzilla?

Dave Townsend
In reply to this post by Mike Ratcliffe-3
On 08/16/12 05:26, Justin Lebar wrote:

>> * We have no way to improve github to meet our own needs.
>
> In my view, the user experience of github is already vastly superior
> to the experience of Bugzilla, even if Bugzilla is in some ways more
> powerful than github.  (I see the lack of attachments as a real
> problem, while the relative simplicity of github's metadata doesn't
> bother me much.)  So in one important sense, the fact that we can
> modify Bugzilla doesn't mean we get a superior experience.
>
> I think github bug tracking (and github in general) has served us well in B2G.

B2G is a project that we hope to be a big thing shipping on multiple
devices. Right now you're in development and I'm sure github's tracker
is just fine. But once it is released the issue tracking requirements
change and I don't know how well handling release management through
github will work. That we've been able to make custom changes to
bugzilla to improve this side of things has helped the release managers
for Firefox a lot.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Why are we using github's issue tracker instead of Bugzilla?

Justin Dolske-2
In reply to this post by Mike Hoye-2
On 8/16/12 9:38 AM, Reed Loden wrote:

>> While I share Dave's opinion that they don't seem _that_ huge, I suspect
>> that many of the advantages of Github have been exacerbated by the culture
>> around Bugzilla being extremely resistant to change.
>
> Your information is greatly outdated. Mozilla's Bugzilla has had two
> full-time developers (dkl and glob) for at least a year and a half, and
> they have been able to do a lot of work to fix some of the long-standing
> issues, as well as innovate on new features and many MoCo-specific
> customizations. They stay constantly busy, so just because you may not
> think Bugzilla is getting any love, it most definitely is.

It's true. It was a real problem in the past (and there's a backlog of
"technical debt to pay off), but I've been consistently pleased at how
responsive glob/dkl have been. It really is an amazing turnaround from
the state of things a year or so ago.

If you've previously given up on making Bugzilla better, I'd encourage
you to give it another shot (filing bugs/suggestions, and maybe even
patches!).

If there's a silver lining here, it's that we've got a good opportunity
to look at things that work well in another bug-tracking system, and see
how we can evolve Bugzilla to match it.

Justin

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

Re: Why are we using github's issue tracker instead of Bugzilla?

davidascher
... just a designer-led reskin would be awesome.
On Aug 16, 2012 12:05 PM, "Justin Dolske" <[hidden email]> wrote:

> On 8/16/12 9:38 AM, Reed Loden wrote:
>
>  While I share Dave's opinion that they don't seem _that_ huge, I suspect
>>> that many of the advantages of Github have been exacerbated by the
>>> culture
>>> around Bugzilla being extremely resistant to change.
>>>
>>
>> Your information is greatly outdated. Mozilla's Bugzilla has had two
>> full-time developers (dkl and glob) for at least a year and a half, and
>> they have been able to do a lot of work to fix some of the long-standing
>> issues, as well as innovate on new features and many MoCo-specific
>> customizations. They stay constantly busy, so just because you may not
>> think Bugzilla is getting any love, it most definitely is.
>>
>
> It's true. It was a real problem in the past (and there's a backlog of
> "technical debt to pay off), but I've been consistently pleased at how
> responsive glob/dkl have been. It really is an amazing turnaround from the
> state of things a year or so ago.
>
> If you've previously given up on making Bugzilla better, I'd encourage you
> to give it another shot (filing bugs/suggestions, and maybe even patches!).
>
> If there's a silver lining here, it's that we've got a good opportunity to
> look at things that work well in another bug-tracking system, and see how
> we can evolve Bugzilla to match it.
>
> Justin
>
> ______________________________**_________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/**listinfo/dev-planning<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: Why are we using github's issue tracker instead of Bugzilla?

Dave Lawrence
Funny you should say that. Couple of our interns have been addressing
this issue in their spare time to help us (BMO team) out in that regard.
One of the prototypes being passed around actually looks quite
promising. I hope that we can continue to utilize them and gets some
real progress on this before their time is up. For a peak at one idea,
look at:

https://dl.dropbox.com/u/28610/bugzilla-sandstone/showbug.html

dkl

On 08/16/2012 03:12 PM, David Ascher wrote:

> ... just a designer-led reskin would be awesome.
> On Aug 16, 2012 12:05 PM, "Justin Dolske" <[hidden email]> wrote:
>
>> On 8/16/12 9:38 AM, Reed Loden wrote:
>>
>>  While I share Dave's opinion that they don't seem _that_ huge, I suspect
>>>> that many of the advantages of Github have been exacerbated by the
>>>> culture
>>>> around Bugzilla being extremely resistant to change.
>>>>
>>>
>>> Your information is greatly outdated. Mozilla's Bugzilla has had two
>>> full-time developers (dkl and glob) for at least a year and a half, and
>>> they have been able to do a lot of work to fix some of the long-standing
>>> issues, as well as innovate on new features and many MoCo-specific
>>> customizations. They stay constantly busy, so just because you may not
>>> think Bugzilla is getting any love, it most definitely is.
>>>
>>
>> It's true. It was a real problem in the past (and there's a backlog of
>> "technical debt to pay off), but I've been consistently pleased at how
>> responsive glob/dkl have been. It really is an amazing turnaround from the
>> state of things a year or so ago.
>>
>> If you've previously given up on making Bugzilla better, I'd encourage you
>> to give it another shot (filing bugs/suggestions, and maybe even patches!).
>>
>> If there's a silver lining here, it's that we've got a good opportunity to
>> look at things that work well in another bug-tracking system, and see how
>> we can evolve Bugzilla to match it.
>>
>> Justin
>>
>> ______________________________**_________________
>> dev-planning mailing list
>> [hidden email]
>> https://lists.mozilla.org/**listinfo/dev-planning<https://lists.mozilla.org/listinfo/dev-planning>
>>
> _______________________________________________
> dev-planning mailing list
> [hidden email]
> https://lists.mozilla.org/listinfo/dev-planning
>

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

Re: Why are we using github's issue tracker instead of Bugzilla?

Jonathan Protzenko
We had the bugzilla redesign discussion several times already,
including
http://bugzillaupdate.wordpress.com/2011/03/31/winner-of-the-make-bugzilla-pretty-contest/ 
that never translated into anything concrete, as far as I can tell on
bugzilla.mozilla.org (but I'd love to be proved wrong :-) !).

David, do you have any insights as to why we went through the whole
process of creating yet another new theme while there was one that
seemingly made consensus in March, 2011?

Cheers,

jonathan

On Thu Aug 16 20:19:27 2012, David Lawrence wrote:

> Funny you should say that. Couple of our interns have been addressing
> this issue in their spare time to help us (BMO team) out in that regard.
> One of the prototypes being passed around actually looks quite
> promising. I hope that we can continue to utilize them and gets some
> real progress on this before their time is up. For a peak at one idea,
> look at:
>
> https://dl.dropbox.com/u/28610/bugzilla-sandstone/showbug.html
>
> dkl
>
> On 08/16/2012 03:12 PM, David Ascher wrote:
>> ... just a designer-led reskin would be awesome.
>> On Aug 16, 2012 12:05 PM, "Justin Dolske" <[hidden email]> wrote:
>>
>>> On 8/16/12 9:38 AM, Reed Loden wrote:
>>>
>>>   While I share Dave's opinion that they don't seem _that_ huge, I suspect
>>>>> that many of the advantages of Github have been exacerbated by the
>>>>> culture
>>>>> around Bugzilla being extremely resistant to change.
>>>>>
>>>>
>>>> Your information is greatly outdated. Mozilla's Bugzilla has had two
>>>> full-time developers (dkl and glob) for at least a year and a half, and
>>>> they have been able to do a lot of work to fix some of the long-standing
>>>> issues, as well as innovate on new features and many MoCo-specific
>>>> customizations. They stay constantly busy, so just because you may not
>>>> think Bugzilla is getting any love, it most definitely is.
>>>>
>>>
>>> It's true. It was a real problem in the past (and there's a backlog of
>>> "technical debt to pay off), but I've been consistently pleased at how
>>> responsive glob/dkl have been. It really is an amazing turnaround from the
>>> state of things a year or so ago.
>>>
>>> If you've previously given up on making Bugzilla better, I'd encourage you
>>> to give it another shot (filing bugs/suggestions, and maybe even patches!).
>>>
>>> If there's a silver lining here, it's that we've got a good opportunity to
>>> look at things that work well in another bug-tracking system, and see how
>>> we can evolve Bugzilla to match it.
>>>
>>> Justin
>>>
>>> ______________________________**_________________
>>> dev-planning mailing list
>>> [hidden email]
>>> https://lists.mozilla.org/**listinfo/dev-planning<https://lists.mozilla.org/listinfo/dev-planning>
>>>
>> _______________________________________________
>> 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: Why are we using github's issue tracker instead of Bugzilla?

Dave Mandelin-2
In reply to this post by Dave Townsend
On Wednesday, August 15, 2012 11:19:10 PM UTC-7, Dave Townsend wrote:
> More and more Mozilla projects are using github to host their source
> code. That's a choice that has arguable benefits and drawbacks, but I
> explicitly don't want to touch on that. What is worrying to me is that
> many of these projects are also using github's issue tracker for bug
> tracking.

I also think that an uncoordinated dispersion to various bug trackers is risky, for all the reasons you mention.

> * I can't figure out where to file stuff. Even worse than having to find
> the right product/component, I now have to find the right issue tracker
> in the first place.

I suppose that could be solved by creating a page that links to the right bug tracker for each project. It's already kind of hard to find the right product and component in Bugzilla, so that wouldn't be much worse. ;-)

> * It's a very simplistic bug tracker, no file attachments (so no
> sensible way to do screenshots f.e.), no explicit dependencies that I
> can see, all sorts of features are missing.
> * We have no way to improve github to meet our own needs.

Those two are *probably* not such a big risk, because the github users are apparently already quite happy with it. But there is some chance they will discover they need more later on, like with release tracking flags.

> * All the data is in github's hands and I believe in a closed source
> tool. Presumably we could write scripts to pull it out of their APIs but
> right now it's on their servers under their control. Are we confident
> that if github suddenly died we'd be able to pull the issues and put
> them somewhere new?

No way to quantify this, but it seems like low-probability event but one with fairly dire consequences. I'm not aware of anything that mitigates it.

> I guess what I'm asking here is what are the compelling reasons for
> using github's tracker in favour of bugzilla that I'm not seeing,
> because right now it doesn't seem like a big benefit to me.

I think that's a very good question, and I haven't seen an answer yet that offers a *compelling* reason. (I do think it's reasonable to put projects that are shared or are otherwise not solely Mozilla in another place.)

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

Re: Why are we using github's issue tracker instead of Bugzilla?

Dave Lawrence
In reply to this post by Jonathan Protzenko
Jonathan Wilde, the winner of the "Make Bugzilla Pretty", contest is
actually one of the interns and is working with Christoper Lee on the
new design over the summer. So we are utilize Jonathan's work as part of
this effort as well.

dkl

On 08/16/2012 04:43 PM, Jonathan Protzenko wrote:

> We had the bugzilla redesign discussion several times already, including
> http://bugzillaupdate.wordpress.com/2011/03/31/winner-of-the-make-bugzilla-pretty-contest/
> that never translated into anything concrete, as far as I can tell on
> bugzilla.mozilla.org (but I'd love to be proved wrong :-) !).
>
> David, do you have any insights as to why we went through the whole
> process of creating yet another new theme while there was one that
> seemingly made consensus in March, 2011?
>
> Cheers,
>
> jonathan
>
> On Thu Aug 16 20:19:27 2012, David Lawrence wrote:
>> Funny you should say that. Couple of our interns have been addressing
>> this issue in their spare time to help us (BMO team) out in that regard.
>> One of the prototypes being passed around actually looks quite
>> promising. I hope that we can continue to utilize them and gets some
>> real progress on this before their time is up. For a peak at one idea,
>> look at:
>>
>> https://dl.dropbox.com/u/28610/bugzilla-sandstone/showbug.html
>>
>> dkl
>>
>> On 08/16/2012 03:12 PM, David Ascher wrote:
>>> ... just a designer-led reskin would be awesome.
>>> On Aug 16, 2012 12:05 PM, "Justin Dolske" <[hidden email]> wrote:
>>>
>>>> On 8/16/12 9:38 AM, Reed Loden wrote:
>>>>
>>>>   While I share Dave's opinion that they don't seem _that_ huge, I
>>>> suspect
>>>>>> that many of the advantages of Github have been exacerbated by the
>>>>>> culture
>>>>>> around Bugzilla being extremely resistant to change.
>>>>>>
>>>>>
>>>>> Your information is greatly outdated. Mozilla's Bugzilla has had two
>>>>> full-time developers (dkl and glob) for at least a year and a half,
>>>>> and
>>>>> they have been able to do a lot of work to fix some of the
>>>>> long-standing
>>>>> issues, as well as innovate on new features and many MoCo-specific
>>>>> customizations. They stay constantly busy, so just because you may not
>>>>> think Bugzilla is getting any love, it most definitely is.
>>>>>
>>>>
>>>> It's true. It was a real problem in the past (and there's a backlog of
>>>> "technical debt to pay off), but I've been consistently pleased at how
>>>> responsive glob/dkl have been. It really is an amazing turnaround
>>>> from the
>>>> state of things a year or so ago.
>>>>
>>>> If you've previously given up on making Bugzilla better, I'd
>>>> encourage you
>>>> to give it another shot (filing bugs/suggestions, and maybe even
>>>> patches!).
>>>>
>>>> If there's a silver lining here, it's that we've got a good
>>>> opportunity to
>>>> look at things that work well in another bug-tracking system, and
>>>> see how
>>>> we can evolve Bugzilla to match it.
>>>>
>>>> Justin
>>>>
>>>> ______________________________**_________________
>>>> dev-planning mailing list
>>>> [hidden email]
>>>> https://lists.mozilla.org/**listinfo/dev-planning<https://lists.mozilla.org/listinfo/dev-planning>
>>>>
>>>>
>>> _______________________________________________
>>> dev-planning mailing list
>>> [hidden email]
>>> https://lists.mozilla.org/listinfo/dev-planning
>>>
>>

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

Re: Why are we using github's issue tracker instead of Bugzilla?

Dave Mandelin-2
In reply to this post by Mike Ratcliffe-3
On Thursday, August 16, 2012 5:26:50 AM UTC-7, Justin Lebar wrote:

> I enjoy using the github bug tracker, myself.
>
>
>
> * It is much faster than Bugzilla on average.
>
> * It is much faster than Bugzilla at the 95th percentile -- that is,
> there are many fewer days in my experience when Github is performing
> badly than when Bugzilla is performing badly.
>
> * Its internal search is usable (and very fast).  Searching Bugzilla
> with Google works, but often does not find newly-filed bugs.
>
> * Code review is built in and works much better than in Bugzilla, in
> my experience.  (*)
>
> * Its autocompletion of usernames (e.g. for cc'ing someone) is fast
> and pleasant to use.
>
> * No mid-air collisions.
>
> * New comments show up without refreshing the page.
>
> In general, github feels like a modern web application, while Bugzilla does not.
>
> I don't disagree with the downsides you listed, save one:
>
> > * We have no way to improve github to meet our own needs.
>
> In my view, the user experience of github is already vastly superior
> to the experience of Bugzilla, even if Bugzilla is in some ways more
> powerful than github.  (I see the lack of attachments as a real
> problem, while the relative simplicity of github's metadata doesn't
> bother me much.)  So in one important sense, the fact that we can
> modify Bugzilla doesn't mean we get a superior experience.

Interesting. And despite all the good work on Bugzilla recently, I think this point stands. Bugzilla has a lot of technical debt (I hear) and a long, long way to go to reach any kind of non-archaic status. I don't see Bugzilla as being on track to catch up.

> I think github bug tracking (and github in general) has served us well in B2G.

Could you elaborate? Do you mean that it's made the project more productive? Would you argue that the productivity boost (or other benefits) are enough to outweigh the risks?

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

Re: Why are we using github's issue tracker instead of Bugzilla?

Justin Lebar-3
>> I think github bug tracking (and github in general) has served us well in B2G.
>
> Could you elaborate? Do you mean that it's made the project more
> productive?

It's hard to quantify the productivity change, if any.  Qualitatively,
having pages load quickly matters more than one might think.  Also, I
think pull requests are a much better/faster review + landing workflow
than posting patches, both for the reviewer and the author.

There's also a "happiness factor" associated with using pretty,
functional, and fast software.  I claim this has a non-negligible
effect: Consider how your overall efficiency on the Web would be
affected if you had to use a hypothetical search engine which was
functionally as good as Google, but took two two five seconds to
return a search result, was ugly, and occasionally silently cleared
the to: field on an e-mail you were writing (*).

(*) I hear they've recently fixed this, mostly or entirely.  :)

In my view, the biggest efficiency gain in B2G probably comes from
using git.  We have 80+ git subrepositories in B2G, and, arguments
about which DVCS is better aside, managing this mess would be much
more difficult if we tried to pull it all into hg somehow.

Collaboration is also a lot easier with git: It's a lot easier to pull
from someone's git fork than it is to import their hg patch queue and
keep it up to date as the person modifies their queue.  I've been
doing this more and more now that I know more people using git for
Gecko development.

But of course we could use git (even hosted at github) plus bugzilla
as a bug tracker.

That said, you should probably get the opinion of someone who uses
github more often than I do -- the majority of my work is down in
Gecko, which we track in Bugzilla.

> Would you argue that the productivity boost (or other benefits) are enough to
> outweigh the risks?

It's hard to weigh immediate benefits against low-probability risks;
I'm not sure how I'd go about making a fair assessment here.

One point I'll make, though, is that losing easy access to historical
data isn't the end of the world.  We lost easy access to gecko blame
when we switched to hg, and we've survived.  It would certainly be bad
if github shut down tomorrow, or next year, or in five years, but if
we had to pull our old Gaia issues off github and into a half-working
static archive, I don't think that would be the end of the project.

-Justin

On Thu, Aug 16, 2012 at 4:54 PM, Dave Mandelin <[hidden email]> wrote:

> On Thursday, August 16, 2012 5:26:50 AM UTC-7, Justin Lebar wrote:
>> I enjoy using the github bug tracker, myself.
>>
>>
>>
>> * It is much faster than Bugzilla on average.
>>
>> * It is much faster than Bugzilla at the 95th percentile -- that is,
>> there are many fewer days in my experience when Github is performing
>> badly than when Bugzilla is performing badly.
>>
>> * Its internal search is usable (and very fast).  Searching Bugzilla
>> with Google works, but often does not find newly-filed bugs.
>>
>> * Code review is built in and works much better than in Bugzilla, in
>> my experience.  (*)
>>
>> * Its autocompletion of usernames (e.g. for cc'ing someone) is fast
>> and pleasant to use.
>>
>> * No mid-air collisions.
>>
>> * New comments show up without refreshing the page.
>>
>> In general, github feels like a modern web application, while Bugzilla does not.
>>
>> I don't disagree with the downsides you listed, save one:
>>
>> > * We have no way to improve github to meet our own needs.
>>
>> In my view, the user experience of github is already vastly superior
>> to the experience of Bugzilla, even if Bugzilla is in some ways more
>> powerful than github.  (I see the lack of attachments as a real
>> problem, while the relative simplicity of github's metadata doesn't
>> bother me much.)  So in one important sense, the fact that we can
>> modify Bugzilla doesn't mean we get a superior experience.
>
> Interesting. And despite all the good work on Bugzilla recently, I think this point stands. Bugzilla has a lot of technical debt (I hear) and a long, long way to go to reach any kind of non-archaic status. I don't see Bugzilla as being on track to catch up.
>
>> I think github bug tracking (and github in general) has served us well in B2G.
>
> Could you elaborate? Do you mean that it's made the project more productive? Would you argue that the productivity boost (or other benefits) are enough to outweigh the risks?
>
> Dave
> _______________________________________________
> 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: Why are we using github's issue tracker instead of Bugzilla?

Dave Mandelin-2
In reply to this post by Dave Mandelin-2
On Thursday, August 16, 2012 2:26:06 PM UTC-7, Justin Lebar wrote:

> >> I think github bug tracking (and github in general) has served us well in B2G.
>
> > Could you elaborate? Do you mean that it's made the project more
> > productive?
>
> It's hard to quantify the productivity change, if any.  Qualitatively,
> having pages load quickly matters more than one might think.  Also, I
> think pull requests are a much better/faster review + landing workflow
> than posting patches, both for the reviewer and the author.
>
> There's also a "happiness factor" associated with using pretty,
> functional, and fast software.  I claim this has a non-negligible
> effect: Consider how your overall efficiency on the Web would be
> affected if you had to use a hypothetical search engine which was
> functionally as good as Google, but took two two five seconds to
> return a search result, was ugly, and occasionally silently cleared
> the to: field on an e-mail you were writing (*).

I agree: the happiness factor definitely matters, and affects productivity.

> In my view, the biggest efficiency gain in B2G probably comes from
> using git.  We have 80+ git subrepositories in B2G, and, arguments
> about which DVCS is better aside, managing this mess would be much
> more difficult if we tried to pull it all into hg somehow.
>
> Collaboration is also a lot easier with git: It's a lot easier to pull
> from someone's git fork than it is to import their hg patch queue and
> keep it up to date as the person modifies their queue.  I've been
> doing this more and more now that I know more people using git for
> Gecko development.

So it sounds like you are saying that (github tracker + git) is much
better than (bugzilla + hg). I know we've talked about switching the
repo to git in the past. Maybe it's time to ask that question again?

> But of course we could use git (even hosted at github) plus bugzilla
> as a bug tracker.
>
> That said, you should probably get the opinion of someone who uses
> github more often than I do -- the majority of my work is down in
> Gecko, which we track in Bugzilla.
>
> > Would you argue that the productivity boost (or other benefits) are enough to
> > outweigh the risks?
>
> It's hard to weigh immediate benefits against low-probability risks;
> I'm not sure how I'd go about making a fair assessment here.

It is hard, but also necessary. Picking up nickels in front of a steamroller
would be the canonical bad tradeoff. I think you're saying it's a lot more
than nickels, and there isn't a steamroller.

One way to think about risks is get estimates as clear as you can about
what the probabilities are and the costs and benefits, and then compare.
Another perspective is to compare the risks to risks we are already taking,
and if we assume we're doing sensible stuff now, then new things that
are less risky may be just fine.

> One point I'll make, though, is that losing easy access to historical
> data isn't the end of the world.  We lost easy access to gecko blame
> when we switched to hg, and we've survived.  It would certainly be bad
> if github shut down tomorrow, or next year, or in five years, but if
> we had to pull our old Gaia issues off github and into a half-working
> static archive, I don't think that would be the end of the project.

No, it's definitely not the end of the world, just disruptive. It's
interesting to think about...what would happen if we lost all JS Bugzilla
data today? It's actually hard for me to see that as a catastrophe at all.
It would disrupt current ongoing work (bugs being currently worked on),
we'd lose history, which is occasionally useful to look at but not crucial.
The most important thing is that we'd lose current regressions and
security-sensitive bugs, which could definitely screw up a release.

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

Re: Why are we using github's issue tracker instead of Bugzilla?

Benjamin Smedberg
In reply to this post by Justin Lebar-3
On 8/16/2012 5:26 PM, Justin Lebar wrote:
>>> I think github bug tracking (and github in general) has served us well in B2G.
>> Could you elaborate? Do you mean that it's made the project more
>> productive?
> It's hard to quantify the productivity change, if any.  Qualitatively,
> having pages load quickly matters more than one might think.  Also, I
> think pull requests are a much better/faster review + landing workflow
> than posting patches, both for the reviewer and the author.
I just recently learned git and started using github for socorro and
some other metrics repositories (Mozilla).

In those cases all the changes go through pull requests, which has been
pretty satisfying. So let's for the moment assume that we keep using
github for version control and pull requests. I don't think this
necessarily means that we should use it for issue tracking. We already
get (or can get) notices posted to bugzilla when pull requests are
merged, etc. Socorro seems to use this setup quite effectively.

The really important advantages of bugzilla (from my perspective as a
sometime driver and triager) are:

* unified handling of security issues and security groups
* ability to triage bugs between projects without refiling them and
losing state
* ability to have and query tracking flags across multiple projects

I really think that we should expect any project (except perhaps
research projects) should use bugzilla, and just suck it up in cases
where slowness and uglinessall are painful.

--BDS

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

Re: Why are we using github's issue tracker instead of Bugzilla?

Justin Lebar-3
> In those cases all the changes go through pull requests, which has been
> pretty satisfying. So let's for the moment assume that we keep using github
> for version control and pull requests. I don't think this necessarily means
> that we should use it for issue tracking. We already get (or can get)
> notices posted to bugzilla when pull requests are merged, etc. Socorro seems
> to use this setup quite effectively.

How does Socorro deal with the fact that review comments are in Github
while the rest of the bug comments are in Bugzilla?  That seems worse
than the current Bugzilla workflow, to me.

Or do you only make pull requests for r+'ed patches?  That then loses
a lot of the magic...
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Why are we using github's issue tracker instead of Bugzilla?

Andrew Sutherland-5
In reply to this post by Dave Townsend
On 08/15/2012 11:19 PM, Dave Townsend wrote:
> * It's a very simplistic bug tracker, no file attachments (so no
> sensible way to do screenshots f.e.), no explicit dependencies that I
> can see, all sorts of features are missing.

As an example of limitations being really problematic, the lack of any
history feature for issues in regards to meta-data like labels is very
bad, especially given some arguably questionable UI behaviour about
fancier features.

I just tried to use the "Label" drop-down option from the issue list to
mass-add a label to some issues because of new level of effort labeling
requirements.  I made the (bad) assumption if that I clicked a single
label with multiple issues' checkboxes checked, it would just add that
one label to all the labels.  Based on my observations, clicking just
the label does nothing, you need to click the "update" button at the
bottom of the labels list.  Except that set all the labels on all of the
issues to be the same on all the selected issues, presumably based on
the first bug in the list.

The major problem is that I don't see any way to see the history of
changes to the labels, so I have no idea what the previous state of the
issues was before I screwed them up.  At first glance the issues API
does not provide history information under the hood either, so my
ability to write a script to undo my screw-up is rather limited.

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

Re: Why are we using github's issue tracker instead of Bugzilla?

Joshua Cranmer-2
In reply to this post by Dave Townsend
On 8/16/2012 2:19 AM, Dave Townsend wrote:

> And that's about all I can think of, hopefully others can add more.
> The downsides from my perspective:
>
> * I can't figure out where to file stuff. Even worse than having to
> find the right product/component, I now have to find the right issue
> tracker in the first place.
> * It's a very simplistic bug tracker, no file attachments (so no
> sensible way to do screenshots f.e.), no explicit dependencies that I
> can see, all sorts of features are missing.
> * We have no way to improve github to meet our own needs.
> * All the data is in github's hands and I believe in a closed source
> tool. Presumably we could write scripts to pull it out of their APIs
> but right now it's on their servers under their control. Are we
> confident that if github suddenly died we'd be able to pull the issues
> and put them somewhere new?
>
> One might argue that bugzilla is overkill for some projects. What
> concerns me is that moving bug trackers is hard, and if these projects
> reach the point where we are shipping them to millions of users (I'm
> thinking of pdf.js and browser ID here) I think we're going to want
> the level of bug tracking that bugzilla gives, and moving sooner
> rather than later is going to be easier.
>
> I guess what I'm asking here is what are the compelling reasons for
> using github's tracker in favour of bugzilla that I'm not seeing,
> because right now it doesn't seem like a big benefit to me.

Github's tracker (and workflow in general) seems to be optimized for
small, more-or-less self-contained projects. Bugzilla, on the other
hand, appears to be better optimized for things like the giant
complicated structure of Firefox, which can be almost partitioned into
not-quite independent projects under the administration of a large,
diverse group of people. With bugzilla, we can develop more complicated
queries, so it's possible for me to keep an eye on "all recent issues
that have the attention of users" in a query (it's my "new TB bugs with
votes" saved search, if you're wondering); I don't see any way to do
that in github. I also have constructed RSS feeds that let me quickly
see any bug in some places I'm interested in that's changed in the last
day, which is a low-effort way to find interesting bugs without being
spammed.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
12345