Mainline in regression-fix mode after Thanksgiving

Mainline in regression-fix mode after Thanksgiving

[Mark Mitchell]

I've been staring at Bguzilla for about a week now trying to figure
out what to make of the fact that there are more than 200 regressions
open against GCC 3.4.  True, some of these are low-priority (MMIX or
Ada bugs for example) -- but most are not.  There are 110 wrong-code,
rejects-valid, or ice-on-valid regressions.  That's negative progress
from October 26th.

I realize that people are agressively using the compiler, and that
bugs reported is partially a function of the amount of use.  I also
understand that with all the changes we've got in this release, there
are bound to be some problems.  However, I think that we've got to
take steps to get things in hand.

Therefore, effective 12:01 AM Friday, November 26th PST, the usual
release-branch rules will be in effect on the mainline.  So,
regression-fixes only.  Patches submitted before that date can still
be applied, but other patches will need to be queued for either (a)
the mainline (if I lift the release-branch rules before we branch) or
(b) GCC 4.1 (if I do not).  Port/language maintainers please respect
this constraint.

The Objective-C++ situation is a special case; the SC has made it a
priority to get that functionality into 4.0.  Therefore, I'm going to
give Zem and Geoff until December 3rd to figure out what to do, and
convince anyone else who needs to be convinced.  Otherwise, I'm going
to postpone Objective-C++ until 4.1.

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com

Re: Mainline in regression-fix mode after Thanksgiving

[Kazu Hirata]

Hi Mark,

> Therefore, effective 12:01 AM Friday, November 26th PST, the usual
> release-branch rules will be in effect on the mainline.  So,
> regression-fixes only.

Are compile-time regressions considered to be regressions?  I am
guessing the answer is "no" to be on the safe side.

Kazu Hirata

Re: Mainline in regression-fix mode after Thanksgiving

[Diego Novillo]

On Mon, 2004-11-22 at 20:15 -0500, Kazu Hirata wrote:

> Are compile-time regressions considered to be regressions?  I am
> guessing the answer is "no" to be on the safe side.
> 
I certainly hope they are.  Several PRs are of this nature and compile
time problems are among the #1 complaints I've heard about mainline.


Diego.

Re: Mainline in regression-fix mode after Thanksgiving

[Mark Mitchell]

Diego Novillo wrote:
> On Mon, 2004-11-22 at 20:15 -0500, Kazu Hirata wrote:
> 
> 
>>Are compile-time regressions considered to be regressions?  I am
>>guessing the answer is "no" to be on the safe side.
>>
> 
> I certainly hope they are.  Several PRs are of this nature and compile
> time problems are among the #1 complaints I've heard about mainline.

Yes, compile-time regressions are OK -- but let's be circumspect.  For 
example, Nathan's bitmap patches are probably more aggressive than I'd 
like after this goes into effect.  Things that are less far-reaching and 
have less associated murkyness would be better.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Mainline in regression-fix mode after Thanksgiving

[Diego Novillo]

On Mon, 2004-11-22 at 17:26 -0800, Mark Mitchell wrote:

> Yes, compile-time regressions are OK -- but let's be circumspect.  For 
> example, Nathan's bitmap patches are probably more aggressive than I'd 
> like after this goes into effect.  Things that are less far-reaching and 
> have less associated murkyness would be better.
> 
OK.  Sounds good to me.


Thanks.  Diego.

Re: Mainline in regression-fix mode after Thanksgiving

[Mike Stump]

On Nov 22, 2004, at 4:26 PM, Mark Mitchell wrote:
> I've been staring at Bguzilla for about a week now trying to figure
> out what to make of the fact that there are more than 200 regressions
> open against GCC 3.4.

Dear Santa, for Christmas I want a regression tester that will 
specifically find the person that caused each of the 200 regressions, 
then do: sort | uniq -c | sort -nr and update a web page with that 
information.  We can then have just the people that put in regressions 
get hammered instead of everyone.

                                                 Thanks, Mike



:-)

Re: Mainline in regression-fix mode after Thanksgiving

[Mark Mitchell]

Mike Stump wrote:
> On Nov 22, 2004, at 4:26 PM, Mark Mitchell wrote:
> 
>> I've been staring at Bguzilla for about a week now trying to figure
>> out what to make of the fact that there are more than 200 regressions
>> open against GCC 3.4.
> 
> 
> Dear Santa, for Christmas I want a regression tester that will 
> specifically find the person that caused each of the 200 regressions, 
> then do: sort | uniq -c | sort -nr and update a web page with that 
> information.  We can then have just the people that put in regressions 
> get hammered instead of everyone.

Yes, that would be nice. :-)

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Mainline in regression-fix mode after Thanksgiving

[Giovanni Bajo]

Mark Mitchell <mark@codesourcery.com> wrote:

