On Jun 4, 2006, at 1:43 PM, Gabriel Dos Reis wrote:
The trouble is there does not seem to be a clear gain in your
punishment system. At best it may just discourage people.
In a commercial organization, that might be a good system. For a free
project like GCC, it is not obvious where the long-
On Jun 4, 2006, at 1:52 PM, Mike Stump wrote:
A wiki page of top regressions we care about? We could politely
request general agreement that the ones listed be given priority.
There is already a link from the main page of GCC to the regressions
and they are given priorities by the release ma
On Jun 4, 2006, at 1:11 PM, Andrew Pinski wrote:
Yes but that is not all the problem because a lot of the time
the maintainer is also the submitter. There is no way to discourage
the behavior of the maintainer on going on to other stuff while there
are known regressions to fix.
A wiki page of
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Jun 4, 2006, at 1:19 PM, Richard Sandiford wrote:
| > I think a system of
| > punishing maintainers is going to make it less attractive for
| > less active maintainers to do anything at all.
|
| You are not punishing the good maintainers, just not so
On Jun 4, 2006, at 1:19 PM, Richard Sandiford wrote:
I think a system of
punishing maintainers is going to make it less attractive for
less active maintainers to do anything at all.
You are not punishing the good maintainers, just not so good
ones. The idea is keep maintainers active in GCC a
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
> However, we should account for periods of inactivity and reduced
> activity caused by personal issues, employer changes, illness,
> whatever.
Agreed.
> Other projects have a certain period of time (one year, eighteen months)
> after which inactive cont
On Jun 4, 2006, at 1:03 PM, Richard Sandiford wrote:
I agree. And I don't think a new gcc by-law is needed here (we
seem so
many of those already). Maintainers can already refuse to review a
"fun
new feature" patch until the submitter has fixed some problem with one
of the submitter's ea
Mike Stump <[EMAIL PROTECTED]> writes:
> On Jun 4, 2006, at 2:08 AM, Steven Bosscher wrote:
>> On 6/4/06, Richard Sandiford <[EMAIL PROTECTED]> wrote:
>>> Even if it's not intended that way, your proposal is probably
>>> going to
>>> be interpreted at some stage as a way of punishing maintainers.
On Jun 4, 2006, at 2:08 AM, Steven Bosscher wrote:
On 6/4/06, Richard Sandiford <[EMAIL PROTECTED]> wrote:
Even if it's not intended that way, your proposal is probably
going to
be interpreted at some stage as a way of punishing maintainers.
And what is wrong with that?
I have a different
On Sun, 4 Jun 2006, Steven Bosscher wrote:
> Maybe it would help clean up the long list of maintainers who don't
> actually do any maintenance. Then, at last, you get a more fair
> picture of the number of reviewers&maintainers that we really have.
Agreed. It will provide a clearer picture at l
On 6/4/06, Richard Sandiford <[EMAIL PROTECTED]> wrote:
Even if it's not intended that way, your proposal is probably going to
be interpreted at some stage as a way of punishing maintainers.
And what is wrong with that? Maybe it would help clean up the long
list of maintainers who don't actual
Andrew Pinski <[EMAIL PROTECTED]> writes:
> Now for the fix I have in mind (which might or might not work):
>
> If you are a maintainer of an area and you approve a patch which
> causes a regression in that new code, you have to fix it or have the
> person whos patch it was fix it or face losing yo
12 matches
Mail list logo
