blanket portmgr approval vs. non-fixing changes

Michelle Sullivan michelle at sorbs.net
Wed Jun 29 16:35:51 UTC 2016


Mathieu Arnold wrote:
> +--On 29 juin 2016 13:15:44 +0200 Michelle Sullivan <michelle at sorbs.net>
> wrote:
> | Baptiste Daroussin wrote:
> |> On Tue, Jun 28, 2016 at 11:15:56PM +0200, Matthias Andree wrote:
> |>>
> |>> 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.
> |>>
> |> I might have been not explicit enough, of course any changes should be
> |> tested, and of course high profile ports breaking means special
> |> attention and prevent the sweeping change to actually happen.
> |>
> | Sorry I think you're wrong at this point.
> |
> | Define "high profile" ... Some library port that other obscure ports are
> | dependent on..?  What say postgresql94-client or perhaps p5-Bucardo...
> | something that only a few ports (if any) rely on, yet would be a massive
> | problem for a lot of production servers/services if they were suddenly
> | and quietly broken...
>
> High profile is gmake, gettext, or libpng, those important things.
>
No disrespect intended, however...

gettext-runtime sure 100% with you...  gettext-devel ...?
gmake? (break gmake it stops people compiling lots, but doesn't actually 
break production servers)
libpng ... 50/50 on that .. its sorta like postgres*-*  I have servers 
that don't have libpng, and I have servers that don't..

...but that's sort of my point... it really should be an all or nothing 
thing... and IMHO it should be 'all'...  Bulk changes in my opinion 
should not leave something that was working, not working.

Regards,

-- 
Michelle Sullivan
http://www.mhix.org/



More information about the freebsd-ports mailing list