>> Dear Santa, for Christmas I want a regression tester that will
>> specifically find the person that caused each of the 200 regressions,
>> then do: sort | uniq -c | sort -nr and update a web page with that
>> information.  We can then have just the people that put in regressions
>> get hammered instead of everyone.
>
> Yes, that would be nice. :-)


The closer I get is this:

~$ wget -q -O - http://snurl.com/regressions40csv | cut -d ',' -f 5 | sort |
uniq -c | sort -nr
    166 "unassigned@gcc.gnu.org"
      7 "mark@codesourcery.com"
      6 "rth@gcc.gnu.org"
      6 "pinskia@gcc.gnu.org"
      6 "giovannibajo@libero.it"
      4 "rakdver@gcc.gnu.org"
      3 "lerdsuwa@gcc.gnu.org"
      2 "zack@gcc.gnu.org"
      2 "nathan@gcc.gnu.org"
      2 "hjl@lucon.org"
      2 "dberlin@gcc.gnu.org"
      2 "bje@gcc.gnu.org"
      1 "zlaski@apple.com"
      1 "zack@codesourcery.com"
      1 "uros@kss-loka.si"
      1 "toon@moene.indiv.nluug.nl"
      1 "steven@gcc.gnu.org"
      1 "jason@redhat.com"
      1 "hubicka@gcc.gnu.org"
      1 "echristo@redhat.com"
      1 "ebotcazou@gcc.gnu.org"
      1 "drow@gcc.gnu.org"
      1 "dnovillo@redhat.com"
      1 "dnovillo@gcc.gnu.org"
      1 "bonzini@gcc.gnu.org"
      1 "bkoz@gcc.gnu.org"
      1 "assigned_to"
      1 "aaronavay62@aaronwl.com"


Then, we need a policy to auto-assign a regression to whoever caused/exposed
it, and you'd get your Santa present for Thanksgiving :)
-- 
Giovanni Bajo

Re: Mainline in regression-fix mode after Thanksgiving

[Daniel Berlin]

On Tue, 23 Nov 2004, Giovanni Bajo wrote:

> Mark Mitchell <mark@codesourcery.com> wrote:
>
>>> Dear Santa, for Christmas I want a regression tester that will
>>> specifically find the person that caused each of the 200 regressions,
>>> then do: sort | uniq -c | sort -nr and update a web page with that
>>> information.  We can then have just the people that put in regressions
>>> get hammered instead of everyone.
>>
>> Yes, that would be nice. :-)
>
>
> The closer I get is this:

This counts people in the assigned field as the causer :).
I took 18611 and 15559 because i felt like fixing bugs, not because i 
caused them :)


> Then, we need a policy to auto-assign a regression to whoever caused/exposed
> it, and you'd get your Santa present for Thanksgiving :)
> --
> Giovanni Bajo
>
>

Re: Mainline in regression-fix mode after Thanksgiving

[H. J. Lu]

On Mon, Nov 22, 2004 at 06:12:09PM -0800, Mark Mitchell wrote:
> Mike Stump wrote:
> >On Nov 22, 2004, at 4:26 PM, Mark Mitchell wrote:
> >
> >>I've been staring at Bguzilla for about a week now trying to figure
> >>out what to make of the fact that there are more than 200 regressions
> >>open against GCC 3.4.
> >
> >
> >Dear Santa, for Christmas I want a regression tester that will 
> >specifically find the person that caused each of the 200 regressions, 
> >then do: sort | uniq -c | sort -nr and update a web page with that 
> >information.  We can then have just the people that put in regressions 
> >get hammered instead of everyone.
> 
> Yes, that would be nice. :-)

How many of them can be reproduced on Linux/ia32, Linux/x86_64 or
Linux/ia64? If you assign some of them to me, I guess I can track
down a couple a day and reassign them to those regression makers.



H.J.

Re: Mainline in regression-fix mode after Thanksgiving

[Nathan Sidwell]

Mark Mitchell wrote:

> Yes, compile-time regressions are OK -- but let's be circumspect.  For 
> example, Nathan's bitmap patches are probably more aggressive than I'd 
> like after this goes into effect.  Things that are less far-reaching and 

I concur that my most recent bitmap patch would not be appropriate after the
freeze.  I do have some small cleanups, confined to bitmap.c, in mind that I
would consider OK :)

nathan

-- 
Nathan Sidwell    ::   http://www.codesourcery.com   ::     CodeSourcery LLC
nathan@codesourcery.com    ::     http://www.planetfall.pwp.blueyonder.co.uk

Re: Mainline in regression-fix mode after Thanksgiving

[Mark Mitchell]

Nathan Sidwell wrote:
> Mark Mitchell wrote:
> 
>> Yes, compile-time regressions are OK -- but let's be circumspect.  For 
>> example, Nathan's bitmap patches are probably more aggressive than I'd 
>> like after this goes into effect.  Things that are less far-reaching and 
> 
> 
> I concur that my most recent bitmap patch would not be appropriate after 
> the
> freeze.  I do have some small cleanups, confined to bitmap.c, in mind 
> that I
> would consider OK :)

