On Mon, May 28, 2007 at 07:29:33AM -0400, Daniel Berlin wrote:
On 5/28/07, Rask Ingemann Lambertsen [EMAIL PROTECTED] wrote:
On Wed, May 23, 2007 at 02:06:21PM -0400, Daniel Berlin wrote:
I have to look into bugzilla 3.0 migration first though. Bugzilla 3.0
introduces a custom fields
Daniel Berlin wrote:
1. Add a field to bugzilla for the SVN revision at which a particular
regression was introduced. Display that in bugzilla as a link to the
online SVN history browser so that clicking on a link takes us from the
PR straight to the checkin. This field value ought to be
On 5/29/07, Joe Buck [EMAIL PROTECTED] wrote:
On Mon, May 28, 2007 at 07:29:33AM -0400, Daniel Berlin wrote:
On 5/28/07, Rask Ingemann Lambertsen [EMAIL PROTECTED] wrote:
On Wed, May 23, 2007 at 02:06:21PM -0400, Daniel Berlin wrote:
.
You can customize what fields are shown on the
On Wed, May 23, 2007 at 10:02:02AM -0700, Joe Buck wrote:
Mark Mitchell wrote:
1. Add a field to bugzilla for the SVN revision at which a particular
regression was introduced. Display that in bugzilla as a link to the
online SVN history browser so that clicking on a link takes us from the
Mark Mitchell wrote:
1. Add a field to bugzilla for the SVN revision at which a particular
regression was introduced. Display that in bugzilla as a link to the
online SVN history browser so that clicking on a link takes us from the
PR straight to the checkin. This field value ought to be the
Mark Mitchell wrote:
1. Add a field to bugzilla for the SVN revision at which a particular
regression was introduced. Display that in bugzilla as a link to the
online SVN history browser so that clicking on a link takes us from the
PR straight to the checkin. This field value ought to be
On Wed, 2007-05-23 10:02:02 -0700, Joe Buck [EMAIL PROTECTED] wrote:
The Bugzilla field is just a string, so it's possible to put a
range there as well as a single number. The mathematical form for
an open/closed range could be used:
(working_rev,failing_rev]
to indicate that the bad
On 5/22/07, Mark Mitchell [EMAIL PROTECTED] wrote:
Ian Lance Taylor wrote:
[Danny, please see below for a request for your help.]
It's a reasonable idea, but overall it would have a negative effect.
People tend to ignore PRs that are assigned to somebody else; they
assume that person is
On Mon, 2007-05-21 15:35:53 -0700, Mark Mitchell [EMAIL PROTECTED] wrote:
Is there a volunteer who would like to help prepare a regular list of
P3-and-higher PRs, together with -- where known -- the name of the
person responsible for the checkin which caused the regression? Or, is
this
On 22/05/07, Jan-Benedict Glaw [EMAIL PROTECTED] wrote:
On Mon, 2007-05-21 15:35:53 -0700, Mark Mitchell [EMAIL PROTECTED] wrote:
Is there a volunteer who would like to help prepare a regular list of
P3-and-higher PRs, together with -- where known -- the name of the
person responsible for the
On Tue, 2007-05-22 08:50:59 +0100, Manuel López-Ibáñez [EMAIL PROTECTED]
wrote:
On 22/05/07, Jan-Benedict Glaw [EMAIL PROTECTED] wrote:
On Mon, 2007-05-21 15:35:53 -0700, Mark Mitchell [EMAIL PROTECTED]
wrote:
Is there a volunteer who would like to help prepare a regular list of
Hi,
When the commit which introduced the regression is known, why not
simply assign the bug to the committer? Surely, people do follow
regularly the bugs that are assigned to them, don't they?
In my opinion, all regressions should always be assigned to someone,
at all times. Either to the
On 5/22/07, François-Xavier Coudert [EMAIL PROTECTED] wrote:
Hi,
When the commit which introduced the regression is known, why not
simply assign the bug to the committer? Surely, people do follow
regularly the bugs that are assigned to them, don't they?
In my opinion, all regressions should
On Tue, May 22, 2007 at 06:13:58PM +0200, François-Xavier Coudert wrote:
CCing the person who caused the regression is more appropriate. Assigning
bugs to them detracts others from fixing the bug.
We already do that, and in lots of cases it doesn't work. CCing is not
coercive enough, you
We already do that, and in lots of cases it doesn't work. CCing is not
coercive enough, you only receive a few more mails (and some people
don't even read their bugzilla mail).
Coercion isn't an option that is available to us.
Hum, I checked the Merriam-Webster dictionary, and clearly
On Tue, May 22, 2007 at 10:11:27AM +0200, Jan-Benedict Glaw wrote:
On Tue, 2007-05-22 08:50:59 +0100, Manuel López-Ibáñez [EMAIL PROTECTED]
wrote:
On 22/05/07, Jan-Benedict Glaw [EMAIL PROTECTED] wrote:
On Mon, 2007-05-21 15:35:53 -0700, Mark Mitchell [EMAIL PROTECTED]
wrote:
Is
François-Xavier Coudert [EMAIL PROTECTED] writes:
When the commit which introduced the regression is known, why not
simply assign the bug to the committer? Surely, people do follow
regularly the bugs that are assigned to them, don't they?
In practice, no, they don't.
In my opinion, all
On 22/05/07, Joe Buck [EMAIL PROTECTED] wrote:
On Tue, May 22, 2007 at 06:13:58PM +0200, François-Xavier Coudert wrote:
CCing the person who caused the regression is more appropriate. Assigning
bugs to them detracts others from fixing the bug.
We already do that, and in lots of cases it
Joe Buck writes:
Joe This implies that you think it is the patch author's job to fix the
Joe problem. And if the patch were incorrect, you'd have an argument.
Joe But in this case, it seems that the patch is correct, but it exposes
Joe a problem elsewhere in the compiler (one of Kenner's famous
On 5/21/07, Mark Mitchell [EMAIL PROTECTED] wrote:
I've received some feedback suggesting that some contributors may not
always be aware of what open issues are available to work on, and,
perhaps more importantly, what regressions they may have caused.
Is there a volunteer who would like to
On 5/22/07, François-Xavier Coudert [EMAIL PROTECTED] wrote:
Take PR31095, for example. It's a 4.3 regression on x86 and x86_64
that is triggered on the GCC testsuite, it has been known for more
than 2 months, Janis kindly did a reghunt a month ago to attribute it,
the patch author was added in
On 5/22/07, François-Xavier Coudert [EMAIL PROTECTED] wrote:
CCing the person who caused the regression is more appropriate. Assigning
bugs to them detracts others from fixing the bug.
We already do that, and in lots of cases it doesn't work. CCing is not
coercive enough, you only receive a
Ian Lance Taylor wrote:
[Danny, please see below for a request for your help.]
It's a reasonable idea, but overall it would have a negative effect.
People tend to ignore PRs that are assigned to somebody else; they
assume that person is actually working on them. Conversely, people
won't
I've received some feedback suggesting that some contributors may not
always be aware of what open issues are available to work on, and,
perhaps more importantly, what regressions they may have caused.
Is there a volunteer who would like to help prepare a regular list of
P3-and-higher PRs,
On Mon, May 21, 2007 at 03:35:53PM -0700, Mark Mitchell wrote:
Is there a volunteer who would like to help prepare a regular list of
P3-and-higher PRs, together with -- where known -- the name of the
person responsible for the checkin which caused the regression? Or, is
this something that
is is very difficult work? i did't know whether i can competent for it.
i'.m a volunteer.
On 5/22/07, Mark Mitchell [EMAIL PROTECTED] wrote:
I've received some feedback suggesting that some contributors may not
always be aware of what open issues are available to work on, and,
perhaps more
26 matches
Mail list logo
