Date: Tue, 28 Jun 2016 11:17:10 +0200 From: Baptiste Daroussin <bapt@FreeBSD.org> To: Kevin Golding <kpg@caomhin.org> Cc: freebsd-ports@freebsd.org Subject: Re: blanket portmgr approval vs. non-fixing changes Message-ID: <20160628091709.pbvq7lekss2ql2en@ivaldir.etoilebsd.net> In-Reply-To: <op.yjrc3knw57n2so@thoth.home> References: <201606272021.u5RKLVhQ057899@slippy.cwsent.com> <op.yjrc3knw57n2so@thoth.home>
next in thread | previous in thread | raw e-mail | index | archive | help
--umjymritqrrpj45u Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Jun 28, 2016 at 09:12:46AM +0100, Kevin Golding wrote: > On Mon, 27 Jun 2016 21:21:31 +0100, Cy Schubert <Cy.Schubert@komquats.com> > wrote: >=20 > > In message <57716D89.1050108@sorbs.net>, Michelle Sullivan writes: >=20 > > > Don't forget that many people see their name/email in the maintainer > > > line as being responsible for the port.. so someone goes makes blanket > > > changes which actually breaks stuff.. that reflects on the person in = the > > > Maintainer line - whether you want it to do so or not, whether you > > > believe it or not.. > >=20 > > I think it's more than the maintainer perceives that they're responsibl= e. > > Getting that email from freebsd-pkg-fallout I think there was and maybe > > still is a general impression that is had. I for one take the attitude, > > you > > break it, you fix it and I don't hesitate to email any committer who > > made a > > blanket change that broke something. It's only fair because fixing > > breakage > > caused by others also takes away from other productive work and project= s, > > as some of us do have time constraints and time pressure due to other > > commitments. >=20 > I think it goes beyond just breakages though. Recently I had a couple of > ports to update so I made sure my tree was current first thing in the > morning, I went through and updated. Then I ran all the build logs etc. > submitted my patches to bugzilla - and about the same time someone did a > blanket update of RUN_DEPENDS in my ports. Including a PORTREVISION bump. > It's easy to argue that's a very trivial change that doesn't needs > maintainer involvement, but it also impacted my day. >=20 > So I updated my tree again and did the whole process again which was > inconvenient, but I also found myself cringing at any users of the port > perhaps updating on the PORTREVISION and then a couple of days later when= my > more complete update was committed having to do it again. I thought it > looked bad as I was obsoleting the patches and build logs I submitted a > couple of hours earlier too. >=20 > Had I known about the blanket update I could've rolled that into my updat= es > or something, but it was just suddenly there. There was no public warning= of > that change coming (and I did search the relevant lists just to make sure= I > hadn't missed something). Luckily my ports are mostly trivial so the actu= al > impact was fairly low, but it still annoyed me and made me feel that it m= ade > me look bad. It still took extra time to do these simple updates, especia= lly > once I started wondering what I'd missed to not catch this beforehand. I > felt rather lucky that I'm quite a low volume maintainer in that regard > because it could've easily sucked up a lot more of my time. >=20 > On the flipside blanket updates will logically come from people who give = far > more time to this stuff than me. Will they be happy with having to jump > through hoops for the likes of me? If I'm unhappy about the extra time th= is > caused me maybe I'm being unfair in asking them to spend time checking for > pending updates before doing something. Maybe I just need to suck it up a= nd > let the big players do their thing. >=20 What you are asking is part of the blanket in particular when changing thin= gs 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 lar= ge portion of the tree we can not expect the committer to have a look at each individual ports. Best regards, Bapt --umjymritqrrpj45u Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXckCLAAoJEGOJi9zxtz5aNUYP/2bw0SP65gJ0tECLGACygQ6t RxSN2DGGokxFczPUYKJGnBDlT2kKAHzml7e0C6rysqfMc69FAjhHJRDIuaa+vJFr 80q9DtHKPQIqkbRiSdp+RJI2s6ICD5S4AJArEsfMBhJX4gTtJ+IbJDbq1Zc6nDBl BYooRbxl8rLISoz9cFNgPdcQY82+RHx9GQrhLrojPTH/QPzqiIO0AwfVwbWdYisN E70D0W5CmqB1miJ/bHmLxepSfvE/ihGPJwkZy0cSGIa4cHlmVmHibjxG8NckEIOY lckzYuWstubiwkJoJFcosu4Z0XnUA52GGj+qSsF7yzq5XSmL2KAVKI3GxcFG1xII zJRyxEmdao6gq2Q0Lk7wn/vP0JNecYHNgyDrSQvqcRKjgaLiv8Mj2CIClyV6KSS8 lCCloxR3nroAZsWupHYuffkM+qFhzlsF9jrQfjWyHpMjAnmIbeowgzfLtqsvKqxL dSX/C//8q2xNJWcvjuPUaJlqQTFjZEOiuNt8U0p9yxDbSWZ1HxflAKxDOeicpZVW ajSpClOcFnJX7fXwK0uGTY4eZHI/02qP75qs+LyseTSYXwm8xBhCDtnuuAuqnA6c CS+56CUd7brOhMGS5/Y2HKn+5IMckekwvxMEJ25EqZbz7Ka9EkVxlGkqeh7VQJ5z lkiVrgf4aufd+9zptbaL =yw7O -----END PGP SIGNATURE----- --umjymritqrrpj45u--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20160628091709.pbvq7lekss2ql2en>