Yes, I was not trying to slander your recent patches, nor impugn your 
future judgement. :-)

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Mainline in regression-fix mode after Thanksgiving

[Janis Johnson]

On Mon, Nov 22, 2004 at 06:12:09PM -0800, Mark Mitchell wrote:
> Mike Stump wrote:
> >On Nov 22, 2004, at 4:26 PM, Mark Mitchell wrote:
> >
> >>I've been staring at Bguzilla for about a week now trying to figure
> >>out what to make of the fact that there are more than 200 regressions
> >>open against GCC 3.4.
> >
> >
> >Dear Santa, for Christmas I want a regression tester that will 
> >specifically find the person that caused each of the 200 regressions, 
> >then do: sort | uniq -c | sort -nr and update a web page with that 
> >information.  We can then have just the people that put in regressions 
> >get hammered instead of everyone.
> 
> Yes, that would be nice. :-)

I'm set up to do regression hunts on a powerpc64-linux-gnu system and
can keep it busy.  For regressions that can be tested with only cc1 or
cc1plus a regression hunt can build and test cross compilers so it
doesn't matter what the build/host system is.

If there are regressions you'd like me to track down, assign the PRs to
me temporarily and then I can assign them to the person who introduced
or exposed the bug, or to someone else who can then decide what do with
it next.

Janis

Re: Mainline in regression-fix mode after Thanksgiving

[Giovanni Bajo]

Janis Johnson <janis187@us.ibm.com> wrote:


> I'm set up to do regression hunts on a powerpc64-linux-gnu system and
> can keep it busy.  For regressions that can be tested with only cc1 or
> cc1plus a regression hunt can build and test cross compilers so it
> doesn't matter what the build/host system is.

Great!

> If there are regressions you'd like me to track down, assign the PRs to
> me temporarily and then I can assign them to the person who introduced
> or exposed the bug, or to someone else who can then decide what do with
> it next.

As I said in another mail in this thread, we do not have a policy so that we
can automatically assign regressions to the author of the patch which
caused/exposed them. (Re)Assigning a bug without permission is considered
unpolite by some people.

Note that I do not agree. If Mark Mitchell agrees, we can setup a policy to
do so. For many regressions present in Bugzilla, we already know which patch
caused it (thanks mainly to Volker and Andrew), so assigning them in
Bugzilla could be a good way to make this more visible. Right now, we
usually just CC: the person that caused the regression notifying him/her.
-- 
Giovanni Bajo

Re: Mainline in regression-fix mode after Thanksgiving

[Mark Mitchell]

Giovanni Bajo wrote:
> Janis Johnson <janis187@us.ibm.com> wrote:

> Note that I do not agree. If Mark Mitchell agrees, we can setup a policy to

It's not purely for me to say.  Making it our policy to auto-assign 
regressions would be something of a societal change, and, as such, 
should only be done as part of a broader consensus.

Personally, I think this is a reasonable thing to do, and I've in fact 
given the bugmasters explict permission to assign bugs to me if the 
regression comes from a patch I've committed.  Assigning the regression, 
however, is only half the problem: the other problem is getting the 
assignee to actually fix the problem.

We have no very effective mechanism for that.  There are, I suppose, 
steps we could take: we could forbid people from checking in changes 
while they have outstanding regressions open, for example.  I do not 
think such a strict policy would be constructive.  (One problem, for 
example: some regressions may not be very important.)

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Mainline in regression-fix mode after Thanksgiving

[Janis Johnson]

On Tue, Nov 23, 2004 at 06:15:59PM +0100, Giovanni Bajo wrote:
> Janis Johnson <janis187@us.ibm.com> wrote:
> 
> 
> > I'm set up to do regression hunts on a powerpc64-linux-gnu system and
> > can keep it busy.  For regressions that can be tested with only cc1 or
> > cc1plus a regression hunt can build and test cross compilers so it
> > doesn't matter what the build/host system is.
> 
> Great!
> 
> > If there are regressions you'd like me to track down, assign the PRs to
> > me temporarily and then I can assign them to the person who introduced
> > or exposed the bug, or to someone else who can then decide what do with
> > it next.
> 
> As I said in another mail in this thread, we do not have a policy so that we
> can automatically assign regressions to the author of the patch which
> caused/exposed them. (Re)Assigning a bug without permission is considered
> unpolite by some people.

Generally I've just added the person to the cc: list, which would be fine
as long as I can also change a PR back to unassigned.  The assignment
would just be to show that I'm looking at it, althought that could just
as well be done with a comment in the PR.  Whatever.

Janis

Re: Mainline in regression-fix mode after Thanksgiving

[Joe Buck]

On Tue, Nov 23, 2004 at 09:23:21AM -0800, Mark Mitchell wrote:
> It's not purely for me to say.  Making it our policy to auto-assign 
> regressions would be something of a societal change, and, as such, 
> should only be done as part of a broader consensus.

