Re: Mainline in regression-fix mode after Thanksgiving

["Giovanni Bajo" <rasky@develer.com>]

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