self-reply. --1.
On 2013-07-11, at 09:56 , Rob Campbell wrote:
> On 2013-05-31, at 15:46 , Boris Zbarsky wrote:
[…]
>> 1) It does not show feedback requests. This may explain why some people
>> are routinely ignoring them….
>
> Good point. I filed:
>
> https://github.com/harthur/bugzilla-
On 2013-05-31, at 15:46 , Boris Zbarsky wrote:
> On 5/24/13 10:50 AM, Justin Lebar wrote:
>> Consider for example how much better harthur's fileit and dashboard
>> tools [1] [2] are than bugzilla's built-in equivalents.
Wasn't "fileit" integrated into the New Bug page? That search suggestion
d
On 5/24/13 8:46 AM, Benoit Girard wrote:
I've got some patches that import webkit's check-style script to check the
style[1].
Google and Linux also have style lint scripts (cpplint.py [1] and
checkstyle.pl [2] respectively) that don't depend on a particular
compiler tool like clang-format.
On 5/24/13 10:50 AM, Justin Lebar wrote:
Consider for example how much better harthur's fileit and dashboard
tools [1] [2] are than bugzilla's built-in equivalents.
> [2] http://harthur.github.io/bugzilla-todos/
So I actually tried using the dashboard you link to for the last week.
It's actua
On 5/29/2013 1:50 PM, Benoit Girard wrote:
The clang-format list tells me that there are near-term plans for a
standalone "clang-tidy" utility built on clang-format that will do
much of what we're looking for as far as basic code-cleanup goes. I'm
asking around about what "near-term" means, and
On 5/23/2013 5:32 PM, Scott Johnson wrote:
Members of dev-platform:
As part of the Web Rendering work-week in Taiwan, we had a discussion of
the process of code review, graciously led by roc. If you were unable to
attend, or were able to attend and would like to review the proceedings,
notes are
On 5/28/13 7:39 AM, Benjamin Smedberg wrote:
Bugzilla is our tracking tool of record. I'm personally rather bullish
about bugzilla improvements, now that the 4.2 upgrade is done and we
have solid people working on it and making weekly improvements.
Yeah. It has its share of flaws, but it's als
On Friday, May 24, 2013 8:05:31 AM UTC-7, Mike Conley wrote:
> Sounds like we're talking about code review.
>
>
>
> >> But I want to qualify "integration into bugzilla": I explicitly do not
>
> >> want a tool that is tightly coupled to bugzilla. In fact, I want a
>
> >> tool that has as littl
Also, for those who are interested, I'm working on a script that will
(hopefully) be a pre-commit hook for checking that IDL changes have
corresponding IID changes (if needed):
https://github.com/jwir3/checkiid
Feel free to use it if you want to test your patches for compliance,
and also to te
On Mon, May 27, 2013 at 10:54 PM, Anthony Jones wrote:
> A pre-upload check would give the fastest feedback.
I'll be checking in a script in the mozilla repo that can be ran offline
and produce the same results.
On Tue, May 28, 2013 at 10:44 AM, Mike Hoye wrote:
> On 2013-05-27 10:54 PM, Antho
On 2013-05-27 10:54 PM, Anthony Jones wrote:
A pre-upload check would give the fastest feedback.
It would help me (and those who review my code) if there is an easy way
to check my patches from the command line before doing hg bzexport. Even
if it is only for white space. What we need is a way t
On 5/24/2013 10:50 AM, Justin Lebar wrote:
* I think we should experiment (again) with real pull-request integration
into bugzilla.
I'm totally in favor of better tools and real pull requests, and of
course the PRs need to be linked to bugzilla /somehow/.
But I want to qualify "integration into
This is only tangentially on topic, but I have a git pre-commit hook
which detects .orig files and trailing whitespace. It's saved me a
lot of embarrassment.
I also have a git tool which will fix trailing whitespace in your patch.
https://github.com/jlebar/moz-git-tools#pre-commit
https://github
On 25/05/13 04:16, Ehsan Akhgari wrote:
> On 2013-05-24 11:46 AM, Benoit Girard wrote:
> Another option is to use clang-format, which can lexically parse diff
> files.
A pre-upload check would give the fastest feedback.
It would help me (and those who review my code) if there is an easy way
to ch
wow, looks like is missed quite a lot while my power was out..
a high level response from the bmo team is: a goal for this quarter is
to address a lot of the review related issues.
i've been working through splinter issues and fixing the easy ones (it
no longer has problems with renames/copie
On 05/24/2013 11:05 AM, Mike Conley wrote:
Sounds like we're talking about code review.
But I want to qualify "integration into bugzilla": I explicitly do not
want a tool that is tightly coupled to bugzilla. In fact, I want a
tool that has as little to do with bugzilla as feasible.
I'm a con
On 2013-05-24 5:15 PM, Michael Hoye wrote:
- Original Message -
From: "Mike Hommey"
To: "Michael Hoye"
clang-format unfortunately only deals with whitespaces. It does have
neat formatting with them, but it's limited to that.
I don't think that's true, or at least, it looks like th
- Original Message -
> From: "Mike Hommey"
> To: "Michael Hoye"
>
> clang-format unfortunately only deals with whitespaces. It does have
> neat formatting with them, but it's limited to that.
I don't think that's true, or at least, it looks like that's only true for the
Mozilla style
On 2013-05-24 11:46 AM, Benoit Girard wrote:
On Fri, May 24, 2013 at 10:30 AM, Benjamin Smedberg
wrote:
* Automated tools: mhoye has identified lack of automated review as one of
our biggest blockers to getting more mentors involved and having successful
mentoring for new volunteers. It turns o
On Fri, May 24, 2013 at 08:40:29AM -0700, Michael Hoye wrote:
> - Original Message -
>
> > From: "Benjamin Smedberg" To: "Scott
> > Johnson" Cc: dev-platform@lists.mozilla.org,
> > "Michael Hoye"
>
> > * Automated tools: mhoye has identified lack of automated review as
> > one of our b
On 2013-05-24 11:04 AM, Justin Lebar wrote:
How about integrating it into BugzillaJS?
I don't think we should require a Firefox add-on to use our bug
tracker effectively.
We're a web company. We make a web browser. Let's write a webpage.
If a browser extension is the only way we can provide
On Fri, May 24, 2013 at 10:30 AM, Benjamin Smedberg
wrote:
> * Automated tools: mhoye has identified lack of automated review as one of
> our biggest blockers to getting more mentors involved and having successful
> mentoring for new volunteers. It turns out that nobody wants to mentor bugs
> when
- Original Message -
> From: "Benjamin Smedberg"
> To: "Scott Johnson"
> Cc: dev-platform@lists.mozilla.org, "Michael Hoye"
>
> * Automated tools: mhoye has identified lack of automated review as
> one
> of our biggest blockers to getting more mentors involved and having
> successful m
On Fri, May 24, 2013 at 10:50 PM, Justin Lebar wrote:
> If we do, we risk ending up with yet another crappy
> non-solution to a real problem (see bugzilla interdiff, splinter
> integration, and so on).
>
I think that's quite unfair to the people who integrated Splinter. It's not
everything I want
Sounds like we're talking about code review.
But I want to qualify "integration into bugzilla": I explicitly do not
want a tool that is tightly coupled to bugzilla. In fact, I want a
tool that has as little to do with bugzilla as feasible.
I'm a contributor to the Review Board project[1], whi
> How about integrating it into BugzillaJS?
I don't think we should require a Firefox add-on to use our bug
tracker effectively.
We're a web company. We make a web browser. Let's write a webpage.
If a browser extension is the only way we can provide a good user
experience in our bug tracker an
How about integrating it into BugzillaJS?
I'm working on it quite a lot now
(https://github.com/gkoberger/BugzillaJS/pull/77 and
https://github.com/gkoberger/omnium/pull/3) to make some improvements to
Bugzilla 'core'.
I think an add-on that eventually is good enough to use for Mozillians woul
> * I think we should experiment (again) with real pull-request integration
> into bugzilla.
I'm totally in favor of better tools and real pull requests, and of
course the PRs need to be linked to bugzilla /somehow/.
But I want to qualify "integration into bugzilla": I explicitly do not
want a to
On 5/23/2013 5:32 AM, Scott Johnson wrote:
Members of dev-platform:
As part of the Web Rendering work-week in Taiwan, we had a discussion of
the process of code review, graciously led by roc. If you were unable to
attend, or were able to attend and would like to review the proceedings,
notes are
Members of dev-platform:
As part of the Web Rendering work-week in Taiwan, we had a discussion of
the process of code review, graciously led by roc. If you were unable to
attend, or were able to attend and would like to review the proceedings,
notes are available here:
https://etherpad.mozilla.org
30 matches
Mail list logo
