Tom Lane <tgl@sss.pgh.pa.us> writes:
> There seems to be some weird notion abroad in this thread that the
> primary time sink during beta is unspecified low-skill "release
> management" tasks. There really isn't all that much of that.
I'd have said high-skill, which the following paragraph I parse as
confirming it:
> What I find takes up a lot of time is post-commit patch review, fixing
> reported bugs, and documentation cleanup. Now we could doubtless find
> other people to do the purely copy-editing aspects of doc cleanup, like
> fixing less-than-stellar English, but what I'm really looking for is
> factually incorrect or obsolete statements. It takes someone who's
> pretty much familiar top-to-bottom with the whole product to do a decent
> job of spotting things that were true awhile ago but aren't any longer.
> We just don't have many people who (a) can and (b) will do that work.
Yeah and the ones who can, they're not all having the possibility to get
paid doing it...
> What I think we really need for beta, and could reasonably hope to get,
> is a larger and better-organized beta testing effort. But we are not
> going to get that if people are thinking about new development and
> commit fests instead of testing what's already there.
That's where the advocacy people involvement would help I think. But for
beta testing to be effective you need all the 3 of non-trivial
application, non-trivial data set and meaningful automated test suite. I
for one don't have that handy.
So what I had in mind is that if you know you're not that helpful on the
release management issues (of which beta testing), maybe you could help
running the review fest for doing entry-level patch triage, even against
the stabilizing tree (if the only goal is timely feedback to authors).
Again I agree we miss resources more than organization, but I can't help
thinking some resources won't be able to participate in end-of-cycle and
are blocked waiting for the release lock.
Regards,
--
dim