On Tue, 16 Nov 2004, Brad Nicholes wrote:
> > automatically be approved for backport by lazy consensus. The
> purpose
> > for this proposal is to avoid stagnation of backport proposals in
> the
> > STATUS file simply due to the lack of votes.
>
> -1 (vote, not veto).
>
> I think this is a bad idea and would make stable turn into CTR. And,
> that, I
> believe jeopardizes the overall quality of the code. And, I'm not
> willing to
> take that risk.
>
> If there are a lack of votes for backport, then I believe that is a
> sign that
> there is not a healthy enough community of people who are able to
> review the
> code. I'd like to ensure that we don't create 'islands' of code that
> do not
> have sufficient people who understand it. -- justin
I agree with Brad that looks dubious, and would give it -0 as it stands.
But I also think it looks bad when a genuine bug sits in bugzilla for
months or even years after a fix is available.
I think perhaps the answer to this is to identify areas of responsibility.
Instead of seeing a critical bug in foo and wondering "who the **** has a
clue about foo", we should be able to bug particular individuals to
review it at the very least. Likewise bugzilla: someone needs to have
responsibility for seeing that a reported bug in foo component doesn't
languish in "NEW" forever.
A little bit of "this is your responsibility" bugging could do Great
Things for round tuits, and either getting those three +1s or finding
out why something shouldn't happen.
Perhaps we can have a couple of levels of per-committer committment:
* Primary responsibility (1 or more person per component) - take
control of issues
* Secondary responsibility - OK to be bugged to review patches.
We have a list of components in Bugzilla. A first step would be to take
each component in there and establish up-to-date records of responsibility
for every component listed there.
--
Nick Kew
