Re: Release Schedule issues and doubts

[Richard Sandiford <richard@codesourcery.com>]

Gerald Pfeifer <gerald@pfeifer.com> 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 contributors are contacted and eventually purged,
> and I think we should do something similar.

I don't really see what we gain by having a fixed limit (and another
rule ;)).  The SC have removed people in the past in cases where it
was "obvious" that they were no longer active.  That's really just a
house-cleaning exercise, though; I don't think we gain anything other
than cleanliness.

Like you said, there are good reasons why people might not be able
to review patches for a while.  But (as you also said) if someone in
MAINTAINERS manages to review an average one patch every two months,
say, that's still better than nothing!  Even if those patches come
after a long period of inactivity.  Some maintainers with a lot of
experience don't review patches as often as they used to, but they
still provide good reviews when they do.  I think a system of
punishing maintainers is going to make it less attractive for
less active maintainers to do anything at all.

It's not like we have a fixed limit on the number of active maintainers.
At the end of the day, if the SC think that someone would make a good
maintainer for a particular part of the compiler, they should just go
ahead and approach them.  Obviously having more maintainers introduces
more risk of disagreement, but (a) folks have generally seemed to work
through such disagreements in the past (b) I think any judgement about
whether the risk is too high is more likely to be based on the way recent
development has been going, _not_ on a count of the number of people
in MAINTAINERS.

Richard