Kevin P. Neal <kpneal@pobox.com> wrote on Fri, 14 Mar 2003 at 20:15:44
-0500 in <20030315011544.GB18538@neutralgood.org>:

> I hope nobody really minds me being in a bad mood....

No, I think it useful (err, well, you know what I mean).

> > So if the solution to a PR is noncontroversial, implement the solution
> > and email the diffs to the PR. Then "find someone to commit it," which
>                                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> Tricky bit ---->

It shouldn't be.

> > should be straightforward, especially in the light of PRs with owners,
> > even if those owners are things like "bin-bug-people@netbsd.org."
> > 
> > In the absence of a clear owner, a query can be directed to the
> > appropriate tech- list.
> 
> Let me get this straight: we find a bug, write a patch, send the PR
> with the patch, and then go hunting down someone to commit the fix?

Well, your experience is doubtless better than mine, because as a person
with commit access, I don't spend a lot of time worrying about the
owners of PRs dealing with my patch submissions.

But emailing the PR with the patch should be sufficient to
contact the owner (who should automatically receive email),
so the "hunt down someone" step should be a no-op.

I recognize that may not always be true, but that's how it ought
to work most of the time.

> Huh? What's the point of a tracking system where items have owners
> if the submitter still has to go looking for people interested enough
> to bother looking at it?

Literal answer: the point is to track problems, and it is more
optimized for that than for fixing them.
More nuanced answer: The submitted shouldn't really have to go looking,
and if that is a regular problem, then you should escalate issue.
It may not be fully apparent who you should escalate to. There
are a variety of choices:
  .  gnats-admin@netbsd.org, responsible for the GNATS system, but
     not really the content. This might be appropriate if you find
     foo-bug-people@netbsd.org is not being responsive.
  .  tech-foo@netbsd.org, which should be able to pick up the slack.
  .  core@netbsd.org, whose precise role is somewhat in transition, I think,
     but is approximately "technical guidance over the project."
  .  Any NetBSD developer who is willing to run the political gamut for
     you. I'd be happy do this if you'd send me private email.


> Doesn't the tracking system send out emails to people letting them know
> about (still) open issues? Why is that not enough?

Is it proving not to be?

It only sends them to the PR owners, and it may or may not be sufficient.

> If I submit something I'd like a little feedback in a reasonable
> amount of time, where reasonable can be as large as a month, or even
> "after the next release makes it out the door". If I submit something
> that sucks, tell me! If I submit something and nobody has time right
> now, tell me! I don't want to sit here wondering if my patches are
> being ignored for technical reasons, other good reasons, or just
> because someone doesn't like me. "Yo, what up?"

Those are reasonable expectations. If they're not happening,
I'm afraid you have to tell us :(.

> And I really really dislike the fact that there is no appeals system.  I
> submitted a documentation correction. One person committed it, another
> decided (incorrectly IMHO) it was "wrong" and backed it out. Now what?

There is certinly an appeals system. Discuss the issue on the appropriate
tech- list. If that somehow fails, choose one of the above escalation
paths.

> Perhaps NetBSD needs some sort of a system where a PR can be escalated
> to a level where a set of people vote on it. The voting group could
> be larger than the group of committers possibly. 

Escalation is certaily necessary. The exact process by which
the escalation is handled is subejct to lots of debate, of course.



And of course, the context of this thread is ways to improve
the system. I'm not suggestig that it doesn't need improvement,
but rather that there is an answer to "How should I work with today's
system?".

--jhawk

p.s.: I think this is not quite right for tech-userlevel, but hesitate
to suggest moving it to a different venue for lack of a good choice...