Ability for maintainers to update own ports

Allan Bowhill abowhill at blarg.net
Wed Nov 12 19:17:18 PST 2003

>> The first can be satisfied with something like pkgsrc-wip, and I always
>> wondered why we don't have a ports-FRESH and ports-TESTED, like we have

>Because even with a single, unbranched ports collection, committers
>can't keep it in working order without significant ongoing effort.  On
>average, several ports become broken on one of the supported
>architectures and versions, *each day*.  That's not counting the
>periodic "cataclysmic events" where hundreds of ports become broken
>due to e.g. a change in -current, and not counting errors introduced
>in the course of development work on the ports collection

All the more reason to allow commit access to maintainers of leaf-node
ports (ports that do not serve as dependencies to others, particularly
multiple ports).
How many of these packages are there - about 8000 to 9000? Wouldn't that
take a load off committers?

Ports that are dependencies of others have a greater need to be kept stable.
How many are there - 1000? Just keeping that stabilized sounds like too
big a task for committers anyway.

>If you start adding more branches to the ports collection, you're
>going to multiply the possible failure modes, and the net result will
>be that the number of errors accumulating in the ports collection will
>more than multiply.

If maintainers had access to commit, they could more quickly respond
to broken ports. But unless some kind of special tools are made available
to allow almost-public access to commit leaf-node ports, they will just sit
there in gnats.

Maybe a FreeBSD 3rd party developers portal could be created, like
"PortsForge"  where maintainers and contributor wannabes could polish-up
their work and commit it without burdening Gnats.

Ports Committers could just scout the site for likely inclusions if they are
looking form something new to bring into the official ports tree.


More information about the freebsd-ports mailing list