Bug Importance

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

Re: Bug Importance

i@paulbooker.co.uk
On 11/04/2012 17:25, Robert Kaiser wrote:

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

+1
>
> Robert Kaiser
> _______________________________________________
> 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
Reply | Threaded
Open this post in threaded view
|

Re: Bug Importance

Justin Wood (Callek)-2
In reply to this post by Robert Kaiser
Robert Kaiser wrote:

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

I had a similar discussion the other day about why B2G issues are being
tracked in github! Where I didn't seem to get much headway with the one
I was discussing with.

That said, I think this general overarching topic needs to be broken out
to a separate thread, with its own discussion/debate/points/etc
completely separately.


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

Mozilla's use of github (was Re: Bug Importance)

Robert Helmer-4
In reply to this post by Robert Kaiser
On 4/11/12 9:25 AM, Robert Kaiser wrote:

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

These are important points. I use github for many Mozilla projects, and
share all the same concerns.

In defense of github - Mozilla does not exist in a vacuum, but in a
world of other open-source and proprietary (and many in-between!)
projects. People involved with these projects wish to work with us, and
us with them, although they will not necessarily become part of the
Mozilla Community.

Two examples I am personally familiar with are Socorro (aka
crash-stats.m.o) which has many installations by people not otherwise
affiliated with Mozilla, and Perf-o-Matic (aka graphs.m.o) which is used
by (at least) WebKit. Both of these Mozilla projects use github,
although graphs is a mirror (hg.m.o/graphs is considered canonical.)
Both projects use Bugzilla exclusively for issue tracking. When we get a
pull request without an affiliated bug, we file one in bugzilla on the
contributor's behalf. I merge to the graphs github repo manually.

The road to contributing a patch to traditionally-hosted Mozilla
projects can be quite daunting compared to the UX of a github pull
request, and I believe that this both makes Mozilla projects harder to
discover and the overall bar to contribute is higher. github's issue
tracker is much simpler (and conversely, has fewer features) than
bugzilla, and many more developers already have github accounts and are
familiar with it's issue tracker (or can figure it out without much fuss.)

I can appreciate the choice github-the-company is making to fund a
high-quality product through charging for private repositories and
installs, which I assume are mostly for proprietary software. There is
definitely a risk here that they need to change strategy, are acquired,
or that some other event could have a big impact on us if our workflow
and information are heavily invested in github.

For git repositories, I believe we already have reasonable hedges in place:

* http://gitmirror.mozilla.org/ is available as an automatic mirror
* everybody who has cloned has a full copy of the project (recovering in
this way does not sound particularly fun, compared to the mirror)

However, for things such as review comments and issues those would
indeed be lost unless some special action was being taken (I believe
everything is available via the github API [1] but I don't know of
anyone actively mirroring this.)

One technical way forward might be to build a new project management/bug
tracker UI that sits atop the bugzilla and github APIs, in the spirit of
solving all problems in computer science by adding another level of
indirection ;)

It strikes me that Mozilla has a need to track, integrate and contribute
to many upstream projects, as well as tracking our own projects, so
having something like this might actually be sensible. The Canonical
Launchpad [2] project has some similarities in that it can track
upstream bugs, but I think it's built with very different goals in mind
so probably not directly applicable.

[1] http://developer.github.com/v3/
[2] http://en.wikipedia.org/wiki/Launchpad_%28website%29
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Mozilla's use of github (was Re: Bug Importance)

Robert Kaiser
Robert Helmer schrieb:
> However, for things such as review comments and issues those would
> indeed be lost unless some special action was being taken (I believe
> everything is available via the github API [1] but I don't know of
> anyone actively mirroring this.)

If the API makes them available, that's already a good step.

> One technical way forward might be to build a new project management/bug
> tracker UI that sits atop the bugzilla and github APIs, in the spirit of
> solving all problems in computer science by adding another level of
> indirection ;)

Hmm, feeding comments and issues into Bugzilla via their API might be
interesting indeed...

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

Re: Mozilla's use of github (was Re: Bug Importance)

Dave Mandelin-2
In reply to this post by Robert Helmer-4
On Friday, April 13, 2012 4:27:18 PM UTC-7, Robert Helmer wrote:

> On 4/11/12 9:25 AM, Robert Kaiser wrote:
> > 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.
>
> These are important points. I use github for many Mozilla projects, and
> share all the same concerns.
>
> In defense of github - Mozilla does not exist in a vacuum, but in a
> world of other open-source and proprietary (and many in-between!)
> projects. People involved with these projects wish to work with us, and
> us with them, although they will not necessarily become part of the
> Mozilla Community.
>
> Two examples I am personally familiar with are Socorro (aka
> crash-stats.m.o) which has many installations by people not otherwise
> affiliated with Mozilla, and Perf-o-Matic (aka graphs.m.o) which is used
> by (at least) WebKit. Both of these Mozilla projects use github,
> although graphs is a mirror (hg.m.o/graphs is considered canonical.)
> Both projects use Bugzilla exclusively for issue tracking. When we get a
> pull request without an affiliated bug, we file one in bugzilla on the
> contributor's behalf. I merge to the graphs github repo manually.
>
> The road to contributing a patch to traditionally-hosted Mozilla
> projects can be quite daunting compared to the UX of a github pull
> request, and I believe that this both makes Mozilla projects harder to
> discover and the overall bar to contribute is higher. github's issue
> tracker is much simpler (and conversely, has fewer features) than
> bugzilla, and many more developers already have github accounts and are
> familiar with it's issue tracker (or can figure it out without much fuss.)

It sounds like you are basically saying that github is better for coordination and co-development with 'external' people, such as WebKit devs and new contributors.

Are there more reasons to use github? In particular, I'm wondering if certain people or teams just find it better than hg+bugzilla for day-to-day work.

> I can appreciate the choice github-the-company is making to fund a
> high-quality product through charging for private repositories and
> installs, which I assume are mostly for proprietary software. There is
> definitely a risk here that they need to change strategy, are acquired,
> or that some other event could have a big impact on us if our workflow
> and information are heavily invested in github.
>
> For git repositories, I believe we already have reasonable hedges in place:
>
> * http://gitmirror.mozilla.org/ is available as an automatic mirror
> * everybody who has cloned has a full copy of the project (recovering in
> this way does not sound particularly fun, compared to the mirror)
>
> However, for things such as review comments and issues those would
> indeed be lost unless some special action was being taken (I believe
> everything is available via the github API [1] but I don't know of
> anyone actively mirroring this.)

Good points. So it seems like there aren't any disasters to worry about, just a risk of substantial disruption to the affected projects if the issues were to get lost.
 
> One technical way forward might be to build a new project management/bug
> tracker UI that sits atop the bugzilla and github APIs, in the spirit of
> solving all problems in computer science by adding another level of
> indirection ;)

Not sure exactly what the wink means. I'm skeptical that something like that could be made to work particularly well, at least without a major investment to build and a substantial continuing maintenance effort.

> It strikes me that Mozilla has a need to track, integrate and contribute
> to many upstream projects, as well as tracking our own projects, so
> having something like this might actually be sensible. The Canonical
> Launchpad [2] project has some similarities in that it can track
> upstream bugs, but I think it's built with very different goals in mind
> so probably not directly applicable.
>
> [1] http://developer.github.com/v3/
> [2] http://en.wikipedia.org/wiki/Launchpad_%28website%29

I think the whole situation and discussion around github is symptomatic of the fact that people think our existing tools are just not keeping up with either our needs, or what's possible with current technology; or maybe that we're just not talking enough as a community about what to do.

If our tools vs. github are a major barrier to attracting contributors or doing our own work, that seems like a major problem. If they are not a major barrier to anything, then having different teams run off and create incompatible trees and issue databases seems like a major problem. So I'm pretty convinced that the current situation is not good.

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

Re: Mozilla's use of github (was Re: Bug Importance)

Robert Helmer-4
On 4/16/12 1:38 PM, Dave Mandelin wrote:

> On Friday, April 13, 2012 4:27:18 PM UTC-7, Robert Helmer wrote:
>> The road to contributing a patch to traditionally-hosted Mozilla
>> projects can be quite daunting compared to the UX of a github pull
>> request, and I believe that this both makes Mozilla projects harder to
>> discover and the overall bar to contribute is higher. github's issue
>> tracker is much simpler (and conversely, has fewer features) than
>> bugzilla, and many more developers already have github accounts and are
>> familiar with it's issue tracker (or can figure it out without much fuss.)
>
> It sounds like you are basically saying that github is better for coordination and co-development with 'external' people, such as WebKit devs and new contributors.
>
> Are there more reasons to use github? In particular, I'm wondering if certain people or teams just find it better than hg+bugzilla for day-to-day work.


I personally feel that github+git is a better UX for development in
general compared to bugzilla+patches, and a big part of that is the
learning curve. Many devs already happen to use gitub. Plain old git
versus hg is way more subjective.


>> For git repositories, I believe we already have reasonable hedges in place:
>>
>> * http://gitmirror.mozilla.org/ is available as an automatic mirror
>> * everybody who has cloned has a full copy of the project (recovering in
>> this way does not sound particularly fun, compared to the mirror)
>>
>> However, for things such as review comments and issues those would
>> indeed be lost unless some special action was being taken (I believe
>> everything is available via the github API [1] but I don't know of
>> anyone actively mirroring this.)
>
> Good points. So it seems like there aren't any disasters to worry about, just a risk of substantial disruption to the affected projects if the issues were to get lost.


All the projects I work on rely quite heavily on bugzilla, and it'd be
pretty devastating for me if it all just went away one day. I find it
super critical for ongoing work as well as archeological expeditions, so
I'd imagine losing a substantial base of github issues and review
comments would be similar.


>> One technical way forward might be to build a new project management/bug
>> tracker UI that sits atop the bugzilla and github APIs, in the spirit of
>> solving all problems in computer science by adding another level of
>> indirection ;)
>
> Not sure exactly what the wink means. I'm skeptical that something like that could be made to work particularly well, at least without a major investment to build and a substantial continuing maintenance effort.


(the wink is just me congratulating myself on a clever reference)

I agree. Project management and issue tracking are a lot of work, and it
never ends (or at least lasts about as long as the project!)
github and bugzilla have both had and continue to have substantial
investment.

We'd need to decide what our current problems are, and whether they're
worth fixing, before trying to apply a technical solution.


>> It strikes me that Mozilla has a need to track, integrate and contribute
>> to many upstream projects, as well as tracking our own projects, so
>> having something like this might actually be sensible. The Canonical
>> Launchpad [2] project has some similarities in that it can track
>> upstream bugs, but I think it's built with very different goals in mind
>> so probably not directly applicable.
>>
>> [1] http://developer.github.com/v3/
>> [2] http://en.wikipedia.org/wiki/Launchpad_%28website%29
>
> I think the whole situation and discussion around github is symptomatic of the fact that people think our existing tools are just not keeping up with either our needs, or what's possible with current technology; or maybe that we're just not talking enough as a community about what to do.
>
> If our tools vs. github are a major barrier to attracting contributors or doing our own work, that seems like a major problem. If they are not a major barrier to anything, then having different teams run off and create incompatible trees and issue databases seems like a major problem. So I'm pretty convinced that the current situation is not good.


Personally I feel that hg, bugzilla, etc. are not a major barrier for a
motivated contributor. I have no way to measure how many more casual
contributions we might have received if it was a little easier, I can
say that I get more random unsolicited github pull requests than I do
bugzilla patches from non-mozillians.

github-the-company has been directing energy at making a great product
for a while now, so I think that's really hard for others to keep up
with and I don't feel too threatened that some of our infra is a bit
lackluster in comparison (we have some nice bells and whistles too that
they don't match, like tbpl and try and perf, dependencies in bugzilla,
etc.)

I think we have good reasons for not putting all of our eggs in the
github basket, but we should definitely learn from them and use their
service as appropriate.

I've found the hg-git plugin pretty handy for merging things between
hg.m.o/github, and for projects that mandate "though shalt use hg +
bugzilla" it's not too hard to just have github "on the side" for
working with contributors.

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

Re: Mozilla's use of github (was Re: Bug Importance)

Robert O'Callahan-3
In reply to this post by Dave Mandelin-2
On Tue, Apr 17, 2012 at 8:38 AM, Dave Mandelin <[hidden email]>wrote:

> If our tools vs. github are a major barrier to attracting contributors or
> doing our own work, that seems like a major problem. If they are not a
> major barrier to anything, then having different teams run off and create
> incompatible trees and issue databases seems like a major problem. So I'm
> pretty convinced that the current situation is not good.
>

As far as I can tell our tools and infrastructure are better than they've
ever been. Maybe other tools and infrastructure are better, but I don't
think anyone can claim our tools and infrastructure are "a major barrier to
doing our own work".

Rob
--
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Mozilla's use of github (was Re: Bug Importance)

David Dahl-5


----- Original Message -----

> From: "Robert O'Callahan" <[hidden email]>
> To: "Dave Mandelin" <[hidden email]>
> Cc: [hidden email], "Damon Sicore" <[hidden email]>
> Sent: Tuesday, April 17, 2012 4:34:21 AM
> Subject: Re: Mozilla's use of github (was Re: Bug Importance)
>
> On Tue, Apr 17, 2012 at 8:38 AM, Dave Mandelin
> <[hidden email]>wrote:
>
> > If our tools vs. github are a major barrier to attracting
> > contributors or
> > doing our own work, that seems like a major problem. If they are
> > not a
> > major barrier to anything, then having different teams run off and
> > create
> > incompatible trees and issue databases seems like a major problem.
> > So I'm
> > pretty convinced that the current situation is not good.
> >
>
> As far as I can tell our tools and infrastructure are better than
> they've
> ever been. Maybe other tools and infrastructure are better, but I
> don't
> think anyone can claim our tools and infrastructure are "a major
> barrier to
> doing our own work".
>

+1

It would be interesting if we could gather metrics on community contribution about our github projects. I get the feeling that Github usage *might* be a catalyst for more community participation but there is no hard evidence (that I have seen) to indicate this.

Regards,

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

Re: Mozilla's use of github (was Re: Bug Importance)

Philip Chee
In reply to this post by Dave Mandelin-2
On Tue, 17 Apr 2012 21:34:21 +1200, Robert O'Callahan wrote:

> On Tue, Apr 17, 2012 at 8:38 AM, Dave Mandelin <[hidden email]>wrote:
>
>> If our tools vs. github are a major barrier to attracting contributors or
>> doing our own work, that seems like a major problem. If they are not a
>> major barrier to anything, then having different teams run off and create
>> incompatible trees and issue databases seems like a major problem. So I'm
>> pretty convinced that the current situation is not good.
>>
>
> As far as I can tell our tools and infrastructure are better than they've
> ever been. Maybe other tools and infrastructure are better, but I don't
> think anyone can claim our tools and infrastructure are "a major barrier to
> doing our own work".

However they might be a major barrier (learning curve, paradigm shift)
to people familiar with the github workflow.

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: Mozilla's use of github (was Re: Bug Importance)

Mike Hoye-2
In reply to this post by Robert O'Callahan-3
On 12-04-17 5:34 AM, Robert O'Callahan wrote:

> On Tue, Apr 17, 2012 at 8:38 AM, Dave Mandelin <[hidden email]>wrote:
>
>> If our tools vs. github are a major barrier to attracting contributors or
>> doing our own work, that seems like a major problem. If they are not a
>> major barrier to anything, then having different teams run off and create
>> incompatible trees and issue databases seems like a major problem. So I'm
>> pretty convinced that the current situation is not good.
>>
>
> As far as I can tell our tools and infrastructure are better than they've
> ever been. Maybe other tools and infrastructure are better, but I don't
> think anyone can claim our tools and infrastructure are "a major barrier to
> doing our own work".

Nobody has made that claim, and it is a very different claim than the
one that kicked off this discussion. The conversation that kicked this
off was an observation that:

-  no two people or teams are using bugzilla the same way, and that this
is starting to cause internal communication problems.

The two major followup points I made in that thread were that:

- One symptom of those communication problems is that Bugzilla presents
a real barrier to participation for new contributors, and

- The increasing use of GitHub's private issue tracking and
closed-source development workflow as a Bugzilla/hg alternative puts
Mozilla at risk of a fractured development community and potentially
real information loss.

If any of those three are false or simply not a good time/value tradeoff
to address then they should not be addressed. If they're not an
organizational priority, doing nothing is the right thing. I think they
should be; I may be wrong.