> Personally, I think this is a reasonable thing to do, and I've in fact 
> given the bugmasters explict permission to assign bugs to me if the 
> regression comes from a patch I've committed.  Assigning the regression, 
> however, is only half the problem: the other problem is getting the 
> assignee to actually fix the problem.

In a corporate environment, where programmers are paid to maintain code,
an assignment policy means that it is a particular person's job to fix a
bug, and that some penalty will be paid if that person does not do his/her
job.  But we don't have that here; it's a volunteer environment.  Under
such a circumstance, the only reasonable thing that assignment can mean in
the GCC project is that the assignee has agreed to work on a bug fix, and
anyone reading the PR can see that it is being worked on.

Under these circumstances, I don't think that the bugmasters should assign
bugs to people unless there is pre-existing agreement (for example,
Mark has agreed to accept bug assignments as described above).  After
all, we have an alternative: if a patch causes regressions and this isn't
promptly fixed, the patch can be reverted.

I suggest cc-ing the patch submitter when a regression is traced to a
patch, and also suggest that people assign bugs to themselves if they plan
to work on a fix, to avoid duplication of work.  That also means
"unassigning" the bug if other work intrudes, so someone else can pick up
the slack.

Re: Mainline in regression-fix mode after Thanksgiving

[Giovanni Bajo]

Joe Buck <Joe.Buck@synopsys.COM> wrote:

> In a corporate environment, where programmers are paid to maintain code,
> an assignment policy means that it is a particular person's job to fix a
> bug, and that some penalty will be paid if that person does not do his/her
> job.  But we don't have that here; it's a volunteer environment.  Under
> such a circumstance, the only reasonable thing that assignment can mean in
> the GCC project is that the assignee has agreed to work on a bug fix, and
> anyone reading the PR can see that it is being worked on.
>
> Under these circumstances, I don't think that the bugmasters should assign
> bugs to people unless there is pre-existing agreement (for example,
> Mark has agreed to accept bug assignments as described above).  After
> all, we have an alternative: if a patch causes regressions and this isn't
> promptly fixed, the patch can be reverted.
>
> I suggest cc-ing the patch submitter when a regression is traced to a
> patch, and also suggest that people assign bugs to themselves if they plan
> to work on a fix, to avoid duplication of work.  That also means
> "unassigning" the bug if other work intrudes, so someone else can pick up
> the slack.

This is basically the rationale for the current way of doing things in
Bugzilla, and in fact it makes a lot of sense.

The change I am proposing is to give LESS meaning to the assignment: since
there is no way we can force anybody to do anything, I am proposing that an
assignemnt becomes just a way to mark the person who is supposed to be
looking the bug more closely at any given moment. For instance, bugmasters
happen to[*] assign bugs to themselves if they are working to trace down
regressions or minimize the bigger testcases, so that they don't duplicate
efforts. Janis was also saying that we could assign bugs to her, and she
would unassign them when her regression hunter is done.

Under this point of view, assigning a bug to the author of the patch who
caused a regression is a way to officially ask his opinion on the bug. It
does not necessarily mean that the bug must be fixed by the assignee. The
assignee would still be free to unassign it immediatly saying "sorry, no
time to look at this right"; the unassigned bug would then be free for other
takers. In more normal scenario, he would at least double check the issue,
and explain if it is his patch which is buggy or if it just exposed an
existing bug. After that, if he doesn't know how to fix the exposed bug, or
he does not have time to work on that, or the moon is blue, he would just
unassign it.

In other words, I do not think the assignment should be interpreted as a
strict commitment to get the bug fixed. After all, as you said, this is a
volunteer project: so there is no way we can force anybody to do anything.
Assigning a bug would just be "please, tell us what you think about this",
keeping a bug assigned would be "yes I'm working on this", and unassigning a
bug would be "sorry, no more time to work on this".

Another thing: if you wander through Bugzilla finding a regression to fix,
it happens often to find regressions which were reported as exposed/caused
by someone else, but he has not commented on the bug for several months, so
you do not know what to do. If the bug was *assigned* to him, you would not
probably even look at it. It would then be up the RM to ask people who are
keeping bugs assigned for months without working on them to at least
unassign them. We could have a policy so that bugmasters could ping an
assignee who has not commented on a bug after one month (or even unassign it
if they get totally no answer from the assignee for a long time).


[*] used to, but I believe it would be valuable to do that again.
-- 
Giovanni Bajo

Re: Mainline in regression-fix mode after Thanksgiving

[Joe Buck]

On Tue, Nov 23, 2004 at 07:27:08PM +0100, Giovanni Bajo wrote:
> The change I am proposing is to give LESS meaning to the assignment: since
> there is no way we can force anybody to do anything, I am proposing that an
> assignemnt becomes just a way to mark the person who is supposed to be
> looking the bug more closely at any given moment.

