Ability for maintainers to update own ports

[Clement Laforet]

On Tue, 11 Nov 2003 03:17:42 +0300
Sergey Matveychuk <sem at ciam.ru> wrote:

> 
> Yes. It's a good point to have two branches for ports. So many times I
> 
> cvs'ed an old port version because found a new one unstable...

Hey guys, it looks like debian packages management system :-)
CVS branches, by-port-mentoring, etc. are pretty good ideas but are we
able to deal with this ? 

Two branches implies two commits. If maintainer can commit on the
"testing" branche, you have just push the dirt under the carpet, who
will consider your port(s) stable enough ? Who will be responsible for
massive changes (like gettext update) ?

By-port-mentoring (I mean "when a committer add a ports, he's reponsible
of it") is seducing, but committers have a real life too, so they can be
AFK for a while, so PR will rot in GNATS too.

Everyone who submits a port hopes his port will be committed quickly, to
contribute with the project. It's quite hard to get a "minor port"
committed if committers don't know you.

Another approach of the problems:
1. insert more revelant informations in PR. We can add fields in PR
bodies to simplify Mark Linimon works.
i.e.
PORTNAME: my-ports
CATEGORY: what-I-want
CLASS: [update|patch|fix]

maintainer-update is no more efficiant nowadays and synopsises are
overloaded with redundant informations to catch committers attention.

2. Encouraging committers to get involved in maintaining categories,
like Joe Marcus Clarke for gnome related ports. I know it's not as easy
at it seems: you can't ask a committer to deal with very specific port
he don't know.
If we "segment" (a little more) ports-bugs, new ports (and only new
ports) can be routed to sublists which committers choose to subscribe or
unsubscribe when they want, avoiding new ports to be lost in the mass.

clem