But this is not (and should not become) a discussion about whether or
not somebody's been doing a second-rate job in some aspect of developer
support; it's about some larger internal and external communication
issues that Mozilla faces that happen to touch, among other things,
developer tools.

--
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: Mozilla's use of github (was Re: Bug Importance)

Mike Connor-4
In reply to this post by Philip Chee
On 2012-04-17, at 10:55 AM, Philip Chee wrote:

> On Tue, 17 Apr 2012 21:34:21 +1200, Robert O'Callahan wrote:
>> On Tue, Apr 17, 2012 at 8:38 AM, Dave Mandelin <[hidden email]>wrote:
>>
>>> If our tools vs. github are a major barrier to attracting contributors or
>>> doing our own work, that seems like a major problem. If they are not a
>>> major barrier to anything, then having different teams run off and create
>>> incompatible trees and issue databases seems like a major problem. So I'm
>>> pretty convinced that the current situation is not good.
>>>
>>
>> As far as I can tell our tools and infrastructure are better than they've
>> ever been. Maybe other tools and infrastructure are better, but I don't
>> think anyone can claim our tools and infrastructure are "a major barrier to
>> doing our own work".
>
> However they might be a major barrier (learning curve, paradigm shift)
> to people familiar with the github workflow.
I think it's all well and good to cite "I get lots of pull requests on Github!" as a rationale, but we've been doing it for long enough that we should probably pull some stats.  Like… how many pull requests do projects get from "outside" contributors vs. team members?

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

Re: Mozilla's use of github (was Re: Bug Importance)

Robert O'Callahan-3
In reply to this post by Mike Hoye-2
On Wed, Apr 18, 2012 at 3:11 AM, Mike Hoye <[hidden email]> wrote:

> -  no two people or teams are using bugzilla the same way, and that this
> is starting to cause internal communication problems.
>

No two people or teams use Bugzilla the same way? It seems to me that I and
the teams I work with have been using Bugzilla consistently for several
years now.

Maybe you meant "not all people or teams".

Rob
--
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Mozilla's use of github (was Re: Bug Importance)

Robert O'Callahan-3
In reply to this post by Philip Chee
On Wed, Apr 18, 2012 at 2:55 AM, Philip Chee <[hidden email]> wrote:

> However they might be a major barrier (learning curve, paradigm shift)
> to people familiar with the github workflow.
>

Learning a new workflow is normal when entering a large open source
project. Most large projects have their own infrastructure and workflow
that's not github's. Many large projects have a workflow that's much more
like ours than github.

So, smoothing the path for github users sounds like a good thing, but it's
more of an opportunity than a problem IMHO.

Rob
--
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Mozilla's use of github (was Re: Bug Importance)

Justin Lebar-3
On Wed, Apr 18, 2012 at 1:37 PM, Robert O'Callahan <[hidden email]> wrote:

> On Wed, Apr 18, 2012 at 2:55 AM, Philip Chee <[hidden email]> wrote:
>
>> However they might be a major barrier (learning curve, paradigm shift)
>> to people familiar with the github workflow.
>>
>
> Learning a new workflow is normal when entering a large open source
> project. Most large projects have their own infrastructure and workflow
> that's not github's. Many large projects have a workflow that's much more
> like ours than github.
>
> So, smoothing the path for github users sounds like a good thing, but it's
> more of an opportunity than a problem IMHO.

I don't want us to ignore the things we *can* learn from github.

It's fast.  It's pretty.  It's integrated with SCM.

It doesn't have mid-air collisions, or accidental modification of
flags.  You can reply to bugmail straight from your e-mail client.
Code review is integrated into the system.

Did I mention it's fast?

"Our workflow is not so hard to learn compared to the inherent
difficulty of hacking on Firefox" is, I think, a completely valid
point to make.  But on the other hand, I don't think we should write
off the pain that people are feeling or the benefits they see in
github.
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Mozilla's use of github (was Re: Bug Importance)

Mike Hoye-2
In reply to this post by Robert O'Callahan-3
On 12-04-17 11:30 PM, Robert O'Callahan wrote:
>
>
> Maybe you meant "not all people or teams".

No, I meant "no two people or teams."

