blanket portmgr approval vs. non-fixing changes

[Baptiste Daroussin]

On Wed, Jun 29, 2016 at 06:35:46PM +0200, Michelle Sullivan wrote:
> 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,

In theory yes, but in reality how to you handle texinfo update have breaking the
syntax and leaving 10 ports are not dependency on and have not been updated
upstream for around 15 years? (Yeah I have been through that and actually fixed
8 of those and left the 2 others because I really could no find the fix and
actually noone complained and this was more than 2 years ago).

of a lib like let say libpng which have a security issue moving you do newer
version of the lib which of course because how stable libpng API is you end up
having to fix 250 ports and you end up with 3 ports you cannot update because
over complicated code and those ports have not been maintained for more than 10
years... you mark those 2 ports as broken and deprecate them.

What about upgrading ruby to the officially commanded version but then
you discover puppet37 is broken and upstream claims they don't care and won't
ever fix? you end up with marking it as broken and the one who care about
puppet37 (which was my case) then you come up and propose a fix and save the
ports

That is all this is about, of course we expect each committer to aim at 100% of
non breakage when you do changes but the reality is always a bit different. and
yes if 2 leaf ports are marked as broken in the battle they so be it.

We have more than 26k ports in the ports tree. Which is way more than any other
operaring system I am aware of, on this list there are around 10-15% of them
which are things without any active upstream, often written in old version of
C/C++ which breaks on regular basis after libc/toolchain updates and we often
manage to make survive (see the getline/dprintf fixes I have been committing
recently for exemple).

The number of working port 'percentage of the entire ports tree' have never been
so high on the entire ports tree since the last 8 years at least (I haven't made
any statistics before) since the blanket, the overwhole general quality has
improved a lot, resulting in less breakage in the ports tree than what it was
before.

If one really want to get numbers I can provide numbers about what was the
number of failing ports with the default options (which is supposed to be the
most tested) 8 years ago, 6 years ago, 2 years ago and now.

I have the same numbes with non default options but use on regular basis options
like NLS off or DOCS off.

We cannot write down a rule that is supposed to describe what is just "common
sense" but again my initial message was: yes of course we do aim at 0 breakages
on changes, and yes sometime sweep changes leads into marking as broken 2 ports.

Pushing sweep changes to be 100% free of breakage leads to people being scared
about doing some important modification that are really needed for a while.
Look at the history of boost updates for example or ICU... After how long
someone really had a look at the bugs from libtool we were suffering for like
forever because of overlinking for example - not only - (leading to constant
breakage of inplace building) etc.


If I only take the freebsd 10 amd64 packages on last run we only got: 13 package
build failure over 26k leading to 93 skipped packages on the quarterly branch
and only 11 on the head branch of the ports tree leading to 86 build skipped
(meaning no hugh profile packages).


Best regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-ports/attachments/20160629/44b2baac/attachment.sig>