Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 29 Jun 2016 23:50:50 +0200
From:      Baptiste Daroussin <bapt@FreeBSD.org>
To:        Michelle Sullivan <michelle@sorbs.net>
Cc:        Mathieu Arnold <mat@FreeBSD.org>, Matthias Andree <matthias.andree@gmx.de>, freebsd-ports@freebsd.org
Subject:   Re: blanket portmgr approval vs. non-fixing changes
Message-ID:  <20160629215050.eaxj2s4z7qqm5xjx@ivaldir.etoilebsd.net>
In-Reply-To: <5773F8E2.9030702@sorbs.net>
References:  <201606272021.u5RKLVhQ057899@slippy.cwsent.com> <op.yjrc3knw57n2so@thoth.home> <20160628091709.pbvq7lekss2ql2en@ivaldir.etoilebsd.net> <5772E90C.6020908@gmx.de> <20160628213341.vvtobzbvxabphsqc@ivaldir.etoilebsd.net> <5773ADE0.7060204@sorbs.net> <1F6847D731A66548F6179F88@ogg.in.absolight.net> <5773F8E2.9030702@sorbs.net>

next in thread | previous in thread | raw e-mail | index | archive | help

--sgrnc2voh2nkktiz
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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@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 sweep=
ing
> > |>> 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 mass=
ive
> > | problem for a lot of production servers/services if they were suddenly
> > | and quietly broken...
> >=20
> > High profile is gmake, gettext, or libpng, those important things.
> >=20
> No disrespect intended, however...
>=20
> 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 th=
at
> don't have libpng, and I have servers that don't..
>=20
> ...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.
>=20
> Regards,

In theory yes, but in reality how to you handle texinfo update have breakin=
g 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 f=
ixed
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 becau=
se
over complicated code and those ports have not been maintained for more tha=
n 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 o=
ther
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 oft=
en
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 w=
as
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 t=
he
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 op=
tions
like NLS off or DOCS off.

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

Pushing sweep changes to be 100% free of breakage leads to people being sca=
red
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 li=
ke
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 pa=
ckage
build failure over 26k leading to 93 skipped packages on the quarterly bran=
ch
and only 11 on the head branch of the ports tree leading to 86 build skipped
(meaning no hugh profile packages).


Best regards,
Bapt

--sgrnc2voh2nkktiz
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJXdEKnAAoJEGOJi9zxtz5aKcoQAN4GAlHKXPU+jwhOikFMP+aw
TOimo+0OTVWH3WXII0apoVH8UGTEV2RXzfJrg0LPxCWPUgZCEtUBfa54BcO40olm
H5uxT/Ua3BcEX+UXsYbiSyrJwqJJY8msKmhfVRSrK/DS4QWrJbCu7V+AYpNQPuAV
pgCuepgf+KdDthUD5n1aZejR6AjniKNh7XSXQylK6oI+93UIpoDAKYqx9rOCvNoS
kzvPQOTp14FKMG/mdFq4JLJJyAtQXpRuEbkyulVgf32HACZqhQdI5gypaL7NwD6/
pCjI5dr296b/9HLZ8KShsQRAZMZmCWDmv8E8NbUWO7RVYt6fHNoZq+nvaXWbKZu5
jo2sR9lcAr5UgM3bnkLki1IpztO7ImSP0CAwlkS1Gk79tOY9Q4NBUvTFLJ1NCzjL
5LVSsO5qL/YgHkoknCHJCcsB66E12qMCXjBLnUEr26gaPrigHMDugLZ9mDaPJBxk
IAEz52Q89aomXgIJ+QclPdf0iyw2zCZQT5F8k+eBEp7pk48kLCGNegeKrfOfXDF2
B/R7KCrhE7ERtwO1pb8Fx5uVy9mqwz6Hg98AJoWpaLPvHTfKTm/Ur7J9Hcjb1CU9
8bbZi5ofr9bc1Qc7VqIYlYESDL+kD+Rhe3R+hmyUldAiiOyij1PvovGEwmt0hSy7
4JDwQgrZHalHf4CaFtsE
=bufv
-----END PGP SIGNATURE-----

--sgrnc2voh2nkktiz--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160629215050.eaxj2s4z7qqm5xjx>