Following the discussion in the "bug importance" thread, I did some
hallway usability testing, and stood in the kitchen in MoTo and asked
anyone walking past how they used Bugzilla.

Everyone I spoke to had roughly the same answer: "My team uses it like
this and ignores everything else. I use this other flag that my team
ignores, for my own reasons." The specific flags and features were
always different.

All told I spoke to about a dozen people; it was interesting to see
people on the same team compare notes about how they both do things
differently but still manage to avoid stepping on each others' toes.

The most fascinating thing is, all that understanding is just completely
ethereal; it's not written down anywhere, people say they just soaked it
up over time as they work with their teams. The implication is that
there isn't just one bugzilla workflow, that may present a challenge for
new contributors - there are dozens of little bugzilla-workflow
dialects, and no way to know which team speaks which one.

--
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: Mozilla's use of github (was Re: Bug Importance)

Chris Pearce-3
In reply to this post by Robert O'Callahan-3
On 19/04/2012 1:53 a.m., Mike Hoye wrote:

> On 12-04-17 11:30 PM, Robert O'Callahan wrote:
>>
>>
>> Maybe you meant "not all people or teams".
>
> No, I meant "no two people or teams."
>
> Following the discussion in the "bug importance" thread, I did some
> hallway usability testing, and stood in the kitchen in MoTo and asked
> anyone walking past how they used Bugzilla.
>
> Everyone I spoke to had roughly the same answer: "My team uses it like
> this and ignores everything else. I use this other flag that my team
> ignores, for my own reasons." The specific flags and features were
> always different.

Why do you think GitHub will be immune to feature usage
drift/divergence? (re: flags & features, not pull requests obviously)

It seems to me (based on only using GitHub for a few of my own small
projects) that the only way to mark/flag an "issue" in GitHub is to
either comment or add a label?

Granted our bugzilla instance has lots of flags used different ways by
different people. But I'm sure if we started using GitHub issues instead
of bugzilla we'd end up using a plethora of labels in the place where we
now use the various bugzilla flags and we'd end up with the same problem.

> The most fascinating thing is, all that understanding is just completely
> ethereal; it's not written down anywhere, people say they just soaked it
> up over time as they work with their teams.

Then maybe we should standardize and write it down and link to it in
such a way that new/prospective contributors are likely to find it?

Regardless we'd still have this problem r.e. flags/labels if we moved to
GitHub, and we'd still need to write it down somewhere.


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

Re: Mozilla's use of github (was Re: Bug Importance)

Mike Hoye-2
On 12-04-18 7:57 PM, Chris Pearce wrote:
> Why do you think GitHub will be immune to feature usage
> drift/divergence? (re: flags & features, not pull requests obviously)

I don't. In fact, I think that the feature/usage drift is both
inevitable and desirable with a complex tool in a large organization.
It's hard to see "Mozilla is now big enough to have several different
internal cultures" as anything but a positive, and regional dialects are
an artefact of a large population. Seems like a victory condition, and
nothing is going to change that.

I am making only two claims:

- That the Bugzilla front-end should be refactored, to some extent, with
an understanding that teams-dialects exist and a way to make those team
dialects explicit for other people, rather than the ethereal "everyone
kind of knows" understanding people have now. I believe that this will
have lasting benefits beyond internal communications issues.

- That the increasing reliance on a closed-source third-party
development workflow and issue tracking package is exposing Mozilla to a
risk of significant real dataloss, and that risk is not currently being
addressed. I believe that this risk is being assumed not out of any
explicit decision, but just because it's quietly happening and nothing's
gone horribly wrong yet. Which is another way of saying "without any
analysis, contingency planning or any one group assuming responsibility".

If GitHub goes dark tomorrow, what happens? Is all that information just
gone?

--
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: Mozilla's use of github (was Re: Bug Importance)

Robert O'Callahan-3
In reply to this post by Mike Hoye-2
On Thu, Apr 19, 2012 at 1:53 AM, Mike Hoye <[hidden email]> wrote:

