Time to dissolve eclipse@ team? Others want to maintain / team concept in general

[Mark Linimon]

On Sun, Apr 20, 2014 at 09:29:57AM +0200, John Marino wrote:
> 1) I recommend that a team must consist of at least 3 people, and if
> this requirement cannot be maintained then the team must be dissolved.

I'm not so sure about this part, but ...
> Nobody is going to touch a PR owned by a team, even if it has timed
> out for months.

... this absolutely has to change.  Evidence below.

To save folks browser time, I've summarized the over 2000 (!) ports
PRs in http://portsmon.freebsd.org/portsprsall.py?sortby=responsible ,
focusing on mailing-list based maintainers.

*note*: I am not blaming anyone on any team for the accumulation.
Like most ports work, PR busting is thankless.

apache               9
autotools            3
chromium             4
doceng              10
freebsd-arm          2
freebsd-eclipse      4
freebsd-emulation   10
freebsd-java        20
freebsd-multimedia  34
freebsd-python      36
freebsd-x11         56
freebsd-xfce        10
gecko               32
gnome              100
haskell              5
kde                 32
lua                  4
mono                 3
office              44
perl                17
pgsql                6
ruby                 1
vbox                18

And now my own conclusions.  Yours may vary.

 - Pretty much every team needs new blood.

 - The UI-based things tend to have a larger number of PRs than
   non-UI-based things.  This is probably to be expected -- there's
   simply more ways to get things wrong.

 - The eclipse PRs are indeed stale -- but they're not the stalest.

 - The doceng (often ghostscript) PRs are rarely answered.

 - The multimedia, mono, and office PRs are rarely answered.

 - The multimedia PRs are mostly about multimedia/vlc.

 - The office PRs are often about build failures.

 - The gnome, kde, and x11 PR counts are somewhat mitigated by the
   fact that a great deal of integration and testing happens outside
   the ports tree, and tend to be introduced all at once.

 - Assigning new-port PRs to mailing lists is counterproductive.

mcl