I'd prefer for assignment to mean that the assigned person has agreed to
look at the bug.  With your change, we lose the ability to make the
distinction: when I see a name in the assignment field, under your system
that would give me no information about whether anyone is looking at it.

If you attach to the log a note saying that the regression is caused by
a given patch (with the name of the patch submitter) all the information
is already in the PR.  Your proposed change to the assignee field, therefore,
adds no information, and in fact removes information (we can already
find out which patch caused the bug, but we can no longer tell whether
there's a person who has agreed to work on a fix).

Re: Mainline in regression-fix mode after Thanksgiving

[Mike Stump]

I find the current thread kinda surreal.

I would like to arguing in favor of setting a policy in which we 
automagically assign people the regressions they cause.  One advantage, 
by exposing them to the after effects of what they do, with experience 
in such a system, they learn what types of changes cause what types of 
problems.  I'll go so far as to say, most people actually change their 
behavior to match the automation.  My experience is that this happens 
in 8-12 months.  Having a machine do it, is easier to take, then having 
someone bring it up, if the machine brings up the issue, others, in 
time, generally won't have to.  Our development model relies heavily on 
trust.  I trust you will not make things worse, and you trust me, that 
I will not.  Our users trust us that we won't put in regressions.  
Users are not unimportant.

As to the question of important regressions v unimportant ones, things 
we plan on shipping broken, those can be xfailed/suspended/closed.

The issue was raised that we can revert patches for regressions that 
are not promptly fixed.  While this works some of the time, this breaks 
down when the regression is found via slow turn around testing 
(non-dejagnu testing), and sometimes these can take a year or more to 
show up, at that point, we generally can't just revert a change, as 
there may now be other work that relies in a more critical way, that 
the change is in.

I don't think people need to unassign so others can take up the slack, 
I think people should just grab bugs they want to fix, and once fixed, 
close them.  A bug that has been sitting for a year on someone's plate 
means that we need more maintainers in that area, or that the bug just 
isn't all that important.  When people step forward to fix things, they 
are voting that the bug is important.

I think that each person can decide if they work on a regression they 
caused or a bug they want to fix.  In general, we want to encourage 
people to fix they regressions they cause.  I think most people 
understand this.


So, let me ask if anyone who puts in patches would object to having 
regressions assigned to them?  If no one objects, I'd say, lets just 
make it policy.

Re: Mainline in regression-fix mode after Thanksgiving

[Mike Stump]

On Nov 23, 2004, at 2:15 PM, chris jefferson wrote:
> While I might be missing something obvious, how do you intend to tell?

Magic pixie dust.  Seriously, any mechanism that works.  Some that 
comes to mind, Pinski, reghunt down to one author...

> I occasionally get e-mails that say "you or someone else on this list 
> caused a regression",

Ideally, we'd want a second order tester working off the data from the 
first that would narrow them down to one author.

In fact, given such a tester, the second one should send out the 
emails, not the first one... :-)

Re: Mainline in regression-fix mode after Thanksgiving

[Joseph S. Myers]

Given the extent of diagnostic changes going into 4.0, once mainline is in 
regression-fix mode (and so the levels of diagnostic churn should be 
lower) I propose to submit a snapshot to the Translation Project (for both 
cpplib.pot and gcc.pot) to give translators more time to catch up before 
the release.  (And then to submit a snapshot with updated .pot files again 
after 4.0 branches to catch up on the much smaller number of changes that 
should have gone in by then.)

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: Mainline in regression-fix mode after Thanksgiving

[Mark Mitchell]

Joseph S. Myers wrote:
> Given the extent of diagnostic changes going into 4.0, once mainline is in 
> regression-fix mode (and so the levels of diagnostic churn should be 
> lower) I propose to submit a snapshot to the Translation Project (for both 
> cpplib.pot and gcc.pot) to give translators more time to catch up before 
> the release.  (And then to submit a snapshot with updated .pot files again 
> after 4.0 branches to catch up on the much smaller number of changes that 
> should have gone in by then.)

Make sense.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Mainline in regression-fix mode after Thanksgiving

[Gabriel Dos Reis]

"Joseph S. Myers" <joseph@codesourcery.com> writes:

| Given the extent of diagnostic changes going into 4.0, once mainline is in 
| regression-fix mode (and so the levels of diagnostic churn should be 
| lower) I propose to submit a snapshot to the Translation Project (for both 
| cpplib.pot and gcc.pot) to give translators more time to catch up before 
| the release.  (And then to submit a snapshot with updated .pot files again 
| after 4.0 branches to catch up on the much smaller number of changes that 
| should have gone in by then.)

I second this proposal.

-- Gaby

Re: Mainline in regression-fix mode after Thanksgiving

[Giovanni Bajo]

Mike Stump <mrs@apple.com> wrote:

> I would like to arguing in favor of setting a policy in which we
> automagically assign people the regressions they cause.

Great, another one for this.

> So, let me ask if anyone who puts in patches would object to having
> regressions assigned to them?  If no one objects, I'd say, lets just
> make it policy.