> Following the discussion in the "bug importance" thread, I did some
> hallway usability testing, and stood in the kitchen in MoTo and asked
> anyone walking past how they used Bugzilla.
>
> Everyone I spoke to had roughly the same answer: "My team uses it like
> this and ignores everything else. I use this other flag that my team
> ignores, for my own reasons." The specific flags and features were always
> different.
>
> All told I spoke to about a dozen people; it was interesting to see people
> on the same team compare notes about how they both do things differently
> but still manage to avoid stepping on each others' toes.
>
> The most fascinating thing is, all that understanding is just completely
> ethereal; it's not written down anywhere, people say they just soaked it up
> over time as they work with their teams. The implication is that there
> isn't just one bugzilla workflow, that may present a challenge for new
> contributors - there are dozens of little bugzilla-workflow dialects, and
> no way to know which team speaks which one.


I see lots of Bugzilla activity from lots of teams (even legal and HR) and
lots and lots of developers and I never feel bothered that they're using
Bugzilla differently to the way I do. I guess these differences just don't
matter to me.

Rob
--
“You have heard that it was said, ‘Love your neighbor and hate your enemy.’
But I tell you, love your enemies and pray for those who persecute you,
that you may be children of your Father in heaven. ... If you love those
who love you, what reward will you get? Are not even the tax collectors
doing that? And if you greet only your own people, what are you doing more
than others?" [Matthew 5:43-47]
_______________________________________________
dev-planning mailing list
[hidden email]
https://lists.mozilla.org/listinfo/dev-planning
Reply | Threaded
Open this post in threaded view
|

Re: Mozilla's use of github (was Re: Bug Importance)

Martin Best
In reply to this post by David Dahl-5


----- Original Message -----

> From: "David Dahl" <[hidden email]>
> To: [hidden email]
> Cc: [hidden email], "Dave Mandelin" <[hidden email]>, "Damon Sicore" <[hidden email]>
> Sent: Tuesday, April 17, 2012 9:21:05 AM
> Subject: Re: Mozilla's use of github (was Re: Bug Importance)
>
>
>
> ----- Original Message -----
> > From: "Robert O'Callahan" <[hidden email]>
> > To: "Dave Mandelin" <[hidden email]>
> > Cc: [hidden email], "Damon Sicore"
> > <[hidden email]>
> > Sent: Tuesday, April 17, 2012 4:34:21 AM
> > Subject: Re: Mozilla's use of github (was Re: Bug Importance)
> >
> > On Tue, Apr 17, 2012 at 8:38 AM, Dave Mandelin
> > <[hidden email]>wrote:
> >
> > > If our tools vs. github are a major barrier to attracting
> > > contributors or
> > > doing our own work, that seems like a major problem. If they are
> > > not a
> > > major barrier to anything, then having different teams run off
> > > and
> > > create
> > > incompatible trees and issue databases seems like a major
> > > problem.
> > > So I'm
> > > pretty convinced that the current situation is not good.
> > >
> >
> > As far as I can tell our tools and infrastructure are better than
> > they've
> > ever been. Maybe other tools and infrastructure are better, but I
> > don't
> > think anyone can claim our tools and infrastructure are "a major
> > barrier to
> > doing our own work".
> >
>
> +1
>
> It would be interesting if we could gather metrics on community
> contribution about our github projects. I get the feeling that
> Github usage *might* be a catalyst for more community participation
> but there is no hard evidence (that I have seen) to indicate this.

I remembered seeing this conversation and thought I would mention that we are currently looking into what it would take to pull github data to give us a consolidated view (dashboard) of activity as part of the Bugzilla Anthropology project.  This is a reaction to requests linked to efforts to track progress towards achieving Kilimanjaro.  The trick seems to be that the API has a 5000 request limit (per user, per ip, and a few other ids) so we would have to figure out the best way to work within that constraint.

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

Re: Mozilla's use of github (was Re: Bug Importance)

Lawrence Mandel-2

> I remembered seeing this conversation and thought I would mention
> that we are currently looking into what it would take to pull github
> data to give us a consolidated view (dashboard) of activity as part
> of the Bugzilla Anthropology project.  This is a reaction to
> requests linked to efforts to track progress towards achieving
> Kilimanjaro.  The trick seems to be that the API has a 5000 request
> limit (per user, per ip, and a few other ids) so we would have to
> figure out the best way to work within that constraint.
>
Or speak with GitHub about giving us an exception/higher limit once we prove that we need one.

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