On Mon, Mar 28, 2011 at 11:51 AM, Jeremy Orlow wrote:
> On Mon, Mar 28, 2011 at 11:48 AM, Maciej Stachowiak wrote:
>
>> I think it's better to have no exceptions than a very narrow exception.
>>
>
> This seems to be a reason for saying we should always have a bug for
> anything that's reviewed..
Darin didn't want to explain, but I'll mention that there are occasionally
situations where non-bugzilla review is desirable. Sometimes, it is desirable
to avoid drawing attention to a change because it relates to confidential
unreleased products, and in such cases it may be necessary to do rev
On Mon, Mar 28, 2011 at 11:48 AM, Maciej Stachowiak wrote:
>
> On Mar 28, 2011, at 11:21 AM, Darin Adler wrote:
>
> > On Mar 28, 2011, at 10:44 AM, Jeremy Orlow wrote:
> >
> > Sure I am open to discussion about that. I think that some check-ins,
> especially LayoutTest ones, don’t need change log
On Mon, Mar 28, 2011 at 11:48 AM, Maciej Stachowiak wrote:
> I think it's better to have no exceptions than a very narrow exception.
>
This seems to be a reason for saying we should always have a bug for
anything that's reviewed...
J
___
webkit-dev ma
On Mon, Mar 28, 2011 at 10:44 AM, Jeremy Orlow wrote:
> On Mon, Mar 28, 2011 at 10:06 AM, David Levin wrote:
>
>>http://trac.webkit.org/changeset/81305
>> PS Dmitry found a flaw in my original change log text -- due to my haste,
>> I originally had put in the wrong valgrind error.
>>
> This
On Mar 28, 2011, at 11:21 AM, Darin Adler wrote:
> On Mar 28, 2011, at 10:44 AM, Jeremy Orlow wrote:
>
>> If the issue is simply one of overhead, then we should allow committers to
>> omit change logs when they're not necessary as well.
>
> Sure I am open to discussion about that. I think that
On Mar 28, 2011, at 10:44 AM, Jeremy Orlow wrote:
> If the issue is simply one of overhead, then we should allow committers to
> omit change logs when they're not necessary as well.
Sure I am open to discussion about that. I think that some check-ins,
especially LayoutTest ones, don’t need chan
On Mar 28, 2011, at 9:59 AM, Antonio Gomes wrote:
> Darin, could you explain your reasons?
I think the burden for supplying a reason goes in the other direction, on
people who want to require a bug for each check-in.
Generally speaking, I want to keep paperwork and overhead to a minimum. We
re
On Mon, Mar 28, 2011 at 10:06 AM, David Levin wrote:
> Here's a change that I felt worth getting someone to glance at but didn't
> feel worth the overhead of a bug:
>http://trac.webkit.org/changeset/81305
>
> Since I was gardener and this was affecting the bots, it was a timely
> situation. (
Here's a change that I felt worth getting someone to glance at but didn't
feel worth the overhead of a bug:
http://trac.webkit.org/changeset/81305
Since I was gardener and this was affecting the bots, it was a timely
situation. (Sometimes getting in your fix right before another break comes
in
Darin, could you explain your reasons?
On Mon, Mar 28, 2011 at 12:52 PM, Darin Adler wrote:
> On Mar 27, 2011, at 1:31 AM, Jeremy Orlow wrote:
>
> > I'd even go a bit further and say that if something is worth a review
> (even if it's over the shoulder), it's worth a bug + a bug number.
>
> This
Can you please explain why? Its very little overhead and is useful for
tracking regressions and such.
J
On Mar 28, 2011 9:52 AM, "Darin Adler" wrote:
> On Mar 27, 2011, at 1:31 AM, Jeremy Orlow wrote:
>
>> I'd even go a bit further and say that if something is worth a review
(even if it's over t
On Mar 27, 2011, at 1:31 AM, Jeremy Orlow wrote:
> I'd even go a bit further and say that if something is worth a review (even
> if it's over the shoulder), it's worth a bug + a bug number.
This is where I do not agree. Review is a requirement, but I don’t think
bugs.webkit.org should be.
On Sat, Mar 26, 2011 at 2:26 PM, Patrick Gansterer wrote:
>
> Am 26.03.2011 um 19:30 schrieb Brent Fulgham:
>
> I don't want to have a bug report for everything either, but I do agree
> that my failure to include it in the changelog for the FontPlatformData
> change was a stupid oversight.
>
> I'l
On Sat, Mar 26, 2011 at 3:24 AM, Patrick Gansterer wrote:
> Hi,
>
> Sometimes folks commit changes without bug numbers. If those changes breaks
> things it's hard to find the correct context for the change.
> Can we make the bug number a requirement for a commit when it has a
> corresponding bug?
Am 26.03.2011 um 19:30 schrieb Brent Fulgham:
> I don't want to have a bug report for everything either, but I do agree that
> my failure to include it in the changelog for the FontPlatformData change was
> a stupid oversight.
>
> I'll make sure to avoid that mistake in the future!
I didn't wa
On Sat, Mar 26, 2011 at 10:41 AM, Darin Adler wrote:
> On Mar 26, 2011, at 3:24 AM, Patrick Gansterer wrote:
>
> > Sometimes folks commit changes without bug numbers. If those changes
> breaks things it's hard to find the correct context for the change.
> > Can we make the bug number a requiremen
> If you use webkit-patch everything just magically works (yay!!)
>
> --Oliver
>
I agree! And if people would use it on uploading patches to a bug report, we
wouldn't need a style-bot.
Dirk
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
htt
If you use webkit-patch everything just magically works (yay!!)
--Oliver
On Mar 26, 2011, at 11:30 AM, Brent Fulgham wrote:
>
> On Mar 26, 2011, at 10:41 AM, Darin Adler wrote:
>
>> On Mar 26, 2011, at 3:24 AM, Patrick Gansterer wrote:
>>
>>> Sometimes folks commit changes without bug numbers
On Mar 26, 2011, at 10:41 AM, Darin Adler wrote:
> On Mar 26, 2011, at 3:24 AM, Patrick Gansterer wrote:
>
>> Sometimes folks commit changes without bug numbers. If those changes breaks
>> things it's hard to find the correct context for the change.
>> Can we make the bug number a requirement f
On Mar 26, 2011, at 3:24 AM, Patrick Gansterer wrote:
> Sometimes folks commit changes without bug numbers. If those changes breaks
> things it's hard to find the correct context for the change.
> Can we make the bug number a requirement for a commit when it has a
> corresponding bug?
> IMHO it
Hi,
Sometimes folks commit changes without bug numbers. If those changes breaks
things it's hard to find the correct context for the change.
Can we make the bug number a requirement for a commit when it has a
corresponding bug?
IMHO it would be great if the style bot and the reviewer complain ab
22 matches
Mail list logo