Any takers?

It is totally fine with me as well, and it is in fact what I already do: I
immediately assign regressions which I caused to me, so that I don't lose
track of them.
-- 
Giovanni Bajo

Re: Mainline in regression-fix mode after Thanksgiving

[Giovanni Bajo]

chris jefferson <caj@cs.york.ac.uk> wrote:

> While I might be missing something obvious, how do you intend to tell?

There are several ways.

Bugmasters have access to an automatic regression tester (by Phil) on
x86-linux which finds the single day on which a regression appeared. Given
there, looking at a ChangeLog is usually enough to spot the offending patch.
Janis reghunt is even more accurate, and it is public (it is in
gcc/contrib).

As I said, bugmasters already find out the offending patch for most
regressions, so the question here is whether we want to auto-assign them or
not. If people thinks this is a SC decision, then I would like to request an
official SC statement on this. Otherwise, we are waiting for a maintainer to
step in and say that he does not like to have regressions auto-assigned to
him and why.
-- 
Giovanni Bajo

Re: Mainline in regression-fix mode after Thanksgiving

[Joe Buck]

On Wed, Nov 24, 2004 at 07:22:04PM +0100, Giovanni Bajo wrote:
> As I said, bugmasters already find out the offending patch for most
> regressions, so the question here is whether we want to auto-assign them or
> not. If people thinks this is a SC decision, then I would like to request an
> official SC statement on this. Otherwise, we are waiting for a maintainer to
> step in and say that he does not like to have regressions auto-assigned to
> him and why.

If there is no objection to auto-assignment by anyone who is likely to
get bugs auto-assigned to him/her (that is, from a heavy-duty contributor),
I think the bugmasters should be free to do what they want without the
SC butting in (even though I raised a concern before).

Re: Mainline in regression-fix mode after Thanksgiving

[Richard Sandiford]

"Giovanni Bajo" <rasky@develer.com> writes:
> Mike Stump <mrs@apple.com> wrote:
>> So, let me ask if anyone who puts in patches would object to having
>> regressions assigned to them?  If no one objects, I'd say, lets just
>> make it policy.
>
> Any takers?

Well, I don't object to anyone doing this for my patches, but I really
do think Joe's description of how the assigned field should work is better.

For example, if I'm in a bug-fixing mood, the first thing I'll do is
search bugzilla for MIPS PRs.  And since this is something I do in my
spare time, I don't want to waste it by duplicating other people's work.
So I'll pick the bugs that aren't yet assigned to anyone.

You (Giovanni) say that people could just unassign themselves if they
don't plan to look at a PR soon.  Although that's clearly the case _in
principle_, in practice, this often doesn't happen.  There are several
target-independent bugs with a MIPS target field that have been assigned
(to non-MIPS maintainers) for many months without any apparent action.

