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>