blanket portmgr approval vs. non-fixing changes

Matthias Andree matthias.andree at gmx.de
Tue Jun 28 21:16:11 UTC 2016


Am 28.06.2016 um 11:17 schrieb Baptiste Daroussin:

> What you are asking is part of the blanket in particular when changing things in
> individual ports, we expect committers to have a look at pending PR (yes I know
> I have been guilty of individual port change without sometime checking about
> pending PR which was wrong from my side)
> 
> For sweeping changes this is a bit different as when a change touches a large
> portion of the tree we can not expect the committer to have a look at each
> individual ports.

Baptiste,

to give you a provoking counter example:

  By that logic, I would not have been expected to notice that the
bitcoin garbage insisted on db48, I could just have killed it off and
moved the bitcoin ports onto db5.  (That's stretching it a bit because
there was Peter Wemm's objection to the DEPRECATED= tag on record already.)


Meaning that, in this thread: I beg to differ on sweeping changes.

These do need a thorough review, and often a series of -exp runs, to
keep the number of casualties low.  If I had gone by this policy of
sweeping changes, we'd nuked all DB2, DB3 and DB4 ports and had force
moved all the bitcoin and openldap ports and whatnot onto db5 without
consulting anyone, and I guess we'd heard a lot more screaming than with
the approach I chose, meaning look at several dozen of ports before
committing the breaking and sweeping changes.

And I do think we should, opposite to what you are proposing, make the
committer spend extra time for high-profile ports that entail sweeping
changes to chase down the breaking change to, say, a library port.

Cheers,
Matthias

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20160628/c7263823/attachment.sig>


More information about the freebsd-ports mailing list