On Sat, 18 Dec 2004, Greg A. Woods wrote:

> People reporting problems in pgksrc,
  [...]
> are going to keep using "send-pr" until they are told otherwise.

This is true, and expected.  We want the PR database to track *problems* in
pkgsrc.

> including submissions of new packages

This is not really true anymore.  People *are* being encouraged to try out
pkgsrc-wip in preference to send-pr.  This is now informal policy, and there
has been talk about making it formal policy at some point.

pkgsrc-wip is quite successful thus far for new pkg submissions.  There's
about a thousand packages there right now, and a couple hundred have already
cycled into main pkgsrc.  We've gained several main pkgsrc developers
through pkgsrc-wip.

> or package upgrades,

If it's a minor update, it's typically fine to put it in a PR.  Often a diff
isn't event needed if the change just consists of updating DISTNAME.

If it's an update that requires major changes to the package to make it work
properly, particularly if many packages depend on the older version,
pkgsrc-wip is by far the better place to go.  Major package reworks tend to
be *bigger* changes than new package submissions, and they need a place to
air out and shake out problems.

> Worse yet ignoring submissions that come by one means in preference to
> another is in fact going to lead to less volunteering.

Let me put it in one simple sentence again (by my count, this is restatement
of the same concept #4):

  We don't have the time to review all new packages submitted via gnats.

We also can't make CVS access more open, as we don't have the support time
available to help with commits by hundreds of new folks who haven't learned
enough about pkgsrc development yet.  pkgsrc-wip provides a very successful
learning environment that otherwise wouldn't exist at all.

> However until and unless use of GNATs is officially deprecated for
> pkgsrc the available human resources really must be encouraged to handle
> GNATS PRs lest the whole GNATS system be unofficially deprected by its
> users because they perceive it as a pointless waste of time and effort.
> I think that would be the worst possible outcome for all of us.

There are some folks who periodically go through gnats and move packages to
pkgsrc-wip (or pkgsrc, if there's time to review them), but really, there is
quite simply a _lack_of_time_.  We'd really like to see more people use
pkgsrc-wip directly, as its environment makes for a much more collaborative
interaction.

> I know there are quite a number of my own pkg PRs still open, though in
> general I've perceived a more timely handling of them than PRs I've
> submitted in other categories, at least until recently.

Really, honestly, go get yourself registered for pkgsrc-wip and move any new
package submissions or updates-with-major-reworks there.  Once committed,
ask for a quick review on the pkgsrc-wip-review mailing list.  You'll be
glad you did.

But don't just take my word for it -- ask the other pkgsrc-wip users on
pkgsrc-wip-discuss.

In case you're thinking of restating "I won't touch pkgsrc-wip with a..."
again, consider this:  pkgsrc-wip consists of one additional subdir "wip"
that you place under pkgsrc/ and can "cvs update" inline with main pkgsrc.
All you need to do to use pkgsrc-wip is cd to pkgsrc and:

[devel]    $ cvs -d USERNAME@cvs.sourceforge.net:/cvsroot/pkgsrc-wip co -P wip

[readonly] $ cvs -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/pkgsrc-wip login
           $ cvs -d :pserver:anonymous@cvs.sourceforge.net:/cvsroot/pkgsrc-wip co -P wip

"cvs update"s on pkgsrc will now automatically update pkgsrc/wip too,
because CVS 1.11+ is smart enough to traverse different CVSROOTs in one tree
properly.

And to answer your other question before it's asked:  No, CVS acls are not
feasible to do this.  (Again, lack of time, in the case of the sysadmins.)

> However I must also admit that I tend to not be quite so agressive at
> submitting PRs about pkgsrc as I could be (I have many dozens of local
> fixes and changes that could be appropriate for mass consumption) because
> I do also perceive that GNATS PRs in general are often ignored or even
> sometimes mishandled.

Much of the stagnation of pkg PRs is thanks to that same lack of time I keep
needing to point out.  There's so many "pkg" PRs related to new pkg
submission that bug fixes or general infrastructure improvements are
sometimes lost in the noise.  Keep submitting those kinds of things via PRs,
and nag on tech-pkg@ if you don't hear timely response.

-- 
-- Todd Vierling <tv@duh.org> <tv@pobox.com>