[No criticism implied, btw.  I'm not whiter than white here.]

As I think Joe said, if the PR trail already mentions the patch that
caused a regression, putting the name of the patch author in the assigned
field doesn't add any more information.  It actually removes information,
because PRs then go into an uncertain "is anyone really going to look at
this or not?" state.

Richard

Re: Mainline in regression-fix mode after Thanksgiving

[Gerald Pfeifer]

On Tue, 23 Nov 2004, Joe Buck wrote:
> I'd prefer for assignment to mean that the assigned person has agreed to
> look at the bug.  With your change, we lose the ability to make the
> distinction: when I see a name in the assignment field, under your system
> that would give me no information about whether anyone is looking at it.

What I have seen in a large development environment is a slight
variation of our current Bugzilla workflow:

  After a bug is assigned to someone, it remains in state NEW, and
  it's up to the developer (or her manager) to ACCEPT that assignment.

We wouldn't need new fields nor state in GCC Bugzilla, just slightly 
adjust the workflow.

Gerald

Re: Mainline in regression-fix mode after Thanksgiving

[Mike Stump]

On Thursday, November 25, 2004, at 02:44  AM, Richard Sandiford wrote:
> For example, if I'm in a bug-fixing mood, the first thing I'll do is
> search bugzilla for MIPS PRs.  And since this is something I do in my
> spare time, I don't want to waste it by duplicating other people's 
> work.
> So I'll pick the bugs that aren't yet assigned to anyone.

What has your experience been taking bugs from others to work and fix 
them?  All I can say is that my running experience is that collisions 
happen less than once a decade.  If you are worried about it, take the 
bug a week before you start working on it.  I'm assuming that bugzilla 
emails the assigned on state change.

If it became a problem, we can always have a state, actively working on 
this, or people could annotate the bug report that it is being worked 
on, or just send the person email asking if they are working on it.

In the olden days, PRMS was used for bug activity and used emacs to 
edit bug reports, and the emacs locking mechanism was enough to alert 
to the fact someone was editing the bug report.  If everyone changed 
but didn't save the report when they start on the bug, then one winds 
up with a nice light weight mechanism that solves the problem.

Re: Mainline in regression-fix mode after Thanksgiving

[Toon Moene]

Mark Mitchell wrote:

> I realize that people are agressively using the compiler, and that
> bugs reported is partially a function of the amount of use.  I also
> understand that with all the changes we've got in this release, there
> are bound to be some problems.  However, I think that we've got to
> take steps to get things in hand.

Note that the Fortran list (both fortran and libfortran) contain 
"regressions" of gfortran vs. g77.  Because these are completely 
separate front ends, these are not really regressions, but extensions to 
Fortran 77 that g77 supports that gfortran does not (yet).

As we assume that distributors will provide both gfortran and (in a 
separate directory) g77, these "regressions" do not really count.

Hope this helps,

-- 
Toon Moene - e-mail: toon@moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/

Re: Mainline in regression-fix mode after Thanksgiving

[Toon Moene]

Janis Johnson wrote:

> I'm set up to do regression hunts on a powerpc64-linux-gnu system and
> can keep it busy.  For regressions that can be tested with only cc1 or
> cc1plus a regression hunt can build and test cross compilers so it
> doesn't matter what the build/host system is.

Be aware of the maximL "Those who make no mistake usually make nothing".

I.e., any measure of regressionist behaviour should be offset 
(normalized) by the number of successful changes the person has made.

Cheers,

-- 
Toon Moene - e-mail: toon@moene.indiv.nluug.nl - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html
A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/

Re: Mainline in regression-fix mode after Thanksgiving

[Mark Mitchell]

Toon Moene wrote:
> Mark Mitchell wrote:
> 
>> I realize that people are agressively using the compiler, and that
>> bugs reported is partially a function of the amount of use.  I also
>> understand that with all the changes we've got in this release, there
>> are bound to be some problems.  However, I think that we've got to
>> take steps to get things in hand.
> 
> 
> Note that the Fortran list (both fortran and libfortran) contain 
> "regressions" of gfortran vs. g77.  Because these are completely 
> separate front ends, these are not really regressions, but extensions to 
> Fortran 77 that g77 supports that gfortran does not (yet).
> 
> As we assume that distributors will provide both gfortran and (in a 
> separate directory) g77, these "regressions" do not really count.

That's very useful information; thank you.

-- 
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com
(916) 791-8304

Re: Mainline in regression-fix mode after Thanksgiving

[Richard Earnshaw]

On Mon, 2004-11-29 at 04:17, Mark Mitchell wrote:
> Toon Moene wrote:
> > Mark Mitchell wrote:
> > 
> >> I realize that people are agressively using the compiler, and that
> >> bugs reported is partially a function of the amount of use.  I also
> >> understand that with all the changes we've got in this release, there
> >> are bound to be some problems.  However, I think that we've got to
> >> take steps to get things in hand.
> > 
> > 
> > Note that the Fortran list (both fortran and libfortran) contain 
> > "regressions" of gfortran vs. g77.  Because these are completely 
> > separate front ends, these are not really regressions, but extensions to 
> > Fortran 77 that g77 supports that gfortran does not (yet).
> > 
> > As we assume that distributors will provide both gfortran and (in a 
> > separate directory) g77, these "regressions" do not really count.
> 
> That's very useful information; thank you.

Whilst on the issue of g77 vs g95.  I still regard the fact that you
have to build and install (in a system directory) a non-standard build
of a non-standard library (gmp with mpf) as a major build bug.  This
makes it impossible for folks who don't have root access on their
machines to build and install the fortran compiler unless they are
prepared to set LD_LIBRARY_PATH (or whatever) every time they want to
run the resulting compiler.

R.

Re: Mainline in regression-fix mode after Thanksgiving

[Paul Brook]

On Monday 29 November 2004 09:55, Richard Earnshaw wrote:
> Whilst on the issue of g77 vs g95.  I still regard the fact that you
> have to build and install (in a system directory) a non-standard build
> of a non-standard library (gmp with mpf) as a major build bug.  This
> makes it impossible for folks who don't have root access on their
> machines to build and install the fortran compiler unless they are
> prepared to set LD_LIBRARY_PATH (or whatever) every time they want to
> run the resulting compiler.

Not impossible. It should work if you build/link a static libgmp.a.
I agree it's a problem though.

Paul

Re: Mainline in regression-fix mode after Thanksgiving

[Richard Earnshaw]

On Mon, 2004-11-29 at 13:29, Paul Brook wrote:
> On Monday 29 November 2004 09:55, Richard Earnshaw wrote:
> > Whilst on the issue of g77 vs g95.  I still regard the fact that you
> > have to build and install (in a system directory) a non-standard build
> > of a non-standard library (gmp with mpf) as a major build bug.  This
> > makes it impossible for folks who don't have root access on their
> > machines to build and install the fortran compiler unless they are
> > prepared to set LD_LIBRARY_PATH (or whatever) every time they want to
> > run the resulting compiler.
> 
> Not impossible. It should work if you build/link a static libgmp.a.
> I agree it's a problem though.

Default builds of these libraries on most platforms will produce DSO
versions of the libraries.

Defaults builds of gcc that link against these will link to the DSO
instances.

You pretty much need to be an expert to work around this.  There's
certainly no configure-time option that I'm aware of that will do all
this for you -- it requires, at the least, changes to the make system.

R.

Re: Mainline in regression-fix mode after Thanksgiving

[Andreas Schwab]

Richard Earnshaw <rearnsha@gcc.gnu.org> writes:

> You pretty much need to be an expert to work around this.  There's
> certainly no configure-time option that I'm aware of that will do all
> this for you -- it requires, at the least, changes to the make system.

Try --disable-shared.

Andreas.

-- 
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Mainline in regression-fix mode after Thanksgiving

[Phil Edwards]

On Mon, Nov 29, 2004 at 03:24:23PM +0100, Andreas Schwab wrote:
> Richard Earnshaw <rearnsha@gcc.gnu.org> writes:
> 
> > You pretty much need to be an expert to work around this.  There's
> > certainly no configure-time option that I'm aware of that will do all
> > this for you -- it requires, at the least, changes to the make system.
> 
> Try --disable-shared.

Now that we're all using newer autoconf, --disable-shared=libgfortran
ought to narrow it down to just that library.

-- 
"This release is mostly intended to mop up the minor and trivial bug fixes
in the list and clear out the documentation changes.  As such, it should be
treated with even more suspicion than is normal."
    - dpkg 1.10.22 release note

Re: Mainline in regression-fix mode after Thanksgiving

[Paul Brook]

On Monday 29 November 2004 21:15, Phil Edwards wrote:
> On Mon, Nov 29, 2004 at 03:24:23PM +0100, Andreas Schwab wrote:
> > Richard Earnshaw <rearnsha@gcc.gnu.org> writes:
> > > You pretty much need to be an expert to work around this.  There's
> > > certainly no configure-time option that I'm aware of that will do all
> > > this for you -- it requires, at the least, changes to the make system.
> >
> > Try --disable-shared.
>
> Now that we're all using newer autoconf, --disable-shared=libgfortran
> ought to narrow it down to just that library.

I believe it was meant --disable-shared when configuring gmp.
AFAIK --{dis,en}able-shared only effects the libraries built as part of the 
package being configured, not libraries used by a package.
gmp and mpfr are required by the host compiler, not the target.

Paul

Re: Mainline in regression-fix mode after Thanksgiving

[Phil Edwards]

On Mon, Nov 29, 2004 at 09:21:41PM +0000, Paul Brook wrote:
> On Monday 29 November 2004 21:15, Phil Edwards wrote:
> > On Mon, Nov 29, 2004 at 03:24:23PM +0100, Andreas Schwab wrote:
> > > Richard Earnshaw <rearnsha@gcc.gnu.org> writes:
> > > > You pretty much need to be an expert to work around this.  There's
> > > > certainly no configure-time option that I'm aware of that will do all
> > > > this for you -- it requires, at the least, changes to the make system.
> > >
> > > Try --disable-shared.
> >
> > Now that we're all using newer autoconf, --disable-shared=libgfortran
> > ought to narrow it down to just that library.
> 
> I believe it was meant --disable-shared when configuring gmp.

Ah, I misunderstood.  Thanks.


> gmp and mpfr are required by the host compiler, not the target.

And I'd forgotten this completely.  :-(


-- 
Behind everything some further thing is found, forever; thus the tree behind
the bird, stone beneath soil, the sun behind Urth.  Behind our efforts, let
there be found our efforts.
              - Ascian saying, as related by Loyal to the Group of Seventeen

Re: Mainline in regression-fix mode after Thanksgiving

[Gerald Pfeifer]

On Mon, 29 Nov 2004, Richard Earnshaw wrote:
> Whilst on the issue of g77 vs g95.  I still regard the fact that you
> have to build and install (in a system directory) a non-standard build
> of a non-standard library (gmp with mpf) as a major build bug.

I strongly second this.  This is really painful.

Gerald

Re: Mainline in regression-fix mode after Thanksgiving

[Richard Kenner]

    Be aware of the maximL "Those who make no mistake usually make nothing".

    I.e., any measure of regressionist behaviour should be offset 
    (normalized) by the number of successful changes the person has made.

I don't think anybody was proposing to use the regression information
to "rate" submitters in any way, just to do a preliminary bug assignment.

Re: Mainline in regression-fix mode after Thanksgiving

[Richard Kenner]

    After all, we have an alternative: if a patch causes regressions and
    this isn't promptly fixed, the patch can be reverted.

But this isn't an alternative in the case being discussed, where the patch
causing the regression might have been checked in months ago.  There may
very well be patches applied on top of that patch or other patches that
depend on that patch.  Reverting an old patch can easily cause more regressions
that the patch itself caused.